bug-gnulib
[Top][All Lists]
Advanced

[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}'
}




reply via email to

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