On Wed, Oct 03, 2007 at 11:05:05AM +1000, Barry Naujok wrote:

On Tue, 02 Oct 2007 19:19:51 +1000, David Chinner [off-list ref] wrote:

quoted

On Tue, Oct 02, 2007 at 10:02:16AM +0100, Christoph Hellwig wrote:

quoted

On Tue, Oct 02, 2007 at 05:08:59PM +1000, Barry Naujok wrote:

quoted

The attached tool allows an inode64 filesystem to be converted to  

inode32.

quoted

For this to work, the filesystem has to be mounted inode32 before  

it's run.

quoted

I'm not sure if there is any packaging changes required.

Together with the stop allocating from specific AGs patch this should be
90% towards an xfs_shrinkfs, right?

Well, this just moves the inodes - it's one piece of the puzzle.  We
still need to collide xfs_fsr with xfs_reno to move the data.

After that, we need to work out how to move the orphan metadata
blocks out of the AGs that are to be truncated off. That's not
simple....

I believe xfs_bmap on all inodes can reveal extended attributes and
directory data in extra AGs. Copying those like xfs_reno does with
"blocked" AGs should perform the desired metadata moving.

Sure. But I'm thinking of metadata like the blocks in an extent
btree that indexes the data or attribute fork of an inode. I don't
think xfs_bmap can tell us where those blocks are, and they could
be anywhere on the filesystem...

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group