Re: [PATCH 0/3] Fiemap, an extent mapping ioctl

[Christoph Hellwig <hch@infradead.org>]

On Wed, Sep 10, 2008 at 05:49:34AM -0700, Mark Fasheh wrote:
> * 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.

So does this actually make sense for any filesystem but XFS?  Still
seems like a not too useful option for a highlevel generic interface.

> 	__u32	fe_device;   /* device number for extent */

As sayd before please kill thise one.  It doesn't make any sense at all
for any merged or near mainline FS.  It'd be an utterly stupid
lustre-specific hack that still doesn't make much sense.

> * FIEMAP_EXTENT_NO_BYPASS
> Direct access to the data in this extent is illegal or will have
> undefined results.

Huh?  What is direct access?  Direct access as in bypassing the
filesystem and writing to the blockdev directly always has undefined
results.

> * FIEMAP_EXTENT_SECONDARY
> The data for this extent is in secondary storage (e.g. HSM).  If the
> data is not also in the filesystem, then FIEMAP_EXTENT_NO_BYPASS
> should also be set.

No HSM in mainline, so please drop it.  We can add it once we get HSM
support.

> * FIEMAP_EXTENT_NET
>   - This will also set FIEMAP_EXTENT_NO_BYPASS
> The data for this extent is not stored in a locally-accessible device.

Doesn't make any sense currently, please drop.

> * FIEMAP_EXTENT_DATA_COMPRESSED
>   - This will also set FIEMAP_EXTENT_NO_BYPASS
> The data in this extent has been compressed by the file system.

Add once we have users for it.

> * FIEMAP_EXTENT_DATA_ENCRYPTED
>   - This will also set FIEMAP_EXTENT_NO_BYPASS
> The data in this extent has been encrypted by the file system.
> 
> * FIEMAP_EXTENT_NOT_ALIGNED
> Extent offsets and length are not guaranteed to be block aligned.
> 
> * 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.
> 
> * 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 if read
> through the filesystem but the contents are undefined if read directly from
> the device.
> 
> * FIEMAP_EXTENT_MERGED
> This will be set when a file does not support extents, i.e., it uses a block
> based addressing scheme.  Since returning an extent for each block back to
> userspace would be highly inefficient, the kernel will try to merge most
> adjacent blocks into 'extents'.