GNU bug report logs - #18406
O_NOATIME patch

Previous Next

Full log

Message #30 received at 18406 <at> debbugs.gnu.org (full text, mbox):

From: Zev Weiss <zev <at> bewilderbeest.net>
To: Jim Meyering <jim <at> meyering.net>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 18406 <at> debbugs.gnu.org,
 starlight.2014q3 <at> binnacle.cx
Subject: Re: bug#18406: O_NOATIME patch
Date: Fri, 4 Sep 2020 12:43:12 -0500

On Fri, Sep 04, 2020 at 11:12:07AM CDT, Jim Meyering wrote:
>On Tue, Sep 1, 2020 at 4:22 AM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>> On 9/11/14 1:13 PM, Paul Eggert wrote:
>> > Thanks, but there's no need for that; just have 'grep' complain if the option is
>> > used and O_NOATIME == 0.
>>
>> On looking into this more today, O_NOATIME seems to be just a best-effort thing
>> as some GNU/Linux filesystems ignore it, so grep should just join the throng and
>> not worry whether O_NOATIME actually works.
>>
>> Also, the O_NOATIME support was withdrawn from fts a couple of years ago, so
>> 'grep -r' can't easily avoid updating atime on directories.
>>
>> A patch is attached. I'm still of two minds about this. The efficiency argument
>> for the new option is not as strong as it used to be, now that relatime has
>> taken over on ext4 style filesystems. So the main argument is "I want to search
>> through this directory but don't want it to count as an access"; although that's
>> indeed a use case I'm not quite sure it's worth modifying 'grep' over. It
>> doesn't seem to be worth using up a scarce option letter over, anyway, so the
>> attached patch uses just a long option.
>
>I confess to similar ambivalence, but do like the idea. Has anyone run
>tests to compare performance on file systems like ext4, btrfs (the
>default with Fedora 33) and xfs?
>
>

For what my two cents are worth: while yes, the performance angle is I'd 
guess probably not real relevant these days in the face of widespread 
noatime/relatime mount options (though I haven't done any measurements), 
I can see the semantic angle -- but adding flags to individual tools 
seems like an awkward way to go about solving the problem.  Something 
like an LD_PRELOAD hack to shove O_NOATIME into the flags argument of 
every open(2) call comes to mind...



Zev

Previous Next

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