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

[jim owens <jowens@hp.com>]

As Jamie pointed out, this:

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

will confuse and mislead many people.  And as Andreas said,
the fe_physical and fe_device can be valid without the ability
to directly access the data.  I suggest we call this:

   FIEMAP_EXTENT_NO_BYPASS

As in "you can't bypass the filesystem" to directly access it.

Based on what Andreas said the NO_DIRECT (NO_BYPASS) means,
I disagree with these:

> * 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_DIRECT
> should also be set.

First, "If the data is not also in the filesystem" has no
relevance.  You are either providing the fe_physical and
fe_device for the HSM which may or may not allow direct
access, or you are providing the location in the filesystem
of the primary copy in which case you are not setting
FIEMAP_EXTENT_SECONDARY.  I don't think you want to return
BOTH the fiemap_extent primary and secondary as this will
confuse the hell out of everyone.

Or, as was said before, maybe HSM should wait until we
know what it really needs.

> * FIEMAP_EXTENT_NET
>   - This will also set FIEMAP_EXTENT_NO_DIRECT
> The data for this extent is not stored in a locally-accessible device.
> 
> * FIEMAP_EXTENT_DATA_COMPRESSED
>   - This will also set FIEMAP_EXTENT_NO_DIRECT
> The data in this extent has been compressed by the file system.
> 
> * FIEMAP_EXTENT_DATA_ENCRYPTED
>   - This will also set FIEMAP_EXTENT_NO_DIRECT
> The data in this extent has been encrypted by the file system.

None of the above are always NO_DIRECT.  Certainly you can
read the raw compressed/encrypted data (a backup program might)
and even a netdev might be accessed if you know how.

I think you need a different top-level flag that covers
"things which are not raw block data" so I would change this:

> * FIEMAP_EXTENT_NOT_ALIGNED
> Extent offsets and length are not guaranteed to be block aligned.

To be something like:

    FIEMAP_EXTENT_ENCODED

> * 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.

With FIEMAP_EXTENT_ENCODED being the top flag set for
FIEMAP_EXTENT_NET, FIEMAP_EXTENT_DATA_COMPRESSED,
FIEMAP_EXTENT_DATA_ENCRYPTED, FIEMAP_EXTENT_DATA_INLINE,
and FIEMAP_EXTENT_DATA_TAIL.  Then FIEMAP_EXTENT_NO_BYPASS
may or may not also be set and would say "can I get to
the physical data", and separately "do I need to do
special processing on it" would be FIEMAP_EXTENT_ENCODED.

> * 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.

This should say "will be all zero if read through the filesystem
but the contents are undefined if read directly."

jim