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

[jim owens <jowens@hp.com>]

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, scan for fs errors, perform backups
with directIO through the fs, move file extents between devices,
allow a stacked cluster filesystem to read/write directly to
the raw device from other Tru64 nodes, allow an IBM Tivoli client
to read/write directly to the raw SAN storage from anywhere,
(and probably some uses I've forgot).

> Given that one of the original desires was to have the fiemap ioctl
> *replace the XFS ioctl*, I'm kinda getting sick of people saying "we
> don't want this because only it's only an XFS feature" depsite the
> fact that wإat we are doing here is re-implemented long standing XFS
> interfaces.

I don't have a problem with a feature that is implemented
for XFS if we can properly define the use of that feature.

I have been saying since I started talking on this forum that
I'm a real Linux newbie.  But I have been doing other kernels
so long they now add "old" to my "mean bastard" designation :)

What I have been trying to point out in the fiemap discussion
is all learned from past mistakes.  The words I'm using may be
part of the problem, or maybe people are too set on defending
an existing implementation to think it through.

So please think carefully about what I say in the next
emails about the design issues and consider that maybe
XFS made a mistake or two along the way.  If the mistake
is just that I don't understand it, please explain.

jim

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html