Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2

[Jamie Lokier <jamie@shareable.org>]

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