[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1208383185.3859.24.camel@bluto.andrew>
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