Re: [Bug-tar] [PATCH] Remove nonportable check for files containing only zeroes

[Andreas Dilger]

On Jan 10, 2018, at 5:05 AM, Dominique Martinet <address@hidden> wrote:
> 
> Hi,
> 
> Pavel Raiskup wrote on Wed, Jan 10, 2018 at 12:50:06PM +0100:
>>> This check benefitted only one unlikely case (large files containing
>>> only zeroes, on systems that do not support SEEK_HOLE)
>> 
>> It drops the optimization even for situations when SEEK_HOLE is not
>> available, which is not 100% necessary.  I'm not proposing doing otherwise
>> (I actually proposed this in [1]), but I'm rather CCing Andreas once more,
>> as that's the original requester, the use-cases with lustre were
>> definitely not unlikely and the question is whether SEEK_HOLE covers them
>> nowadays.
> 
> Jumping in for lustre, for which there currently is a trivial SEEK_HOLE
> implementation that only checks file size boundaries, but I'd like to
> properly implement it soonish so I don't think tar should wait for
> lustre there.
> (not sure how Andreas feels about that though, will let him speak up)

I'd be happy to have a proper SEEK_HOLE/SEEK_DATA implementation for
Lustre, though it would be a bit tricky for sparse files striped over
multiple OSTs.  Probably the best way to handle this would be to
fetch the FIEMAP data for each stripe to the client, and then interleave
the extents on stripe_size boundaries (in file offset order) to determine
where the actual holes/data are.

As a side benefit, this would allow the unpatched filefrag to work on
Lustre striped files, at the expense of making the output horribly ugly
due to hundreds/thousands of 1MB extents interleaved in file offset order,
rather than showing the contiguous allocations on each server.

Cheers, Andreas

signature.asc
Description: Message signed with OpenPGP