GNU bug report logs - #20826
SEEK_HOLE not supported for ext4 for kernel < 3.1

Previous Next

Full log

Message #17 received at 20826 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Eric Blake <eblake <at> redhat.com>, Johannes Meixner <jsmeix <at> suse.de>, 
 20826 <at> debbugs.gnu.org, Bug-gnulib <bug-gnulib <at> gnu.org>
Subject: Re: bug#20826: SEEK_HOLE not supported for ext4 for kernel < 3.1
Date: Tue, 16 Jun 2015 14:06:44 +0100

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.