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:ebl...@redhat.com] Envoyé : mercredi 12 juillet 2017 16:11 À : Moyard John; 27...@debbugs.gnu.org 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
