On Jul 03, 2008 10:37 -0400, jim owens wrote: >> * FIEMAP_EXTENT_NO_DIRECT >> Direct access to the data in this extent is illegal or will have >> undefined results. > > will confuse and mislead many people. And as Andreas said, > the fe_physical and fe_device can be valid without the ability > to directly access the data. I suggest we call this: > > FIEMAP_EXTENT_NO_BYPASS > > As in "you can't bypass the filesystem" to directly access it. > > Based on what Andreas said the NO_DIRECT (NO_BYPASS) means, > I disagree with these: > >> * FIEMAP_EXTENT_NET >> - This will also set FIEMAP_EXTENT_NO_DIRECT >> The data for this extent is not stored in a locally-accessible device. >> >> * FIEMAP_EXTENT_DATA_COMPRESSED >> - This will also set FIEMAP_EXTENT_NO_DIRECT >> The data in this extent has been compressed by the file system. >> >> * FIEMAP_EXTENT_DATA_ENCRYPTED >> - This will also set FIEMAP_EXTENT_NO_DIRECT >> The data in this extent has been encrypted by the file system. > > None of the above are always NO_DIRECT. Certainly you can > read the raw compressed/encrypted data (a backup program might) > and even a netdev might be accessed if you know how. I don't see that calling this "NO_BYPASS" is significantly different than calling it "NO_DIRECT". You can "bypass" that flag just as easily, the point is that you may get garbage out of it, don't do that. I don't think anyone writing an application will be seriously confused. >> * FIEMAP_EXTENT_NOT_ALIGNED >> Extent offsets and length are not guaranteed to be block aligned. > > To be something like: > > FIEMAP_EXTENT_ENCODED That doesn't make sense either. "NOT_ALIGNED" just means that it isn't a full filesystem block, but it isn't necessarily "encoded" in any way. >> * FIEMAP_EXTENT_DATA_INLINE >> This will also set FIEMAP_EXTENT_NOT_ALIGNED >> Data is located within a meta data block. >> >> * FIEMAP_EXTENT_DATA_TAIL >> This will also set FIEMAP_EXTENT_NOT_ALIGNED >> Data is packed into a block with data from other files. > > With FIEMAP_EXTENT_ENCODED being the top flag set for > FIEMAP_EXTENT_NET, FIEMAP_EXTENT_DATA_COMPRESSED, > FIEMAP_EXTENT_DATA_ENCRYPTED, FIEMAP_EXTENT_DATA_INLINE, > and FIEMAP_EXTENT_DATA_TAIL. Then FIEMAP_EXTENT_NO_BYPASS > may or may not also be set and would say "can I get to > the physical data", and separately "do I need to do > special processing on it" would be FIEMAP_EXTENT_ENCODED. It seems to me that "ENCODED" has no relation to "NET" or "DATA_TAIL" or "DATA_INLINE". >> * FIEMAP_EXTENT_UNWRITTEN >> Unwritten extent - the extent is allocated but it's data has not been >> initialized. This indicates the extent's data will be all zero. > > This should say "will be all zero if read through the filesystem > but the contents are undefined if read directly." That does make sense and should be updated. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
