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

[jim owens <jowens@hp.com>]

Dave Chinner wrote:

> Yes, but file locking and application level synchronisation is
> outside the scope of the fiemap syscall. I'm not disagreeing that
> this is not needed, just that such application level synchronisation
> has no direct relevance to the fiemap API.

At least we agree on something.  I keep talking about locking
only to say that true data consistency requires using some other
system locking mechanism around fiemap().  The relevance is that
without these other mechanisms the data must be assumed inconsistent.

> OTOH, an atomic sync+map is relevant fiemap as this is the only API
> that can provide it. We often do stuff with atomic primitives to
> avoid unnecessary and/or expensive locking and that's all this is -
> an atomic mapping primitive. You may not consider it useful, but
> some of us do....

My objection is that I still have not heard a consistent
logical argument and set of semantics that apply to ALL
filesystems with an explanation of how a NEW tool would
use this feature.  I would be happy to have the SYNC flag
with its current semantic for XFS if we redefine it as:

* FIEMAP_B_STUPID
*    may provide a more complete extent map on some
*    filesystems at the expense of using more resources

So users understand what they really are doing and
don't think an atomic fsync provides good data.

Here is the summary of the SYNC supporters argument:

1) XFS tools can't deal with delalloc.

2) XFS tools know returned data is crap and handle that.

3) XFS needs to obsolete and replace XFS specific api.

4) XFS tools must be recoded for #3, and already have
    extensive logic for #2 to make rational decisions
    with bad data... BUT it is impossible to have
    the XFS tools fixed so #1 is also handled, thus
    we must have the fiemap SYNC flag.

AAARRRRRGGGG!

Does anyone else see why I just don't freak'n get it!

This is the truth:  FIEMAP DATA IS UNSTABLE

NEW TOOLS MUST DEAL WITH THAT INSTABILITY.

jim