From: Kevin Corry <kevcorry@us.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: thornber@sistina.com, linux-kernel@vger.kernel.org
Subject: Re: online resizing of devices/filesystems (2.6)
Date: Fri, 17 Oct 2003 16:42:32 -0500 [thread overview]
Message-ID: <200310171642.32064.kevcorry@us.ibm.com> (raw)
In-Reply-To: <200310171549.44589.kevcorry@us.ibm.com>
On Friday 17 October 2003 15:49, Kevin Corry wrote:
> On Friday 17 October 2003 15:05, Andrew Morton wrote:
> > So one approach would be to do what NBD does, and just write i_size
> > directly.
>
> We had considered that originally. It just seemed like too big of a hack.
> :) Plus I wasn't sure if there were locking issues with changing fields in
> the inode.
>
> > You could create a little helper library function which takes i_sem and
> > then writes i_size. But the VFS tends to avoid taking i_sem on blockdevs
> > because it doesn't expect i_size to change ;)
>
> So...should I take i_sem or not? :) Perhaps calling i_size_write() in
> include/linux/fs.h would be preferrable, since it seems to be doing
> different things for SMP and preempt.
>
> Thanks for the feedback!
Here's a patch that takes bdev->bd_inode->i_sem, and then calls
i_size_write() to update the inode size. My initial tests have been
successful in resizing mounted reiser and xfs filesystems on
2.6.0-test7.
--
Kevin Corry
kevcorry@us.ibm.com
http://evms.sourceforge.net/
When setting the size of a Device-Mapper device in the gendisk entry, also try
to set the size of the corresponding block_device entry's inode. This is
necessary to allow online device/filesystem resizing to work correctly.
--- a/drivers/md/dm.c 9 Oct 2003 16:47:44 -0000
+++ b/drivers/md/dm.c 17 Oct 2003 21:06:01 -0000
@@ -726,6 +726,20 @@
up_write(&md->lock);
}
+static void __set_size(struct gendisk *disk, sector_t size)
+{
+ struct block_device *bdev;
+
+ set_capacity(disk, size);
+ bdev = bdget_disk(disk, 0);
+ if (bdev) {
+ down(&bdev->bd_inode->i_sem);
+ i_size_write(bdev->bd_inode, size << SECTOR_SHIFT);
+ up(&bdev->bd_inode->i_sem);
+ bdput(bdev);
+ }
+}
+
static int __bind(struct mapped_device *md, struct dm_table *t)
{
request_queue_t *q = md->queue;
@@ -733,7 +747,7 @@
md->map = t;
size = dm_table_get_size(t);
- set_capacity(md->disk, size);
+ __set_size(md->disk, size);
if (size == 0)
return 0;
next prev parent reply other threads:[~2003-10-17 21:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-17 16:16 online resizing of devices/filesystems (2.6) Kevin Corry
2003-10-17 20:05 ` Andrew Morton
2003-10-17 20:49 ` Kevin Corry
2003-10-17 21:42 ` Kevin Corry [this message]
-- 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=200310171642.32064.kevcorry@us.ibm.com \
--to=kevcorry@us.ibm.com \
--cc=akpm@osdl.org \
--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.