Re: [Qemu-devel] [PATCH v2] block/raw-posix: Try both FIEMAP and SEEK_HOLE

[Max Reitz]

On 07.05.2014 07:56, Markus Armbruster wrote:
> Eric Blake <address@hidden> writes:
>
> > On 05/06/2014 03:18 PM, Eric Blake wrote:
> >
> > > ...if you are on a file system where SEEK_HOLE triggers the kernel
> > > fallback of "entire file is allocated", but where FIEMAP is wired up for
> > > that file system, would it make sense to have try_seek_hole return -1 in
> > > situations where lseek(s->fd, 0, SEEK_HOLE) returns the end of the file?
> > >   Even more, should skip_seek_hole be a tri-state?
> > On the other hand, such systems are getting vanishingly rare as people
> > upgrade to newer kernels.  Do we care about catering to them, or is it
> > fair game to just tell people to upgrade if they want performance?
> My tolerance for code complications to speed up things under old kernels
> isn't zero, but close.  Leave these games to downstreams sporting such
> kernels.

As far as I see it, it isn't an optimization for older but for newer 
kernels. Including Paolo's comment for v3, we could get away without 
these tristate shenanigans if we'd keep the old (current) order, that 
is, first try FIEMAP which will return ENOTSUP if it's not supported, 
and then fall back to SEEK_HOLE which will always return some result (if 
available, otherwise we can't even use it, obviously).

But as SEEK_HOLE is apparently the more "standard" way to acquire the 
required information, using it first is an optimization for newer 
systems (older Linux systems and/or older drivers will only provide FIEMAP).

I think there is no big performance penality in trying FIEMAP first, as 
the first call to raw_co_get_block_status() will detect that it is not 
available for the given file and therefore will be skipped from then on 
anyway.

Considering this, I guess I'll send a v4 without any tristates and which 
keeps the old order (FIEMAP first and then SEEK_HOLE).

Max