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

[Paul Eggert]

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 ? :
>   https://utcc.utoronto.ca/~cks/space/blog/linux/GrepBinaryFileReason
> https://github.com/zfsonlinux/zfs/issues/6050

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

> https://lists.gnu.org/archive/html/bug-grep/2012-07/msg00022.html

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.