xfs
[Top] [All Lists]

Re: REVIEW: xfs_reno

To: "David Chinner" <dgc@xxxxxxx>, "Christoph Hellwig" <hch@xxxxxxxxxxxxx>
Subject: Re: REVIEW: xfs_reno
From: "Barry Naujok" <bnaujok@xxxxxxx>
Date: Wed, 03 Oct 2007 11:05:05 +1000
Cc: "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>, xfs-dev <xfs-dev@xxxxxxx>
In-reply-to: <20071002091951.GE995458@xxxxxxx>
Organization: SGI
References: <op.tzj549h63jf8g2@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20071002090216.GA22721@xxxxxxxxxxxxx> <20071002091951.GE995458@xxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Opera Mail/9.10 (Win32)
On Tue, 02 Oct 2007 19:19:51 +1000, David Chinner <dgc@xxxxxxx> 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.

After that, we need the transaction to shrink the fs.

At that point, we'll got a "working" shrink that will allow
shrinking to only 50% of the original size because the log will
get in the way. To fix that, we'll need to implement transactions
to move the log...

Cheers,

Dave.



<Prev in Thread] Current Thread [Next in Thread>