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.