On Apr 11, 2007 06:42 -0400, Theodore Tso wrote: > We don't currently have a way to modify indirect blocks > directly (although I may create that soon or patches would be > greatfully accepted :-), and of course there is a similar issue with > extents and extended attributes blocks. Note that as part of the i_extra_isize e2fsck support we are adding functions to manage EAs to libext2fs that could be used as the basis for this. > At the moment I'm assuming that e2fsprogs block allocation algorithms > (which are not as sophisticated as what's in the kernel) aren't going > to be changing. I thought as much myself. > If they change, you're right, they could break the test. > At the minimum I should document where the numbers are coming > from in the test. At least the test would break and any change that caused it could be seen immediately. > I could imagine a debugfs extension where we could do things like: > > set_var $shared_blk /dir4/quux block[0] > set_inode_field /dir/foo block[0] $shared_blk > set_inode_field /dir2/bar block[0] $shared_blk > set_inode_field /dir3/baz block[0] $shared_blk > > Of course the temptation then would be to start adding conditions, > functions, maybe an entire tcl interpreter.... :-) Yes, I thought of this too, and also the "let's build a full interpreted language into debugfs" conclusion. It wouldn't be fatal though - in some cases it would be nice to have debugfs loop over inodes to fix some unusual corruption. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - 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
