bug-grep
[Top][All Lists]
Advanced

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

Re: SEEK_HOLE defined but useless on linux-3.4+/ext4 [Re: small ascii fi


From: Jim Meyering
Subject: Re: SEEK_HOLE defined but useless on linux-3.4+/ext4 [Re: small ascii files can be sparse
Date: Tue, 31 Jul 2012 20:43:52 +0200

Paul Eggert wrote:
> On 07/31/2012 10:14 AM, Jim Meyering wrote:
>> Can you outline how a grep -r X A B C might go astray due to such a
>> cache entry becoming stale, assuming we clear the cache between command
>> line arguments?
>
> For example, one could have 'grep -R X A', where A contains symlinks
> that point into another file system, and that file system could
> be remounted between the time one symlink is visted, and the next.
>
> The problem could occur without symlinks as well.  A could be a
> tree above two mounted file systems A/F and A/G.  'grep -r X A' visits
> A/F first.  After it stops visiting A/F, A/F is unmounted
> and A/G mounted, with the same device number as A/F.  grep then visits
> A/G and uses incorrect cached info about A/G's status.

True, there is a race.

Ways to work around that, when dereferencing:

  - incur the cost of an extra fstatfs call per "open"
    when a file's device differs from its parent's

  - disable fs-type caching altogether (simplest, and wouldn't
    bother me: IMHO, grep's -R option is best avoided)

However, do you think this race scenario
(remounting a compressing FS as a non-compressing one
while a grep -R run that examines files on the remounted FS)
is even worth working around?  It seems a little too far-fetched
even for me.

> xstat should work, assuming it's designed well.
> But surely SEEK_HOLE will be available sooner, for ext4.
> I see there's active development in that area now
> <http://comments.gmane.org/gmane.linux.file-systems/66117>.

Yes, that is reassuring.
If that functionality makes it in for both ext4 and tmpfs,
and no long-supported system has the stubbed (i.e., useless)
SEEK_HOLE/SEEK_DATA support, then we won't need to bother
with any of this.

That (doing nothing about this, for now) would be simplest of all,
but I do not like it when grep -r mysteriously hangs and makes
my system run out of memory.  This really does affect me a couple
times per month, at least.



reply via email to

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