bug-gnulib
[Top][All Lists]
Advanced

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

Re: [PATCH 1/2] fts: introduce the FTS_NOLEAF flag


From: Pádraig Brady
Subject: Re: [PATCH 1/2] fts: introduce the FTS_NOLEAF flag
Date: Thu, 7 Sep 2017 21:19:02 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

On 05/09/17 01:36, Kamil Dudka wrote:
> On Thursday, December 10, 2015 2:26:38 AM CEST Pádraig Brady wrote:
>> On 09/12/15 10:35, Pádraig Brady wrote:
>>> On 09/12/15 06:34, Kamil Dudka wrote:
>>>> The flag is needed to implement the -noleaf option of find.
>>>> * lib/fts.c (link_count_optimize_ok): Implement the FTS_NOLEAF flag.
>>>> * lib/fts_.h (FTS_NOLEAF): New macro, shifted conflicting constants.
>>>
>>> Is this exposed to fix issues with certain file systems,
>>> or just in case there may be issues, or support easily
>>> testing find without the leaf optimization?
>>>
>>> I see Jim said the current FTS implementation
>>> would make -noleaf a no-op there:
>>> https://lists.gnu.org/archive/html/bug-gnulib/2008-12/msg00280.html
>>>
>>> cheers,
>>> Pádraig.
>>>
>>> p.s. I see that find does a stat per file on XFS,
>>> while d_type can be used to distinguish dirs there.
>>> On XFS DT_DIR is set for dirs and DT_UNKNOWN otherwise.
>>> I wonder is there some optimization we could do for that case.
>>
>> I did a quick check on XFS which suggests the leaf optimization
>> based on st_nlink is valid:
>>   test $(($(find . -maxdepth 1 -type d | wc -l) + 1)) = $(stat -c %h .) &&
>> echo leaf_ok
>>
>> Applying this diff:
>> @@ -717,6 +718,7 @@ leaf_optimization_applies (int dir_fd)
>>      {
>>        /* List here the file system types that lack usable dirent.d_type
>>           info, yet for which the optimization does apply.  */
>> +    case S_MAGIC_XFS:
>>      case S_MAGIC_REISERFS:
>>        return true;
>>
>> Gives this significant speedup:
>>   $ time find/find-before /usr/share >/dev/null
>>   real    0m0.410s
>>   user    0m0.145s
>>   sys     0m0.266s
>>
>>   $ time find/find-after /usr/share >/dev/null
>>   real    0m0.278s
>>   user    0m0.147s
>>   sys     0m0.131s
> 
> Pádraig, do you remember which kernel you tested it with?
> 
> I am currently not able to get any speedup on XFS with Fedora/el7 kernels...

Eek that's getting towards 2 years ago :)
I _vaguely_ remember creating a loopback XFS for testing on Fedora.
Me goes spelunking on an old laptop...
Ah found a perf.data indicating 4.2.5-300.fc23.x86_64 (glibc-2.22)
I don't have the code changes though I vaguely remember having
to tweak things so that the gnulib FTS was used.

cheers,
Pádraig



reply via email to

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