All of lore.kernel.org
 help / color / mirror / Atom feed
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/


             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.