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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
