All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lou Langholtz <ldl@aros.net>
To: linux-kernel <linux-kernel@vger.kernel.org>
Subject: [RFC] should block layer export bd_set_size() or equivalent?
Date: Tue, 01 Jul 2003 13:04:58 -0600	[thread overview]
Message-ID: <3F01DB5A.6060106@aros.net> (raw)

Background:

Several drivers (like drivers/block/nbd.c or drivers/block/rd.c) need to 
be able to update their devices' size after the first open. The way 
fs/block_dev.c is currently implemented (as recently as 2.5.73-mm2) 
however, updating the size as seen by user processes is not possible 
without directly updating the size stored in various locations of the 
struct block_device and the bd_inode as well. As an example, we have the 
code in drivers/block/rd.c rd_open() which essentially calls what 
fs/block_dev.c calls in its bd_set_size() function. But things are 
changing within the block layer still as evidenced by changes to 
bd_set_size() between 2.5.73 and 2.5.73-mm2 and consequently 
drivers/block/rd.c rd_open() may be incorrect now.

Suggestion:

To have fs/block_dev.c share bd_set_size(struct block_device *bdev, 
loff_t size) or something like this to better abstract the block layer 
from drivers and save us from essentially re-writing the code from here.

Next step:

Discuss this. Why isn't it already exported? What are the cons of just 
exporting bd_set_size()? Should we even let drivers change a device's 
size after the first open? An alternative for nbd at least, is to have 
its user space tool (nbd-client) simply close the device after it has 
changed the size and then re-open it before continuing on. This way 
fs/block_dev.c do_open() re-checks the disk capacity and calls 
bd_set_size() again with the new correct size. Also, bd_set_size() is 
very similar to set_blocksize() (the former though changes the byte size 
of the block device which is what's most critical really to nbd at 
least), perhaps these two functions can be rolled into one; at least 
set_blocksize() is already exported.


                 reply	other threads:[~2003-07-01 18:50 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F01DB5A.6060106@aros.net \
    --to=ldl@aros.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.