Re: [PATCH] fts: introduce FTS_NOATIME

[Jim Meyering]

Eric Blake wrote:

> On 07/07/2011 03:07 PM, Eric Blake wrote:
>> On 07/07/2011 03:02 PM, Paul Eggert wrote:
>>> On 07/07/11 10:41, Eric Blake wrote:
>>>> This gives clients the option to try a non-invasive traversal,
>>>
>>> Thanks for doing that; a couple of minor comments:
>>>
>>>> -            int fd = open (".", O_SEARCH);
>>>> +            int fd = open (".",
>>>> +                           O_SEARCH | (ISSET (FTS_NOATIME) ? O_NOATIME : 
>>>> 0));
>>>
>>> Shouldn't this use diropen rather than open?  Then you don't need
>>> to worry about checking the flag here.  (This comment applies to
>>> the existing code, too.)
>>
>> Possibly.  Jim?
>
> Then again, maybe not.  This particular open() is done in early
> initialization, and diropen() assumes that the rest of the fts struct
> internals have already been initialized.  That is, diropen() may fail if
> called this early.

Thanks for answering your own question.  On the topic of fts, just
yesterday, prompted by this report, http://bugzilla.redhat.com/719749,
I realized that fts may require some surgery.

rm -fr million-entry-directory requires way more memory than needed
(300MiB), at least on extN, due to the sort-by-inode hack that works
around the O(N^2) performance problem you would otherwise see.  And with
N=1000000, see it you would.  However, if we care about this enough
to fix it (probably) I'll have to redesign part of fts.c to read/sort
entries only say 50K at a time, and that only when fts_open specifies
a NULL comparison function.