Mark Fasheh wrote: > Hello, > > The following patches are the latest attempt at implementing a > fiemap ioctl, which can be used by userspace software to get extent > information for an inode in an efficient manner. > > These patches are against 2.6.26-rc3, though they probably apply > fine against Linus' latest tree. The fs patches are much more complete this > time around, and the vfs patch has been trimmed down. > > An updated version of my ioctl wrapper test program is available at: > > http://www.kernel.org/pub/linux/kernel/people/mfasheh/fiemap/tests/ > > A couple of notes regarding the VFS patch: > > Firstly, most behavior-changing fm_flags have been removed. We're > left with SYNC and XATTR now. This is a very good thing because frankly, I > think fiemap should be targeted as a straight-forward and relatively > uncomplicated API for exposing extents as they appear on disk. Think "one > notch above extent-based FIBMAP replacement". So Mark's gonna hate me for this 'cause I was acting all resigned last night, but I have to throw this out (sorry Mark!) Right now the interface seems to be about returning details of the filesystem's accounting of the on-disk layout, as opposed to just a simple mapping. As 2 examples: 1) If you have 8 contiguous 128M extents for a 1G file, currently the interface will (or may) give you back 8 extents for the entire file, even though the file is 100% unfragmented, because that reflects the details of the filesystem's internal accounting. 2) Further, if you ask for a mapping of that file between 100M and 200M (logical), you will (or may) get back 2 extents between 0M and 256M because again, that is how the filesystem is tracking the layout internally. (compare with a simple mapping-only interface which would return a single range from 0 to 1G, or from 100M to 200M). Either approach has its merits, depending on what you want the interface to do I suppose. Maybe it should even be (gasp) another flag to switch between one or the other? (merge & trim extents vs. distinct & full extents?) For filesystem debugging work I see the value in returning some details of the filesystem's internal representation of the layout. For a mapping interface, I think it complicates things for the caller. In the end I can live with either as long as we're explicit about it, but I think it's worth pointing out. -Eric -- 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
