From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <1cc4d6a83793875fa8fdf894eceec081@vitanuova.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] fossil speed Date: Wed, 26 Jan 2005 22:26:12 +0000 From: rog@vitanuova.com In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-kxnrcqsuedwdcvrikshebdwxha" Topicbox-Message-UUID: 3668fe86-eace-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-kxnrcqsuedwdcvrikshebdwxha Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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. --upas-kxnrcqsuedwdcvrikshebdwxha Content-Type: message/rfc822 Content-Disposition: inline Received: from mail.cse.psu.edu ([130.203.4.6]) by doppio; Wed Jan 26 21:39:45 GMT 2005 Received: from psuvax1.cse.psu.edu (localhost [127.0.0.1]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 807CFC67F4 for ; Wed, 26 Jan 2005 16:37:03 -0500 (EST) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: from localhost (localhost [127.0.0.1]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id AB63A63FE3 for <9fans@cse.psu.edu>; Wed, 26 Jan 2005 16:36:32 -0500 (EST) Received: from mail.cse.psu.edu ([127.0.0.1]) by localhost (psuvax1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 04908-01-90 for <9fans@cse.psu.edu>; Wed, 26 Jan 2005 16:36:31 -0500 (EST) Received: from plan9.ucalgary.ca (plan9.ucalgary.ca [136.159.220.110]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 09CC263FB0 for <9fans@cse.psu.edu>; Wed, 26 Jan 2005 16:36:30 -0500 (EST) Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] fossil speed Date: Wed, 26 Jan 2005 14:36:29 -0700 From: andrey mirtchovski In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces+rog=vitanuova.com@cse.psu.edu Errors-To: 9fans-bounces+rog=vitanuova.com@cse.psu.edu > 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 --upas-kxnrcqsuedwdcvrikshebdwxha--