Re: online resizing of devices/filesystems (2.6)

From: Kevin Corry
Date: Fri Oct 17 2003 - 11:22:27 EST


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@xxxxxxxxxx
http://evms.sourceforge.net/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/