Re: REVIEW: xfs_reno

[David Chinner <dgc@sgi.com>]

On Wed, Oct 03, 2007 at 11:05:05AM +1000, Barry Naujok wrote:
> On Tue, 02 Oct 2007 19:19:51 +1000, David Chinner <dgc@sgi.com> wrote:
> 
> >On Tue, Oct 02, 2007 at 10:02:16AM +0100, Christoph Hellwig wrote:
> >>On Tue, Oct 02, 2007 at 05:08:59PM +1000, Barry Naujok wrote:
> >>>
> >>> The attached tool allows an inode64 filesystem to be converted to  
> >>inode32.
> >>> For this to work, the filesystem has to be mounted inode32 before  
> >>it's run.
> >>>
> >>> 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