From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alasdair G Kergon Subject: Re: [dm-devel] generic wrappers for multi-device FS operations Date: Wed, 9 Mar 2011 21:49:28 +0000 Message-ID: <20110309214927.GI11312@agk-dp.fab.redhat.com> References: <4D766199.4010307@gmail.com> <20110308174308.GP10767@agk-dp.fab.redhat.com> <20110309142325.GA11312@agk-dp.fab.redhat.com> <20110309213629.GV15097@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: device-mapper development , Wendy Cheng , Ric Wheeler , Linux FS Devel , Karel Zak Return-path: Received: from mx1.redhat.com ([209.132.183.28]:28555 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751529Ab1CIVtl (ORCPT ); Wed, 9 Mar 2011 16:49:41 -0500 Content-Disposition: inline In-Reply-To: <20110309213629.GV15097@dastard> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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