Subject: Re: Xfs partition "move" ?
From: Steve Lord <lord@sgi.com>
To: stimits@idcomm.com
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <3C223EBA.92C54144@idcomm.com>
References: <200112201855.fBKIt4X16354@oss.sgi.com>
	<1008873166.30178.0.camel@stout.americas.sgi.com> 
	<3C223EBA.92C54144@idcomm.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 20 Dec 2001 13:45:52 -0600
Message-Id: <1008877552.19431.7.camel@jen.americas.sgi.com>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 2001-12-20 at 13:40, D. Stimits wrote:

> > 
> > growfs only grows on the end of a filesystem, you can't grow the
> > beginning backwards...
> 
> It would probably be ridiculously painful to do, but maybe not, so I'll
> suggest a possible change that might make this possible. Suppose that a
> clean/new XFS partition were added just before the current partition,
> one that in this case started at the first block, and ended just before
> the current partition. A twisted version of growfs could be designed to
> merge the 2nd (tail end) partition into the first. Perhaps it would be
> (with some difficulty) possible to also make a version that consumes the
> earliest inodes first, and adds in the beginning of the old tail
> partition exactly as it consumes the inodes, and only if there is not
> enough space already available from the new head partition without
> consuming the old. The idea being to squeeze as much as possible into
> the newer head partition before consuming the older tail partition,
> making it possible to stop "consumption" before the old tail partition
> is actually complete. This in turn making it possible to arbitrarily cut
> off how much of the tail *must* be consumed and used in the new
> partition...at the end of the process, the user could be asked how much
> of the blank space should be left alone (default to use it all), and how
> much should be chopped off (at the very end). The chopped off part would
> become its own empty XFS partition.
> 


Ugh ugh ugh!

The only problem(s) are:

xfs allocation groups are expected to all be the same size.
Inode numbers include the allocation group number. Inserting at
the beginning would change all inode numbers in the filesystem.

Trust me, you want a memmove type operation which works on disks here.

Steve


-- 

Steve Lord                                      voice: +1-651-683-3511
Principal Engineer, Filesystem Software         email: lord@sgi.com