David Chinner 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....
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...
If we do that could be move to an inode based log?
Keep it contagious so recovery won't have to parse
up the file system to find the log.
The normal running case should be easier to deal with if
the log was just a file?
Cheers,
Dave.
cattelan.vcf
Description: Vcard
|