[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: Moyard John
Subject: bug#27666: [grep on GPFS filesystem] SEEK_HOLE problem
Date: Tue, 18 Jul 2017 11:23:24 +0000

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 ? :
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.

So, is-it possible for you to modify something about the way to test binary 
file ?


-----Message d'origine-----
De : Paul Eggert [mailto:address@hidden 
Envoyé : jeudi 13 juillet 2017 22:44
À : Moyard John; Eric Blake; address@hidden
Objet : Re: bug#27666: [grep on GPFS filesystem] SEEK_HOLE problem

On 07/13/2017 02:13 AM, Moyard John wrote:
> That's why I was asking about another way to identify a binary file instead 
> using 'seek(SEEK_HOLE)' : do you think that it could possible?

If there is a reasonable (i.e., cheap) way for grep to determine that SEEK_HOLE 
is buggy for the current file, I suppose grep could do that. 
Do you know of any such method?

Really, the bug here is in the file system, not in grep. Have you filed a bug 
with the GPFS maintainers?

reply via email to

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