bug#20826: SEEK_HOLE not supported for ext4 for kernel < 3.1

[Pádraig Brady]

On 16/06/15 13:47, Eric Blake wrote:
> [adding bug-gnulib]
> 
> On 06/16/2015 06:28 AM, Johannes Meixner wrote:
>>
>>> From one of our (SUSE) kernel developers
>> I even got a proposal for a workaround in grep:
>>
>> --- a/src/grep.c
>> +++ b/src/grep.c
>> @@ -575,6 +575,17 @@ file_textbin (char *buf, size_t size, in
>>            off_t hole_start = lseek (fd, cur, SEEK_HOLE);
>>            if (0 <= hole_start)
>>              {
>> +             /* if hole_start is identical with cur, it's more likely a
>> buggy
>> +              * lseek(SEEK_HOLE) implementation in kernel filesystem;
>> +              * check whether it really reads a null byte.
>> +              */
>> +             if (hole_start == cur)
>> +               {
>> +                 char c;
>> +                 if (read (fd, &c, 1) != 1 || c != 0)
>> +                   hole_start = st->st_size; /* no hole */
>> +               }
>> +
> 
> Sounds like we need to update the gnulib lseek module to work around
> bugs like this in the wild.

Interesting. The above runtime check wouldn't be appropriate I think
for such an old fleeting problem. Also the read() as a side effect
would be very much best avoided.  How about a linux kernel version check
at build time?

As a general point, gnulib would really benefit from SEEK_HOLE, SEEK_DATA
wrappers that degenerated to SEEK_END,0 and SEEK_SET,offset respectively.

cheers,
Pádraig.