Re: [PATCH 1/4] vfs: vfs-level fiemap interface

[jim owens <jowens@hp.com>]

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