Re: FTS not ready for a remount during traversal

[Kamil Dudka]

On Thu October 22 2009 16:42:48 Jim Meyering wrote:
> Have you measured the performance penalty it incurs?
> I hope it is possible to do the same thing, but with less of a penalty.
> 
> I'm afraid we'll have to do something like that one way or
> another.  At best, the impact will be so small that we won't
> even have to provide a new "flag" to enable it.

Here are some basic metrics (/var is ext3, /mnt/archive is NFSv3):

Before patch
============
# time du -sh /var
2.8G    /var

real    0m0.222s
user    0m0.038s
sys     0m0.186s

# time find /var > /dev/null

real    0m0.187s
user    0m0.068s
sys     0m0.118s

# time find /mnt/archive/fotky/ > /dev/null

real    0m0.089s
user    0m0.010s
sys     0m0.031s


After patch
===========
# time du -sh /var
2.8G    /var

real    0m0.220s
user    0m0.051s
sys     0m0.169s

# time find /var > /dev/null

real    0m0.197s
user    0m0.055s
sys     0m0.142s

# time find /mnt/archive/fotky/ > /dev/null

real    0m0.090s
user    0m0.007s
sys     0m0.030s


There is no measurable performance penalty, assuming you have more files than 
directories in the tree (which is IMO the common use case). I am attaching 
also a filtered strace output showing the cost of the second stat call:

# strace -rve trace=openat,newfstatat -o trace.raw du -sh /var
# grep -A1 -B1 openat trace.raw | lzma -c > trace.lzma

Kamil

trace.lzma
Description: application/lzma