All of lore.kernel.org
 help / color / mirror / Atom feed
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 15:49:44 -0500	[thread overview]
Message-ID: <200310171549.44589.kevcorry@us.ibm.com> (raw)
In-Reply-To: <20031017130543.0e01d862.akpm@osdl.org>

On Friday 17 October 2003 15:05, Andrew Morton wrote:
> 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.

There's no technical reason why you couldn't shrink as well. But right now we 
don't have any filesystems that support online shrink, so the tools prevent 
that scenario. Online expand is quite common, though.

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

Ok.

> 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!
-- 
Kevin Corry
kevcorry@us.ibm.com
http://evms.sourceforge.net/


  reply	other threads:[~2003-10-17 20:55 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 [this message]
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=200310171549.44589.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.