that's not too bad.

i fancy that the big difference i was seeing might have
been to do with the fact that i was creating (or destroying)
tens of thousands of tiny files, whereas your example contains
only three. also, isn't gzip somewhat more compute-intensive
than gunzip, in which case maybe what you were doing
was more cpu-bound?

one example:

	linux% time rm -r mozilla
	
	real	0m3.621s
	user	0m0.090s
	sys	0m1.180s
	linux% 

an equivalent under fossil, removing only half that
number of files took more than 5 minutes.

another:

	linux% ls -l *.bz2
	-rw-r--r--    1 rog      rog      32686249 Jan 26 20:54 firefox.tar.bz2
	linux% time sh -c 'bunzip2 < firefox.tar.bz2 | dd 'bs=512k' | tar xf -'
	
	real	1m23.266s
	user	0m36.600s
	sys	0m5.050s
	linux% 

(the big blocksize dd is there to try and reduce disk contention
between the bunzip process and the tar write).

when i did this using fossil i killed it after an hour had passed.
thanks for pointing out the dma/rwm - i hadn't in fact enabled these
when network booting.  however, even after enabling them, it still
going to take 20-40 minutes (estimate varies a bit)

it might very well be my slow disk, but i'd like to hear how other
people's systems compare.

i wonder if perhaps the rather complex fossil/venti directory structure
might be slowing things down?  also, my fossil cache size is 2000
blocks.  i would imagine this'd be sufficient to cache
parent-directory meta data, but perhaps i'm wrong.