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 14:23:26 +0000 Message-ID: <20110309142325.GA11312@agk-dp.fab.redhat.com> References: <4D766199.4010307@gmail.com> <20110308174308.GP10767@agk-dp.fab.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Wendy Cheng , Ric Wheeler , Linux FS Devel , device-mapper development , Karel Zak Return-path: Received: from mx1.redhat.com ([209.132.183.28]:47226 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751911Ab1CIOXi (ORCPT ); Wed, 9 Mar 2011 09:23:38 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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