From: Dave Chinner <david@fromorbit.com>
To: Wendy Cheng <s.wendy.cheng@gmail.com>,
Ric Wheeler <ricwheeler@gmail.com>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
device-mapper development <dm-devel@redhat.com>,
Karel Zak
Subject: Re: [dm-devel] generic wrappers for multi-device FS operations
Date: Thu, 10 Mar 2011 08:36:29 +1100 [thread overview]
Message-ID: <20110309213629.GV15097@dastard> (raw)
In-Reply-To: <20110309142325.GA11312@agk-dp.fab.redhat.com>
On Wed, Mar 09, 2011 at 02:23:26PM +0000, Alasdair G Kergon wrote:
> On Tue, Mar 08, 2011 at 10:05:40AM -0800, Wendy Cheng wrote:
> > So the "resize" is on the filesystem, not the volume ? The "grow" part
> > is probably easy. Unfortunately, the "shrink" may not be easy for some
> > of the filesystems:
>
> The LVM situation today works both ways around.
>
> You can use 'lvresize' with an option to resize the filesystem too,
> or use 'fsadm' with an option to resize the LV. We felt that 'fsadm'
> was a more-natural approach: allow the user to resize their filesystem
> and automatically adjust the things underneath as necessary.
>
> Long term, we'd like it to be possible to configure a system for resizing
> entire device stacks both top down (fsadm) and bottom up (triggered by the
> appropriate Unit Attention).
I can see how this would be advantageous from a management
perspective for growing LVM pools, but I can see quite a few
problems with extending that to automatically growing filesystems
above LVM. e.g. The LUN resizes, the PV is expanded, the VG is
expanded, but which LV in the VG is going to make use the new space?
Similarly, you can't safely shrink a filesystem from the bottom up -
the filesystem has to empty the space first before it is safe to
shrink it. How would you handle this from a bottom-up driven
change?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2011-03-09 21:36 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-08 17:04 generic wrappers for multi-device FS operations Ric Wheeler
2011-03-08 17:43 ` [dm-devel] " Alasdair G Kergon
2011-03-08 18:05 ` Wendy Cheng
2011-03-08 18:13 ` Ric Wheeler
2011-03-08 18:34 ` James Bottomley
2011-03-08 18:51 ` Ric Wheeler
2011-03-08 20:16 ` Lars Marowsky-Bree
2011-03-08 18:37 ` Josef Bacik
2011-03-08 18:51 ` Ric Wheeler
2011-03-09 14:23 ` Alasdair G Kergon
2011-03-09 15:13 ` Ric Wheeler
2011-03-10 15:28 ` Hannes Reinecke
2011-03-10 15:30 ` Ric Wheeler
2011-03-09 21:36 ` Dave Chinner [this message]
2011-03-09 21:49 ` Alasdair G Kergon
2011-03-10 5:04 ` Dave Chinner
2011-03-08 20:54 ` Andreas Dilger
2011-03-08 20:58 ` Ric Wheeler
2011-03-09 2:11 ` Dave Chinner
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=20110309213629.GV15097@dastard \
--to=david@fromorbit.com \
--cc=dm-devel@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=ricwheeler@gmail.com \
--cc=s.wendy.cheng@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).