Bruno Haible <[EMAIL PROTECTED]> wrote: > Hi Jim, > > The Darwin HFS+ bug is even reproducible on Linux, on NFS mounts from a > Darwin 10.3.9 machine. Here is that same directory, of which Darwin's > readdir() bug occurred after 178 removals. Here it occurs already after > 13 removals on average: > > $ ll charmaps | wc -l > 195 > $ rm -r charmaps > rm: cannot remove directory `charmaps': Directory not empty ... > This means one has to enable the workaround with 8% speed penalty on all > systems, not just Darwin...
Thanks for trying that. I've been considering doing just that. Luckily, the 8% doesn't apply here, since we needn't always do the rewind. It's necessary only when rm has removed enough files in a directory to provoke the bug. That 8% was performing the rewind even when there was only one entry in a directory, and with the very worst case directory "shape", and on the very worst case type of file system (tmpfs), where I/O overhead is very low, so normally insignificant factors like that one would appear. With the current choice of 10 (assuming rm imposes the cost for everyone) that means for non-buggy systems, rm would perform an unnecessary rewind upon end of dirstream only when it has removed 10 or more files from a given directory. In fact, I am unable to measure any significant performance difference. I created a hierarchy of 30000 directories, each containing 11 files on a tmpfs file system: n=30000 seq --format=a/%g $n|xargs mkdir -p for i in $(seq $n); do seq --format=a/$i/%g 11;done|xargs touch Then remove them all via "rm -rf a". [The first has the work-around rewindir call, the second doesn't.] $ /usr/bin/time /cu/src/rm -rf a 0.34user 3.45system 0:03.85elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+167minor)pagefaults 0swaps $ /usr/bin/time /p/bin/rm -rf a 0.39user 3.37system 0:03.80elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+164minor)pagefaults 0swaps
