Mark Fasheh wrote: > * FIEMAP_FLAG_SYNC > If this flag is set, the kernel will sync the file before mapping extents. Is there a reason why fsync() before calling FIEMAP is unsuitable? > * FIEMAP_FLAG_XATTR > If this flag is set, the extents returned will describe the inodes > extended attribute lookup tree, instead of it's data tree. What is this for? The meaning of the xattr tree sounds rather filesystem specific to me. > * FIEMAP_EXTENT_NO_DIRECT > Direct access to the data in this extent is illegal or will have > undefined results. ... > * FIEMAP_EXTENT_NET > - This will also set FIEMAP_EXTENT_NO_DIRECT > The data for this extent is not stored in a locally-accessible device. Does this _always_ set FIEMAP_EXTENT_NO_DIRECT? Some network filesystems do support O_DIRECT access - NFS comes to mind. (I'm assuming 'direct access' means O_DIRECT). > * FIEMAP_EXTENT_DATA_ENCRYPTED > - This will also set FIEMAP_EXTENT_NO_DIRECT > The data in this extent has been encrypted by the file system. I don't think encryption necessarily rules out O_DIRECT. It'll depend how I/O is implemented by that filesystem. > * FIEMAP_EXTENT_DATA_INLINE > This will also set FIEMAP_EXTENT_NOT_ALIGNED > Data is located within a meta data block. This seems like it would always set FIEMAP_EXTENT_NO_DIRECT :-) (Generally, won't FIEMAP_EXTENT_NOT_ALIGNED always set FIEMAP_EXTENT_NO_DIRECT?) > * FIEMAP_EXTENT_DATA_TAIL > This will also set FIEMAP_EXTENT_NOT_ALIGNED > Data is packed into a block with data from other files. Maybe this too. -- Jamie -- 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
