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

[Moyard John]

Hi,

I forgot to precise that activate  '--binary-files=text'  grep option or 
integrate a synchronization step before a grep are not lasting solutions in all 
my shell scripts.
That's why I was asking about another way to identify a binary file instead 
using 'seek(SEEK_HOLE)' : do you think that it could possible?

Best regards
john



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

On 07/12/2017 04:27 AM, Moyard John wrote:
> Hi,
> 
> I use GPFS file system and I have sometimes an issue using grep command.
> When issue occurs with the following message "Binary file <myfile> matches"
> But "<myfile>" is an ASCII one, not a binary file.
> The problem seems to deals with lseek(SEEK_HOLE) command and a file not 
> completely flushed after close.

If lseek(SEEK_HOLE) returns a mid-file offset when the file is first created, 
but not later after the file has been synced, then that is a bug in the 
filesystem which should be reported to the appropriate filesystem/kernel folks. 
 SEEK_HOLE is only allowed to return a mid-file offset if reading the file at 
that point in time would read NUL bytes, and NUL bytes are indeed binary data.

> It could take several seconds to save the entire file on the disk.

Does running 'sync' prior to grep solve the problem?

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org