On Aug 6, 2011, at 07:24, Gary Palmer wrote: > On Fri, Aug 05, 2011 at 08:56:36PM -0700, Doug Barton wrote: >> On 08/05/2011 20:38, Daniel O'Connor wrote: >> >>> Ahh, but OP had moved these files away and performance was still poor.. >>> _that_ is the bug. >> >> I'm no file system expert, but it seems to me the key questions are; how >> long does it take the system to recover from this condition, and if it's >> more than N $periods is that a problem? We can't stop users from doing >> wacky stuff, but the system should be robust in the face of this. > > Its been quite a while since I worked on the filesystem stuff in any > detail but I believe, at least for UFS, it doesn't GC the directory, > just truncate it if enough of the entries at the end are deleted > to free up at least one fragment or block. If you create N files and > then a directory and move the N files into the directory, the directory > entry will still be N+1 records into the directory and the only way to > "recover" is to recreate the directory that formerly contained the N > files. It is theoretically possible to compat the directory but since > the code to do that wasn't written when I last worked with UFS I suspect > its non trivial. > > I don't know what ZFS does in this situation
It sounds like it does something similar. I re-ran the experiment to see if I could narrow down the problem. % mkdir foo % cd foo && for i in {1..1000}; do touch $i; done % ls > list % for file in $(cat list); do rm -f $file; done % time ls (slow!) % rm -f list % time ls (slow!) I would like to dig into this a bit more, I suppose it's probably a good enough reason to explore how DTrace works :) Sean_______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"