Re: [RFC][PATCH] Implement SEEK_HOLE/SEEK_DATA

["Jörn Engel" <joern@logfs.org>]

On Wed, 28 November 2007 16:39:59 -0700, Andreas Dilger wrote:
> On Nov 28, 2007  14:56 -0800, Nicholas Miell wrote:
> > 
> > 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.

I didn't follow the discussion much, since it didn't appear to suit
logfs too well.  In a nutshell, logfs is purely block-based, prepends
every block with a header, may compress blocks and packs them as tightly
as possible (byte alignment).

Maybe the "MAP" part fooled me to believe FIEMAP would also expose
physical location of extends on the medium.  But reading the proposal
again, I am unsure about that part.  If physical locations are exposed,
SEEK_HOLE/SEEK_DATA is significantly more elegant for logfs.  If not,
FIEMAP could be useful.

Jörn

-- 
Measure. Don't tune for speed until you've measured, and even then
don't unless one part of the code overwhelms the rest.
-- Rob Pike
-
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