generic wrappers for multi-device FS operations

generic wrappers for multi-device FS operations

[Ric Wheeler]

After seeing some of the feedback and confusion that happened in the fedora 
community after Josef suggestion that we default to btrfs in an upcoming Fedora 
release, it became clear to me that many users are incredibly unaware of the 
common features that we have across file systems today given LVM/device mapper 
support.

btrfs will make multi-volume/multi-disk operations common place and easy to do, 
but there is no reason not to do most/all of this today with ext4, xfs, etc on 
top of lvm.

To make this trivial to do for users, I think that it would be really nice to 
have a two-level wrappers for things like resize, add a volume, shrink, etc. 
Similar to the way we have mount or fsck invoke file system specific bits.

Good idea? Bad idea?

Thanks!

Ric

Re: [dm-devel] generic wrappers for multi-device FS operations

[Alasdair G Kergon]

On Tue, Mar 08, 2011 at 12:04:25PM -0500, Ric Wheeler wrote:
> To make this trivial to do for users, I think that it would be really 
> nice to have a two-level wrappers for things like resize, add a volume, 
> shrink, etc. Similar to the way we have mount or fsck invoke file system 
> specific bits.
> Good idea? Bad idea?

We began this within LVM some time ago with a script we called 'fsadm'.

http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/LVM2/scripts/fsadm.sh?rev=1.24&content-type=text/plain&cvsroot=lvm2&f=h

Alasdair


fsadm: Utility to resize or check the filesystem on a device

  fsadm [options] check device
    - Check the filesystem on device using fsck

  fsadm [options] resize device [new_size[BKMGTPE]]
    - Change the size of the filesystem on device to new_size

  Options:
    -h | --help         Show this help message
    -v | --verbose      Be verbose
    -e | --ext-offline  unmount filesystem before ext2/ext3/ext4 resize
    -f | --force        Bypass sanity checks
    -n | --dry-run      Print commands without running them
    -l | --lvresize     Resize given device (if it is LVM device)
    -y | --yes          Answer "yes" at any prompts

  new_size - Absolute number of filesystem blocks to be in the filesystem,
             or an absolute size using a suffix (in powers of 1024).
             If new_size is not supplied, the whole device is used.

Re: [dm-devel] generic wrappers for multi-device FS operations

[Wendy Cheng]

> On Tue, Mar 08, 2011 at 12:04:25PM -0500, Ric Wheeler wrote:
>> To make this trivial to do for users, I think that it would be really
>> nice to have a two-level wrappers for things like resize, add a volume,
>> shrink, etc. Similar to the way we have mount or fsck invoke file system
>> specific bits.
>> Good idea? Bad idea?
>

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:

-- Wendy

Re: [dm-devel] generic wrappers for multi-device FS operations

[Ric Wheeler]

On 03/08/2011 01:05 PM, Wendy Cheng wrote:
>> On Tue, Mar 08, 2011 at 12:04:25PM -0500, Ric Wheeler wrote:
>>> To make this trivial to do for users, I think that it would be really
>>> nice to have a two-level wrappers for things like resize, add a volume,
>>> shrink, etc. Similar to the way we have mount or fsck invoke file system
>>> specific bits.
>>> Good idea? Bad idea?
> 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:
>
> -- Wendy

I think any "standard" operation would be allowed to fail with "notsupported" 
effectively. Shrink is definitely a challenge & even when it works, it often has 
performance implications.

I think that adding support to fsadm might be the easy path forward, but we 
would need to be able to do at least a handful of more advanced things (add a 
whole device for example).

Ric

Re: [dm-devel] generic wrappers for multi-device FS operations

[James Bottomley]

On Tue, 2011-03-08 at 13:13 -0500, Ric Wheeler wrote:
> On 03/08/2011 01:05 PM, Wendy Cheng wrote:
> >> On Tue, Mar 08, 2011 at 12:04:25PM -0500, Ric Wheeler wrote:
> >>> To make this trivial to do for users, I think that it would be really
> >>> nice to have a two-level wrappers for things like resize, add a volume,
> >>> shrink, etc. Similar to the way we have mount or fsck invoke file system
> >>> specific bits.
> >>> Good idea? Bad idea?
> > 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:
> >
> > -- Wendy
> 
> I think any "standard" operation would be allowed to fail with "notsupported" 
> effectively. Shrink is definitely a challenge & even when it works, it often has 
> performance implications.
> 
> I think that adding support to fsadm might be the easy path forward, but we 
> would need to be able to do at least a handful of more advanced things (add a 
> whole device for example).

There's still the problem of moving the underlying device from being a
plain block device to being a dm one ... what happened to the idea of
presenting all devices as dm ones to solve this?

James

Re: [dm-devel] generic wrappers for multi-device FS operations

[Josef Bacik]

On Tue, Mar 08, 2011 at 10:05:40AM -0800, Wendy Cheng wrote:
> > On Tue, Mar 08, 2011 at 12:04:25PM -0500, Ric Wheeler wrote:
> >> To make this trivial to do for users, I think that it would be really
> >> nice to have a two-level wrappers for things like resize, add a volume,
> >> shrink, etc. Similar to the way we have mount or fsck invoke file system
> >> specific bits.
> >> Good idea? Bad idea?
> >
> 
> 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:
>

Who wants to make their fs smaller anyway?  ;)

Josef 

Re: [dm-devel] generic wrappers for multi-device FS operations

[Ric Wheeler]

On 03/08/2011 01:37 PM, Josef Bacik wrote:
> On Tue, Mar 08, 2011 at 10:05:40AM -0800, Wendy Cheng wrote:
>>> On Tue, Mar 08, 2011 at 12:04:25PM -0500, Ric Wheeler wrote:
>>>> To make this trivial to do for users, I think that it would be really
>>>> nice to have a two-level wrappers for things like resize, add a volume,
>>>> shrink, etc. Similar to the way we have mount or fsck invoke file system
>>>> specific bits.
>>>> Good idea? Bad idea?
>> 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:
>>
> Who wants to make their fs smaller anyway?  ;)
>
> Josef

I have been surprised more than once by customers who do this on a regular basis :)

Ric

Re: [dm-devel] generic wrappers for multi-device FS operations

[Ric Wheeler]

On 03/08/2011 01:34 PM, James Bottomley wrote:
> On Tue, 2011-03-08 at 13:13 -0500, Ric Wheeler wrote:
>> On 03/08/2011 01:05 PM, Wendy Cheng wrote:
>>>> On Tue, Mar 08, 2011 at 12:04:25PM -0500, Ric Wheeler wrote:
>>>>> To make this trivial to do for users, I think that it would be really
>>>>> nice to have a two-level wrappers for things like resize, add a volume,
>>>>> shrink, etc. Similar to the way we have mount or fsck invoke file system
>>>>> specific bits.
>>>>> Good idea? Bad idea?
>>> 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:
>>>
>>> -- Wendy
>> I think any "standard" operation would be allowed to fail with "notsupported"
>> effectively. Shrink is definitely a challenge&  even when it works, it often has
>> performance implications.
>>
>> I think that adding support to fsadm might be the easy path forward, but we
>> would need to be able to do at least a handful of more advanced things (add a
>> whole device for example).
> There's still the problem of moving the underlying device from being a
> plain block device to being a dm one ... what happened to the idea of
> presenting all devices as dm ones to solve this?
>
> James

I think that would certainly be a nice start, but we could do something short 
term that did not require that.

Ric

Re: [dm-devel] generic wrappers for multi-device FS operations

[Lars Marowsky-Bree]

On 2011-03-08T12:34:34, James Bottomley <James.Bottomley@suse.de> wrote:

> There's still the problem of moving the underlying device from being a
> plain block device to being a dm one ... what happened to the idea of
> presenting all devices as dm ones to solve this?

Giving remapping abilities to every block device certainly would be
extremly useful.


Regards,
    Lars

-- 
Architect Storage/HA, OPS Engineering, Novell, Inc.
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: generic wrappers for multi-device FS operations

[Andreas Dilger]

On 2011-03-08, at 10:04 AM, Ric Wheeler wrote:
> After seeing some of the feedback and confusion that happened in the fedora community after Josef suggestion that we default to btrfs in an upcoming Fedora release, it became clear to me that many users are incredibly unaware of the common features that we have across file systems today given LVM/device mapper support.
> 
> btrfs will make multi-volume/multi-disk operations common place and easy to do, but there is no reason not to do most/all of this today with ext4, xfs, etc on top of lvm.
> 
> To make this trivial to do for users, I think that it would be really nice to have a two-level wrappers for things like resize, add a volume, shrink, etc. Similar to the way we have mount or fsck invoke file system specific bits.

I definitely think this makes sense.  However, taking a quick look at fsadm,
I don't think it is the right starting point for this work.  It is essentially
a single script that is special-casing each filesystem it is touching, which
makes it a maintenance nightmare to add in support for different filesystems.

A better structure is the mkfs.* and fsck.* tools that extend the basic
mkfs/fsck functionality for each new filesystem.  That allows new filesystems
to be added without the requirement to modify the upstream fsadm script.


Another tool similar to this that I've been trying to push upstream for some
time is the "lvcheck" script, which is essentially a wrapper for online
filesystem checking.  It is currently structured as an extension to the LVM
tools, since it depends on creating a snapshot of an LV and does a check on
the snapshot.  If the snapshot is clean the original filesystem is marked
checked as well, which avoids the "slow ext* check on boot" problem, while
still ensuring that periodic filesystem checks will catch latent errors.

It wouldn't be unreasonable to have a new wrapper for online filesystem
checking (e.g. ofsck) or just an extension to fsck that does this in a more
"plug-in" manner like fsck.* does today.  It would naturally progress into
real online checking for filesystems that support this (e.g. btrfs, and I
think XFS is going in this direction as well).

Cheers, Andreas

Re: generic wrappers for multi-device FS operations

[Ric Wheeler]

On 03/08/2011 03:54 PM, Andreas Dilger wrote:
> On 2011-03-08, at 10:04 AM, Ric Wheeler wrote:
>> After seeing some of the feedback and confusion that happened in the fedora community after Josef suggestion that we default to btrfs in an upcoming Fedora release, it became clear to me that many users are incredibly unaware of the common features that we have across file systems today given LVM/device mapper support.
>>
>> btrfs will make multi-volume/multi-disk operations common place and easy to do, but there is no reason not to do most/all of this today with ext4, xfs, etc on top of lvm.
>>
>> To make this trivial to do for users, I think that it would be really nice to have a two-level wrappers for things like resize, add a volume, shrink, etc. Similar to the way we have mount or fsck invoke file system specific bits.
> I definitely think this makes sense.  However, taking a quick look at fsadm,
> I don't think it is the right starting point for this work.  It is essentially
> a single script that is special-casing each filesystem it is touching, which
> makes it a maintenance nightmare to add in support for different filesystems.
>
> A better structure is the mkfs.* and fsck.* tools that extend the basic
> mkfs/fsck functionality for each new filesystem.  That allows new filesystems
> to be added without the requirement to modify the upstream fsadm script.

I do like the two level scheme that mkfs.* and fsck.* use - same interface 
largely regardless of the file system and the ability to customize the fs 
specific command as needed.

>
> Another tool similar to this that I've been trying to push upstream for some
> time is the "lvcheck" script, which is essentially a wrapper for online
> filesystem checking.  It is currently structured as an extension to the LVM
> tools, since it depends on creating a snapshot of an LV and does a check on
> the snapshot.  If the snapshot is clean the original filesystem is marked
> checked as well, which avoids the "slow ext* check on boot" problem, while
> still ensuring that periodic filesystem checks will catch latent errors.
>
> It wouldn't be unreasonable to have a new wrapper for online filesystem
> checking (e.g. ofsck) or just an extension to fsck that does this in a more
> "plug-in" manner like fsck.* does today.  It would naturally progress into
> real online checking for filesystems that support this (e.g. btrfs, and I
> think XFS is going in this direction as well).
>
> Cheers, Andreas

Online fsck would certainly be a win & would make a lot of users happy,

Ric

Re: generic wrappers for multi-device FS operations

[Dave Chinner]

On Tue, Mar 08, 2011 at 01:54:37PM -0700, Andreas Dilger wrote:
> On 2011-03-08, at 10:04 AM, Ric Wheeler wrote:
> > After seeing some of the feedback and confusion that happened in the fedora community after Josef suggestion that we default to btrfs in an upcoming Fedora release, it became clear to me that many users are incredibly unaware of the common features that we have across file systems today given LVM/device mapper support.
> > 
> > btrfs will make multi-volume/multi-disk operations common place and easy to do, but there is no reason not to do most/all of this today with ext4, xfs, etc on top of lvm.
> > 
> > To make this trivial to do for users, I think that it would be really nice to have a two-level wrappers for things like resize, add a volume, shrink, etc. Similar to the way we have mount or fsck invoke file system specific bits.
> 
> I definitely think this makes sense.  However, taking a quick look at fsadm,
> I don't think it is the right starting point for this work.  It is essentially
> a single script that is special-casing each filesystem it is touching, which
> makes it a maintenance nightmare to add in support for different filesystems.
> 
> A better structure is the mkfs.* and fsck.* tools that extend the basic
> mkfs/fsck functionality for each new filesystem.  That allows new filesystems
> to be added without the requirement to modify the upstream fsadm script.

That seems like a sensible approach to me, however handling the
different volumes could be trouble. e.g. the top level app would
still need to know about the difference between log devices and data
devices for XFS/ext3/ext4, realtime devices for XFS (as they can be
grown separately to the data device but as still part of the same
filesystem), while for btrfs just uses generic block devices, pools
and volumes....

> Another tool similar to this that I've been trying to push upstream for some
> time is the "lvcheck" script, which is essentially a wrapper for online
> filesystem checking.  It is currently structured as an extension to the LVM
> tools, since it depends on creating a snapshot of an LV and does a check on
> the snapshot.  If the snapshot is clean the original filesystem is marked
> checked as well, which avoids the "slow ext* check on boot" problem, while
> still ensuring that periodic filesystem checks will catch latent errors.

I think this is very different to the well defined operations of
growing and shrinking filesystems and block devices.

Checking snapshots isn't really "online" checking at all - it's
generating a temporary stable image of the filesystem that is used
for an offline check. If anything is found wrong, you've still got
to take the fs offline and run the offline repair program.

As it is, dm-snapshot based checking really isn't a solution that
can be employed in production environments with performance SLAs or
that require sustained high performance because of the performance
hit the COW based snapshot mechanism causes while there are active
snapshots. And that's before considering the impact of all the IO
the check process would issue...

> It wouldn't be unreasonable to have a new wrapper for online filesystem
> checking (e.g. ofsck) or just an extension to fsck that does this in a more
> "plug-in" manner like fsck.* does today.  It would naturally progress into
> real online checking for filesystems that support this (e.g. btrfs, and I
> think XFS is going in this direction as well).

Online filesystem scrubbing and repair is highly filesystem
specific, just like offline repair is. It can't be easily separated
from the kernel code because of the need to be coherent with
current operations.

My current line of thinking is that for XFS it would be an entirely
in-kernel operation in combination with a scrubber and additional
on-disk metadata structures (such as an rmap btree) to make the
operation of the scrubber as efficient as possible. The scrubber
would run in the background and trigger repair of problems it
encounters, with extra triggers for when normal operation encounter
corruption problems. i.e. check and reapir with no specific external
userspace control or intervention.

IOWs, until we actually have real online repair implemented in more
than one filesystem and can determine similarites in their
operation, I think trying to develop a generic interface for them
is premature....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: [dm-devel] generic wrappers for multi-device FS operations

[Alasdair G Kergon]

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).
 
(The current fsadm script was written as a proof-of-concept under the
constraint of just wrapping existing binaries. Of course there are cleaner
ways to do it when you allow filesystem-specific code.)

Alasdair

Re: [dm-devel] generic wrappers for multi-device FS operations

[Ric Wheeler]

On 03/09/2011 09:23 AM, 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).
>
> (The current fsadm script was written as a proof-of-concept under the
> constraint of just wrapping existing binaries. Of course there are cleaner
> ways to do it when you allow filesystem-specific code.)
>
> Alasdair

Is anyone actively looking at taken it beyond proof of concept?

Ric

Re: [dm-devel] generic wrappers for multi-device FS operations

[Dave Chinner]

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

Re: [dm-devel] generic wrappers for multi-device FS operations

[Alasdair G Kergon]

On Thu, Mar 10, 2011 at 08:36:29AM +1100, Dave Chinner wrote:
> 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?
 
You'd handle that by configuration settings under sysadmin control.
There are plenty of situations where there would be an 'obvious' LV 
to extend.

> 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?
 
Obviously there are limits, and passing a message "Prepare to
be made smaller by X" up the stack probably isn't very feasible.

Alasdair

Re: [dm-devel] generic wrappers for multi-device FS operations

[Dave Chinner]

On Wed, Mar 09, 2011 at 09:49:28PM +0000, Alasdair G Kergon wrote:
> On Thu, Mar 10, 2011 at 08:36:29AM +1100, Dave Chinner wrote:
> > 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?
>  
> You'd handle that by configuration settings under sysadmin control.

So you have to set it up ahead of time, and then remember that you
have set it up to automatically expand LV X when PV Y expands
because device Z was expanded.

> There are plenty of situations where there would be an 'obvious' LV 
> to extend.

Sure, but that's the easy case. My concern is always the hard cases
- what to do when there isn't an obvious LV to expand, or you want
an LV that isn't the obvious or configured LV to expand when the
PV is grown, or you just want to grow the PV ready to add new LVs
rather than expand an LV....

> > 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?
>  
> Obviously there are limits, and passing a message "Prepare to
> be made smaller by X" up the stack probably isn't very feasible.

Agreed, especially as it can take hours of IO before an "ok to be
made smaller now " message can be sent or the attempt to shrink the
filesystem fails...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: [dm-devel] generic wrappers for multi-device FS operations

[Hannes Reinecke]

On 03/09/2011 04:13 PM, Ric Wheeler wrote:
> On 03/09/2011 09:23 AM, 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).
>>
>> (The current fsadm script was written as a proof-of-concept under the
>> constraint of just wrapping existing binaries. Of course there are
>> cleaner
>> ways to do it when you allow filesystem-specific code.)
>>
>> Alasdair
> 
> Is anyone actively looking at taken it beyond proof of concept?
> 
I'm working on the kernel-side parts, namely pushing unit attention
events out to userspace via debugfs.
There'll be daemon reading those and eventually triggering the
appropriate action.

We could hold a BoF at LSF or Collab summit, seeing that there is
quite some interest in these kind of things.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [dm-devel] generic wrappers for multi-device FS operations

[Ric Wheeler]

On 03/10/2011 10:28 AM, Hannes Reinecke wrote:
> On 03/09/2011 04:13 PM, Ric Wheeler wrote:
>> On 03/09/2011 09:23 AM, 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).
>>>
>>> (The current fsadm script was written as a proof-of-concept under the
>>> constraint of just wrapping existing binaries. Of course there are
>>> cleaner
>>> ways to do it when you allow filesystem-specific code.)
>>>
>>> Alasdair
>> Is anyone actively looking at taken it beyond proof of concept?
>>
> I'm working on the kernel-side parts, namely pushing unit attention
> events out to userspace via debugfs.
> There'll be daemon reading those and eventually triggering the
> appropriate action.
>
> We could hold a BoF at LSF or Collab summit, seeing that there is
> quite some interest in these kind of things.
>
> Cheers,
>
> Hannes

I think that the idea of a BOF would be great - probably more room/time at 
collab given the schedule of LSF at this point,

Ric