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

[jim owens <jowens@hp.com>]

Andreas Dilger wrote:

> That doesn't make sense either.  "NOT_ALIGNED" just means that it
> isn't a full filesystem block, but it isn't necessarily "encoded"
> in any way.

I fully agree (don't let anyone know I said that) the word
encoded is bad, but I was trying to produce a set of top
level flags that minimize the checks applications need.

>>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.
>  
> It seems to me that "ENCODED" has no relation to "NET" or "DATA_TAIL"
> or "DATA_INLINE".

The point is that a simple app that only processes blocks
would not handle any of the above extents.

When I proposed this I was thinking about layered flag checking,
but now I'm starting to wonder if having top catagories actually
helps applications now or for the future.  It seems they still
need to check "are there any flags set that I don't know", rather
than checking groupings.

So now I don't see FIEMAP_EXTENT_NOT_ALIGNED or "ENCODED"
has any value.

jim