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.
