[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FTS not ready for a remount during traversal
From: |
Jim Meyering |
Subject: |
Re: FTS not ready for a remount during traversal |
Date: |
Wed, 04 Nov 2009 13:02:33 +0100 |
Kamil Dudka wrote:
> On Sat October 31 2009 12:22:01 Jim Meyering wrote:
>> I'm trying to reconcile this file system's behavior with
>> fundamental assumptions about unchanging device/inode,
>> and as a result am having second thoughts.
>>
>> What event causes the directory's stat.st_dev to change?
>> Opening the directory? Calling readdir? Accessing one
>> of its entries?
>>
>> Can you describe how to reproduce the problem on rawhide or Fedora 12?
>
> all the info should be already placed at the RH bug (where you are also
> subscribed):
>
> https://bugzilla.redhat.com/501848
>
> Let me know if there is anything missing. A new version of the patch is
> attached. Any feedback welcome!
Hi Kamil,
Thanks for the new patch.
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:
(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 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.
Those z-* things are bash functions to create and remove deep
hierarchies:
z-mkdir () {
local n
case $# in
(1) n=$1 ;;
(*) echo "Usage: $FUNCNAME N" >&2
return 1 ;;
esac
command perl -w -e 'my $root = $ENV{TMPDIR} || "/tmp";
chdir $root or die "cannot chdir to $root: $!\n";
$i=1; do { mkdir "z",0700 or die "mkdir failed: depth $i: $!\n";
chdir "z" or die "chdir failed: depth $i: $!\n" }
while (++$i <= '$n')'
}
z-rmdir () {
case $# in
(0) ;;
(*) echo "Usage: $FUNCNAME" >&2
return 1 ;;
esac
local root=${TMPDIR=/tmp}
command perl -w -e 'my $root = $ENV{TMPDIR} || "/tmp";
chdir $root or die "cannot chdir to $root: $!\n";
while (1) {chdir "z" or last};
while (1) {chdir ".." && rmdir "z" or last}'
}