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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to