All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Kevin Corry <kevcorry@us.ibm.com>
Cc: thornber@sistina.com, linux-kernel@vger.kernel.org
Subject: Re: online resizing of devices/filesystems (2.6)
Date: Fri, 17 Oct 2003 13:05:43 -0700	[thread overview]
Message-ID: <20031017130543.0e01d862.akpm@osdl.org> (raw)
In-Reply-To: <200310171116.07362.kevcorry@us.ibm.com>

Kevin Corry <kevcorry@us.ibm.com> wrote:
>
> On August 21, 2003, Joe Thornber wrote:
> > Hi,
> > 
> > Should genhd.h:set_capacity() find and update the i_size field of the
> > inode for the device ?
> > 
> > The BLKGETSIZE and BLKGETSIZE64 ioctls report the size in the devices
> > inode:
> > 
> > 	case BLKGETSIZE:
> > 		if ((bdev->bd_inode->i_size >> 9) > ~0UL)
> > 			return -EFBIG;
> > 		return put_ulong(arg, bdev->bd_inode->i_size >> 9);
> > 	case BLKGETSIZE64:
> > 		return put_u64(arg, bdev->bd_inode->i_size);
> > 
> > Currently people have to close and reopen the device in order for a
> > size change to take effect.  This is a problem if people want to do
> > online resizing of a filesystem (supported by xfs and resier).
> 
> Has anyone had any thoughts about this issue?

Resizing a blockdev while someone has a filesystem mounted on it is a bit
rude, but I guess that as long as it is being expanded, not much can go
wrong.

bd_set_size() isn't quite what you want because it fiddles with the
blocksize as well.

So one approach would be to do what NBD does, and just write i_size directly.

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 ;)


  reply	other threads:[~2003-10-17 20:05 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 [this message]
2003-10-17 20:49   ` Kevin Corry
2003-10-17 21:42     ` Kevin Corry
  -- 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=20031017130543.0e01d862.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=kevcorry@us.ibm.com \
    --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.