From: Andrew Patterson <andrew.patterson@hp.com>
To: linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk,
dm-devel@redhat.com
Cc: axboe@kernel.dk, viro@zeniv.linux.org.uk, andmike@linux.vnet.ibm.com
Subject: bdev size not updated correctly after underlying device is resized
Date: Wed, 09 Apr 2008 17:29:42 -0600 [thread overview]
Message-ID: <1207783782.31821.80.camel@bluto.andrew> (raw)
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.
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);
next reply other threads:[~2008-04-09 23:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-09 23:29 Andrew Patterson [this message]
2008-04-15 23:03 ` bdev size not updated correctly after underlying device is resized Andrew Morton
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=1207783782.31821.80.camel@bluto.andrew \
--to=andrew.patterson@hp.com \
--cc=andmike@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox