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

[Moyard John]

Hi,

This is the kind of answer obtained from the development file system team :
---
(close(2) manpage reference)
A successful close does not guarantee that the data has been successfully saved 
to disk, as the kernel defers writes.  It is not common for a filesystem to 
flush the buffers when the stream is closed.  If you need to be sure that the 
data is physically stored, use fsync(2).  (It will depend on the disk hardware 
at this point).
---

So running 'sync' prior to grep should solve the problem.
I don't try it yet.
Another solution found to use grep in this issue is to use activate ' 
--binary-files=text' grep option.

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