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

[Dave Chinner <david@fromorbit.com>]

On Mon, Jul 07, 2008 at 07:01:24PM -0400, jim owens wrote:
> Anton Altaparmakov wrote:
>
>> It is completely irrelevant whether the information is still valid   
>> after the fiemap returns.
>
> So if that is true, any XFS utility that does more than PRINT
> the extent map based on doing JUST a fiemap is subject to
> erronious results.

No, that's an incorrect conclusion.

The fact that the file can change *after* the mapping is done is
taken into account by the application. The XFS utilities assume
that the mapping is atomic, but can change after the mapping
has been taken.

Indeed, there's usually bigger issues to deal with than this e.g.
defrag has to deal with the file not changing for the entire copy
process, not just the mapping part. e.g., xfs_fsr uses atomic
primitives and inode change detection to avoid the need exclusively
lock out all other access whilst doing the defragmentation.....

> I agree with everyone who says that to do useful work with
> the output of fiemap, you need a set of syscall functions
> that have this effect:
>
>    mandatory_exclusive_file_lock();
>      [optional] fsync(); or force_allocation();
>    fiemap();
>      [do ugly userspace stuff]
>    release_mandatory_exclusive_file_lock();

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.

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

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com