[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#27666: [grep on GPFS filesystem] SEEK_HOLE problem

From: Paul Eggert
Subject: bug#27666: [grep on GPFS filesystem] SEEK_HOLE problem
Date: Wed, 19 Jul 2017 03:47:36 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

Moyard John wrote:
GPFS maintainers give me the answer including manpage close(2) : nothing will 
be done.

Sorry, I don't follow (why is close(2) involved?).

Is your correspondence with the GPFS maintainers public? It sounds like they do not understand the issue.

Anyway, as Eric said, GPFS is clearly buggy. True, a file system is not obliged to report holes. But if it reports a hole, the hole must contain NUL bytes.

On the web, same problems has been identified  for ZFS or perhaps NFS v4 ? :

These URLs talk about a ZFS-on-Linux bug that has been fixed, apparently.  Good.


This is the inverse issue, which doesn't cause the problem you mentioned.

I will not file a bug on each file system maintainers : I should obtain the 
same answer.

I don't see why. Only GPFS has the problem, as far as we know. And this is probably just a communication problem with its developers.

So, is-it possible for you to modify something about the way to test binary 
file ?

Programs other than 'grep' use SEEK_HOLE. Even if we changed 'grep' to stop using SEEK_HOLE, the other programs would still be broken on GPFS. Plus, 'grep' would likely be slower everywhere, just to work around the bug on GPFS.

Really, GPFS needs to be fixed. If GPFS can't support SEEK_HOLE correctly, it should simply have lseek with SEEK_HOLE go to end-of-file; that will work with 'grep' (albeit more slowly), and is the documented way that SEEK_HOLE is supposed to work on file systems that cannot support SEEK_HOLE directly.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]