GNU bug report logs - #27666
[grep on GPFS filesystem] SEEK_HOLE problem

Previous Next

Full log

View this message in rfc822 format

From: Eric Blake <eblake <at> redhat.com>
To: Moyard John <John.Moyard <at> cnes.fr>, Paul Eggert <eggert <at> cs.ucla.edu>, "27666 <at> debbugs.gnu.org" <27666 <at> debbugs.gnu.org>
Subject: bug#27666: [grep on GPFS filesystem] SEEK_HOLE problem
Date: Tue, 18 Jul 2017 06:30:37 -0500

[Message part 1 (text/plain, inline)]

On 07/18/2017 06:23 AM, Moyard John wrote:
> GPFS maintainers give me the answer including manpage close(2) : nothing will be done.
> 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
> https://lists.gnu.org/archive/html/bug-grep/2012-07/msg00022.html
> I will not file a bug on each file system maintainers : I should obtain the same answer.
> Or perhaps I will obtain an extract of manpage lseek(2), i.e. http://man7.org/linux/man-pages/man2/lseek.2.html :
>      However, a filesystem is not obliged to report holes, so
>     these operations are not a guaranteed mechanism for mapping the
>     storage space actually allocated to a file
> It's not a bug in file system.

A file system is not obliged to report holes, but IS obliged to NOT
report holes if a read() on that range will not see zeroes.  I still
think GPFS has a bug.

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

[signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.