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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
