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
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
