Date:	Wed, 16 Apr 2008 15:59:45 -0600
From:	Andrew Patterson <andrew.patterson@...com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk,
	dm-devel@...hat.com, axboe@...nel.dk, andmike@...ux.vnet.ibm.com,
	linux-scsi@...r.kernel.org
Subject: Re: bdev size not updated correctly after underlying device is
	resized

On Tue, 2008-04-15 at 17:21 -0600, Andrew Patterson wrote:
> On Tue, 2008-04-15 at 16:03 -0700, Andrew Morton wrote:
> > On Wed, 09 Apr 2008 17:29:42 -0600
> > .
> > > Subject: [PATCH] Reset bdev size regardless of other openers.
> > > 
> > > A block device may be resized while online.  If the revalidate_disk
> > > routine is called after the resize, the gendisk->capacity value is
> > > updated for the device.  However, the bdev->bd_inode->i_size is not
> > > updated when the block device is opened if there are any other openers
> > > on the device.  This means that apps like LVM are unlikely to see the
> > > size change as they tend to keep their block devices open.  There is a
> > > discussion of this problem at:
> > > 
> > >   http://lkml.org/lkml/2007/7/3/83
> > > 
> > > This patch changes block_dev.c:do_open() to call bd_set_size()
> > > regardless if there are other openers on the device.  It should not be
> > > applied in its existing state as changing i_size should be protected by
> > > a lock. Also, there needs to be some analysis on the effects of changing
> > > the device size underneath an app.
> > 
> > hm, tricky.
> > 
> > I don't know what problems a change like this might cause - probably few,
> > given the rarity and slowness of block device resizing.
> 
> I have been looking through code where this might be a problem.  The
> sort of things I was worried about is where something might try and do a
> calculation based on the i_size and write/read data from there after it
> has been resized, possibly corrupting data.  The COW code in dm seems to
> come the closest, but then if you are resizing the device that has
> snapshots on it, you might be getting what you deserve.
> 
> > 
> > Presumably increasing the device size will cause les problems than
> > decreasing it would. 
> 
> Agreed.
> 
> >  Do we even support device shrinking?
> 
> Yes, this common with LVM at least.  Whether it is a good idea to do
> this with a mounted file-system on it is another matter.
> 
> > 
> > > diff --git a/fs/block_dev.c b/fs/block_dev.c
> > > index 7d822fa..d13a4e5 100644
> > > --- a/fs/block_dev.c
> > > +++ b/fs/block_dev.c
> > > @@ -992,6 +992,9 @@ static int do_open(struct block_device *bdev, struct file *file, int for_part)
> > >  				ret = bdev->bd_disk->fops->open(bdev->bd_inode, file);
> > >  				if (ret)
> > >  					goto out;
> > > +				/* device may have been resized with revalidate_disk */
> > > +				if (!part)
> > > +					bd_set_size(bdev, (loff_t)get_capacity(disk)<<9);
> > >  			}
> > >  			if (bdev->bd_invalidated)
> > >  				rescan_partitions(bdev->bd_disk, bdev);
> > 
> > I'd have thought that an appropriate way to fix all this would be to
> > perform the i_size update between freeze_bdev() and thaw_bdev(), when the
> > fs is quiesced.  But it's not really in my comfort zone.
> 
> Except that this is not only done with file-systems.  In my case I am
> just trying to extend an LVM logical volume after a resize but cannot
> because it is open (activated). In practice, however, it is probably
> only useful to do this with an online file-system.  Otherwise you could
> just close all openers and the resize will work fine.
> 
> > 
> 

Adding linux-scsi.  



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

Powered by blists - more mailing lists