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.
