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