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
Description: OpenPGP digital signature
