Re: FTS not ready for a remount during traversal

[Kamil Dudka]

Hi Jim,

On Wed November 4 2009 13:02:33 Jim Meyering wrote:
> I've built with it and compared before/after performance
> using an all-directories hierarchy on a tmpfs file system.
> 
> The result is a >10% performance decrease in this contrived worst case:

thanks for stating the upper boundary estimation!

> (Note: previously-built, unpatched version is in prev/,
> just-patched is in ./)
> 
>   $ z-mkdir 200000; for i in 1 2 3; do for p in prev .; do echo "$p ___";
>     env time $p/chgrp -R group2 $TMPDIR/z; done; done; z-rmdir
>   prev ___
>   1.52user 17.92system 0:19.46elapsed 99%CPU (0avgtext+0avgdata
>  0maxresident)k 0inputs+0outputs (0major+14369minor)pagefaults 0swaps
>   . ___
>   1.71user 20.61system 0:22.34elapsed 99%CPU (0avgtext+0avgdata
>  0maxresident)k 0inputs+0outputs (0major+14368minor)pagefaults 0swaps
>   prev ___
>   1.54user 17.92system 0:19.47elapsed 99%CPU (0avgtext+0avgdata
>  0maxresident)k 0inputs+0outputs (0major+14369minor)pagefaults 0swaps
>   . ___
>   1.63user 20.84system 0:22.48elapsed 99%CPU (0avgtext+0avgdata
>  0maxresident)k 0inputs+0outputs (0major+14369minor)pagefaults 0swaps
>   prev ___
>   1.64user 17.86system 0:19.52elapsed 99%CPU (0avgtext+0avgdata
>  0maxresident)k 0inputs+0outputs (0major+14370minor)pagefaults 0swaps
>   . ___
>   1.70user 20.69system 0:22.40elapsed 99%CPU (0avgtext+0avgdata
>  0maxresident)k 0inputs+0outputs (0major+14368minor)pagefaults 0swaps

I can confirm your results, just run your tests on an ext3 file system.

> I saw similar numbers when timing rm -rf and chmod -R.
> Thus, I'm reluctant to impose such a penalty without
> first exhausting all other possibilities.

Yes, it makes sense. However what other possibilities do we have actually?

Preferring higher performance in some rear cases over correct behavior
in more common cases is of course not a possibility for me.

Kamil