From: Kevin Corry <kevcorry@us.ibm.com>
To: Joe Thornber <thornber@sistina.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: online resizing of devices/filesystems (2.6)
Date: Fri, 17 Oct 2003 11:16:07 -0500 [thread overview]
Message-ID: <200310171116.07362.kevcorry@us.ibm.com> (raw)
On August 21, 2003, Joe Thornber wrote:
> Hi,
>
> Should genhd.h:set_capacity() find and update the i_size field of the
> inode for the device ?
>
> The BLKGETSIZE and BLKGETSIZE64 ioctls report the size in the devices
> inode:
>
> case BLKGETSIZE:
> if ((bdev->bd_inode->i_size >> 9) > ~0UL)
> return -EFBIG;
> return put_ulong(arg, bdev->bd_inode->i_size >> 9);
> case BLKGETSIZE64:
> return put_u64(arg, bdev->bd_inode->i_size);
>
> Currently people have to close and reopen the device in order for a
> size change to take effect. This is a problem if people want to do
> online resizing of a filesystem (supported by xfs and resier).
Has anyone had any thoughts about this issue?
To recap, in drivers/md/dm.c:__bind(), there is a call to set_capacity(),
which sets the device size in the gendisk entry. But if the device is already
open (e.g., mounted, or in use by another device (loop, raid, other
device-mapper)), then the bdev->bd_inode->i_size field for that gendisk entry
also needs to be updated to reflect this new size to the VFS.
My initial thoughts were to add something like this to the __bind() function
mentioned above:
bdev = bdget_disk(md->disk, 0);
if (bdev) {
bd_set_size(bdev, size << 9);
bdput(bdev);
}
Of course, bd_set_size() is static to fs/block_dev.c, but it does seem to do
exactly what we need in this situation. The only user of bd_set_size() is
do_open(), which does quite a bit of locking before making modifications to
the block_device entry.
Does anyone have any advice as to whether this is the correct approach, or
what additional locking is necessary? Or is there a different approach that
I'm overlooking?
Thanks!
--
Kevin Corry
kevcorry@us.ibm.com
http://evms.sourceforge.net/
next reply other threads:[~2003-10-17 16:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-17 16:16 Kevin Corry [this message]
2003-10-17 20:05 ` online resizing of devices/filesystems (2.6) Andrew Morton
2003-10-17 20:49 ` Kevin Corry
2003-10-17 21:42 ` Kevin Corry
-- strict thread matches above, loose matches on Subject: below --
2003-08-21 10:17 Joe Thornber
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=200310171116.07362.kevcorry@us.ibm.com \
--to=kevcorry@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=thornber@sistina.com \
/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.