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

[Andreas Dilger <adilger@sun.com>]

On Nov 29, 2007  00:48 +0100, Jörn Engel wrote:
> 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).

The FIEMAP interface in some ways well suited to your needs, because it
uses byte offsets instead of FIBMAP, which uses block offsets.  I now see
that one hole in the specification is that your physical extent is not the
same length as the logical extent that the data represents.

I'm not sure that is in itself a reason not to use FIEMAP.  There is already
a provision for logical extents that do not map directly to the physical
layout (i.e. FIEMAP_EXTENT_NO_DIRECT flag on the extent).  In the case of
logfs, the extent fe_length would represent the logical length of the data
that the extent covers, fe_offset is the start of the physical extent, and
FIEMAP_EXTENT_NO_DIRECT indicates that this extent cannot be directly mapped.
This is useful for applications like LILO that would otherwise assume the
physical offset can be used to access the data from the block device.

It would still provide very useful information about the layout of files on
disk for filefrag, and if tar or cp used FIEMAP they could know to read the
data from the start up to the end of an extent to avoid waiting for a seek
in the middle of the IO, and of course skipping holes during copy.  A very
smart tar might even FIEMAP a whole bunch of files and then read the extents
in physical block offset order to reduce seeking.

I don't think most applications will care about the actual physical location
of an extent, so much as the relative locations of extents within a file and
between files.

> 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.

SEEK_HOLE/SEEK_DATA only provides a fraction of the useful information
that FIEMAP does.  It won't give users or developers any information about
the on disk layout (which is quite important for knowing if allocation
algorithms are good).

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