Re: [PATCH 3/3] e2fsprogs: Support for large inode migration.

["Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>]

Theodore Tso wrote:
> On Thu, Jul 26, 2007 at 05:15:30PM +0530, Aneesh Kumar K.V wrote:
>>> Let me guess, you're testing with a filesystem with two block groups,
>>> right?  And to date you've tested *only* by doubling the size of the
>>> inode.
>> I tested this with multiple ( 1 and 7 ) groups. But yes all the
>> testing was to change inode size from 128 to 256.
> 
> Your patch comments stated "As a part of increasing the inode size we
> throw away the free inodes in the last block group."  This is *only*
> true if the filesystem has two (and exactly two) block groups.  Hence
> my guess that only tested on filesystems with two block groups.
> 

Okey i didn't stress the "last" part in the above sentence. What i wanted
to convey was inodes in the block groups towards the end (well more than one).



> If you tested with larger numbers of block groups, the filesystem must
> have been mostly empty, or at least not a large number of directories,
> or else you would have noticed that most of the time that your
> algorithm wouldn't work.
> 
>> I guess Undo I/O manager can go in because I have been using it for
>> the ext3 -> ext4 inode migration testing and for testing the above patch.
> 
> Well, I really want a valid use case for undo code, and right now the
> above patch is IMHO not suitable for merging into mainline, given all
> of the problems that it has.
> 

What are the issues you see with PATCH 1 and PATCH 2 which implement 
Undo I/O Manager and undoe2fs other than it is not hooked into any of
the existing tools. I will try to add it to mke2fs as you suggested. But
should that prevent it from going in ?


-aneesh