On Nov 28, 2007 14:56 -0800, Nicholas Miell wrote: > I stand by my belief that SEEK_HOLE/SEEK_DATA is a lousy interface. > > It abuses the seek operation to become a query operation, it requires a > total number of system calls proportional to the number holes+data and > it isn't general enough for other similar uses (e.g. total number of > contiguous extents, compressed extents, offline extents, extents > currently shared with other inodes, extents embedded in the inode > (tails), etc.) > > Something like the following would be much better: > > int getfilextents(int fd, off_t offset, int type, size_t *length, struct > extent *extents) > > with > > int fd: open file > > offset: offset in file to start reporting extents > > type: one of EXTENT_TYPE_HOLE, EXTENT_TYPE_DATA, EXTENT_TYPE_EXTENTS, > EXTENT_TYPE_COMPRESSED, EXTENT_TYPE_UNCOMPRESSED etc. This is what FIEMAP is supposed to do. We wrote a spec and implemented a prototype for ext4, but haven't had time to make it generic to move the large part of the code into the VFS. If someone wanted to take that up, it would be much appreciated. See "[RFC] add FIEMAP ioctl to efficiently map file allocation" in linux-fsdevel for details on this interface. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. - 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
