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