Re: [9fans] fossil speed

[rog@vitanuova.com]

[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]

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.

[-- Attachment #2: Type: message/rfc822, Size: 2922 bytes --]

From: andrey mirtchovski <mirtchov@cpsc.ucalgary.ca>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] fossil speed
Date: Wed, 26 Jan 2005 14:36:29 -0700
Message-ID: <bcad6afcd37a3dc9f5ec58a336592223@plan9.ucalgary.ca>

> has anyone else found fossil to be very slow?  even when it's not
> using venti at all (e.g.  extracting a large tar archive).
> 

"almost" identical machines using ide disks (2.0 vs 2.6ghz cpu's):

on plan9:

	plan9% time tar cv xen | gzip > xen.tgz
	a xen/9pccpu 3189 blocks
	a xen/etc_xen_plan9 7 blocks
	a xen/kfs_root_image.gz 298211 blocks
	0.42u 6.48s 56.15r 	 tar cv xen
	plan9%

then this very same file was copied and untarred on the linux box:

	$ time tar cvf - xen | gzip > xen.tgz
	xen/
	xen/9pccpu
	xen/etc_xen_plan9
	xen/kfs_root_image.gz
	
	real    0m29.123s
	user    0m22.805s
	sys     0m2.635s
	$ 

i have both rwm and dma turned on.  the disks are IDE in both cases.
for Plan 9, fossil is mounted through a devfs mirror of two disks,
which should slow it down even more.

andrey