On Wed, Aug 14, 2013 at 07:06:44AM +0200, Felipe Monteiro de Carvalho wrote: > > Did my last message go through? Just wondering if it was lost ... I think part of the problem (besids lots of people being busy and on vacation) is it's not clear what your ext4 reader is going to be used for. As a result it's hard to give advice, not knowing what the requirements are for said reader. > > EXT4_FEATURE_INCOMPAT_COMPRESSION = $0001; Compression isn't implemeneted, and so I'd suggest not trying to assume anything the file system with this feature. > > EXT4_FEATURE_INCOMPAT_FILETYPE = $0002; This would be true only if you are properly handling the name_len in the direct structure. (It is a 16 bit Little Endian element, but only the low 8 bits are the name length; the high 8 bits are for the file type). > > EXT4_FEATURE_INCOMPAT_RECOVER = $0004; // Needs recovery */ If you are not doing journal replay, you should *not* try to handle a file system with the needs recovery bit set. > > EXT4_FEATURE_INCOMPAT_BG_USE_META_CSUM= $2000; // use crc32c for bg */ If you're going to ignore potential checksum errors in the metadata.... > > But I now wonder about these features: > > > > EXT4_FEATURE_INCOMPAT_MMP = $0100; This is used to protect against multiple systems trying to access a shared block device. If you are not supporting the MMP protocol, it's possible for the metadata blocks on a shared block device to be changing out from under you, with potentially hilarious (if you find kernel oops or file system reader crashes funny) results. > > EXT4_FEATURE_INCOMPAT_EA_INODE = $0400; // EA in inode */ > > EXT4_FEATURE_INCOMPAT_DIRDATA = $1000; // data in dirent */ > > EXT4_FEATURE_INCOMPAT_LARGEDIR = $4000; // >2GB or 3-lvl htree */ > > EXT4_FEATURE_INCOMPAT_INLINEDATA = $8000; // data in inode */ These features aren't quite fully supported yet. The inline data feature is probably closest to be being fully supported, when we release an the next major version of e2fsprogs. > > And also which ones require an active work for a reader application to > > implement. As I already found out that FLEX_BG does not require active > > work to be supported despite being in the INCOMPAT list... A lot of whether changes are needed to a file system implementation depends on how carefully and robustly it had been written in the first place. Flex_bg had to be an incompat feature because the Linux kernel implementation was checking certain invariants which flex_bg would have violated. If you have an implementation that isn't checking for various metadata inconsistenties or errors, it might not matter. By the way, depending on what your propietary reader is going to be used for, you might want to consider using an fsfuzzer to make sure it handles subtly corrupted file systems in a sane way. If not (again depending on how oyu use it), you could end up crashing your system (if this mysterious proprietary reader is part of some OS) or potentially causing a security breach (buffer overruns, anyway? :-) Cheers, - 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
