A couple of old documentation nits that were to be fixed:
+fm_extents[] to hold the file's current mapping. Note that there is
+nothing to prevent the file from changing between calls to FIEMAP.
+
+Currently, there are three flags which can be set in fm_flags:
Current flags which can be set in fm_flags:
+
+* FIEMAP_FLAG_SYNC
+If this flag is set, the kernel will sync the file before mapping extents.
+
+* 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.
extended attributes, otherwise the extents describe the file data.
-----------------------------------------------
And a documentation issue with this new change:
+
+* FIEMAP_EXTENT_NO_MOUNTED_IO
Did you really intend to name it FIEMAP_EXTENT_NO_MOUNTED_IO
or did you intend it to be FIEMAP_EXTENT_NO_UNMOUNTED_IO ?
+Accessing the data in this extent via I/O to the block device while the
+filesystem is unmounted is illegal or will have undefined results. This
+may because the data is somehow encrypted or compressed by the filesystem.
may be because the data is somehow encrypted or compressed by the
filesystem.
+Note that accessing the data using the information returned by the
+FIEMAP interface is *always* undefined should not be attempted by user
+applications.
FIEMAP interface is never guaranteed to be consistent and should
not be attempted by user applications.
[ IMO - it is confusing to say "undefined" when the flag is ]
[ set and also say "undefined" when the flag is clear ]
jim
--
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
