[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blake
Subject: bug#27666: [grep on GPFS filesystem] SEEK_HOLE problem
Date: Wed, 12 Jul 2017 09:10:50 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]