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
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
