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

[Dave Chinner <david@fromorbit.com>]

On Mon, Jul 07, 2008 at 05:16:50PM -0400, jim owens wrote:
> Dave Chinner wrote:
>
>> Why? Have you ever used an extent mapping interface before?
>
> YES - for the past 9 years in Tru64 unix.
>
> Interfaces that were used by tools to defragment, print extmaps,
> capture metadata for support,
> perform backups
> with directIO through the fs, move file extents between devices,

Those are simple 'give me a mapping' cases - syncing first
is appropriate for all those cases. Making it atomic so you only
get blocks mapped to disk is also appropriate for all these
cases....

> scan for fs errors,

Deep filesystem specific knowledge is needed to do that properly, so
it's not really a use case we've considered for a generic fiemap
API.

> allow a stacked cluster filesystem to read/write directly to
> the raw device from other Tru64 nodes,

Oh, that's just gross.

> allow an IBM Tivoli client
> to read/write directly to the raw SAN storage from anywhere,
> (and probably some uses I've forgot).

yes, that's a fairly common thing to do from a read-only snapshot
of the filesystem. IOWs, the filesystem image is not changing so

	- block mapping is stable
	- no concurrent modifications

The application has provided sane access synchronisation to the
blocks, so it's not needed in fiemap. Great - your an expert in
storage and you know that your application doesn't need use the
FIEMAP_FLAG_SYNC....

> What I have been trying to point out in the fiemap discussion
> is all learned from past mistakes. 

You're saying that like it's a bad thing. Learning from mistakes
is how we improve things.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com