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

[Moyard John]

Thank your very much for your detailed answer.
"close(2)" is involved because a test case made to reproduce the problem use a 
cp, initially a fortran code to make a copy, follow by a grep.

I clearly understand your point of view about 
     reporting hole and NUL bytes
     GPFS incompatibility with others programs/commands that could use SEEK_HOLE
I try to take a quick look about this last point and don't find yet any system 
command using it.
Do you have an example of other command using SEEK_HOLE?

In POSIX point of view, lseek(2) manpage precise this :
SEEK_DATA and SEEK_HOLE are nonstandard extensions also present in Solaris, 
FreeBSD, and DragonFly BSD
They are proposed for inclusion in the next  POSIX  revision   (Issue 8)
Do you have any information about it?
Does compile 'grep' mechanism could avoid the use of SEEK_HOLE test ?
I just try to obtain a grep command with a default behavior in respect of POSIX 
standard.



-----Message d'origine-----
De : Paul Eggert [mailto:address@hidden 
Envoyé : mercredi 19 juillet 2017 12:48
À : Moyard John; Eric Blake; address@hidden
Objet : Re: bug#27666: [grep on GPFS filesystem] SEEK_HOLE problem

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.