I've been busy working on extents support in e2fsck, and so as part of that I was looking at the clusterfs extent patches (mostly for inspiration to see how they work). One of the things which I noticed is the patches seem to check the inode direct blocks, and if they look like the extent header, but the EXTENTS_FL flag isn't set, it flags this as an error. 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. Not a problem for people who are using it for testing, but if anyone is using these patches in production (such as Gentoo, cough, who is shipping the patches), I thought I should give a warning --- these patches are not ready for prime-time, and anyone who wants to use it production will probably want to take out that particular check. - 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
