On Sep 15, 2007 21:22 -0400, Theodore Ts'o wrote: > The problem with this is that it's fragile; you could potentially have > an inode that happens to have as its first block something which looks > like the extent magic number, and if the second block passes the extent > validity checks, e2fsck will flag an error --- and if e2fsck is run in > preen mode, it will just set the extent flag without prompting the user > or aborting the boot process. Well, I agree it's possible, but given that it is checking 8 bytes for validity (though only a 2-byte magic) it seems reasonably safe. There are only 5 blocks in the filesystem that could correctly match in this case (though I grant they are low-valued blocks due to little-endian placement of the 16-bit magic). They would have to be allocated as the first block in the file (0x0000f30a, 0x0001f30a, ..., 0x0004f30a) and 3 always-invalid blocks that would have to be allocated as the second block (0x000N0002, 0x000N0003, 0x000N0004). The latter are used as group descriptor and/or bitmap/inode table blocks, so the inode would likely be corrupt as a non-extent inode as well. I'm not terribly worried about it. 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
