On Tue, Apr 10, 2007 at 10:22:20PM -0600, Andreas Dilger wrote: > On Apr 10, 2007 23:40 -0400, Theodore Tso wrote: > > Also note that providing a > > script which generates the test filesystem is now preferred to > > including an image.gz file; it avoids the need for binary patches, and > > it makes it clearer how the test filesystem is constructed. > > Agreed, though in some cases it is considerably easier to produce the > corruption via binary editing than debugfs commands unless there are > now facilities to copy blocks/bytes around within the filesystem? Yes, there are still some facilities that could be added to make life more convenient. 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. A facility to set a specific range of bytes, or copy a range of bytes from one block/offset to another (to simulate a disk controller hiccup) is definitely not a bad idea. Maybe something like this? write_data_bytes <block>/<offset> <hex string> write_data_ascii <block>/<offset> <ascii string> copy_data_bytes <block/offset> <block/offset> <count> > > +set_inode_field /dir/foo block[0] 30 > > +set_inode_field /dir2/bar block[0] 30 > > +set_inode_field /dir3/baz block[0] 30 > > +set_inode_field /dir/fee block[0] 34 > > +set_inode_field /dir2/fie block[0] 34 > > +set_inode_field /dir3/foe block[0] 34 > > Also, items such as these presuppose that the directory has specific > blocks allocated to it, which need the test case to be constructed in > multiple passes (to extract these numbers) and could break at some time > in the future. 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. 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. 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.... :-) - Ted - 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
