All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Andrew Patterson <andrew.patterson@hp.com>
Cc: linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk,
	dm-devel@redhat.com, axboe@kernel.dk, andmike@linux.vnet.ibm.com
Subject: Re: bdev size not updated correctly after underlying device is resized
Date: Tue, 15 Apr 2008 16:03:14 -0700	[thread overview]
Message-ID: <20080415160314.11e9b7e1.akpm@linux-foundation.org> (raw)
In-Reply-To: <1207783782.31821.80.camel@bluto.andrew>

On Wed, 09 Apr 2008 17:29:42 -0600
Andrew Patterson <andrew.patterson@hp.com> wrote:

> I ran into this problem while trying to resize a mounted file-system
> after growing/shrinking the size of the underlying block device (in this
> case, a fibre-channel LUN). The kernel recognizes the device size change
> when revalidate_disk() is called, but the bdev->bd_inode->i_size will
> not be updated for any new openers if there are already openers of the
> device.  In my case I was using LVM thusly:
> 
>      1. Create a volume group with a physical volume on something that
>         can be resized (usually some sort of SCSI RAID device).
>      2. Create a logical volume on that VG.  This holds the underlying
>         PV block device open as long at the LV is activated
>      3. Run blockdev --getsize <block dev>
>      4. Resize the underlying block device.
>      5. Get the OS to notice the change.  For fibre-channel LUN's you
>         can use /sys/class/scsi_device/<device>/device/rescan.
>      6. Size is correctly changed in /dev/block/<device>/size
>      7. Run blockdev --getsize again (no change in size reported)
>      8. Inactivate the LV (there are now no longer any openers on the
>         block device)
>      9. Run blockdev --getsize again.  Size is now correct as there are
>         no openers on the device when blockdev is run.
> 
> This problem has been reported before at:
> 
>   http://lkml.org/lkml/2007/7/3/83
> 
> The following patch is a suggestion on how to fix this problem.  It is
> not a complete solution as it is probably a bad thing to change other
> openers device size without at least protecting the change with a lock.
> And user-apps and other sub-systems might not like the reported device
> size being changed underneath them. It looks like the following
> sub-systems access this value:
> 
> ndb
> dm
> md
> affs
> hfs
> jfs
> reiserfs
> udf
> 
> 
> 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.
> 
> Andrew Patterson
> 
> 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.

Presumably increasing the device size will cause les problems than
decreasing it would.  Do we even support device shrinking?

> 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.

  reply	other threads:[~2008-04-15 23:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-09 23:29 bdev size not updated correctly after underlying device is resized Andrew Patterson
2008-04-09 23:29 ` Andrew Patterson
2008-04-15 23:03 ` Andrew Morton [this message]
2008-04-15 23:21   ` Andrew Patterson
2008-04-16 21:59     ` Andrew Patterson
2008-04-16 23:54       ` James Bottomley
2008-04-17 15:49         ` Andrew Patterson

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=20080415160314.11e9b7e1.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=andmike@linux.vnet.ibm.com \
    --cc=andrew.patterson@hp.com \
    --cc=axboe@kernel.dk \
    --cc=dm-devel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.