From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <cf345dbcdec4a749ac3c3fadd167f497@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] SCSI or IDE? 
From: "Russ Cox" <rsc@plan9.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Date: Mon, 31 Mar 2003 08:23:02 -0500
Topicbox-Message-UUID: 87cdcdf4-eacb-11e9-9e20-41e7f4b1d025

> In addtion, I'm anxious of what rog said here before.
> Something like venti+fossil is slower than kfs system on his notebook. ☺
> 
> I know kfs is very slow when compared with my real file server with SCSI
> disks.   So, if venti+fossil is slower than kfs, hmmm...

Kfs and the real file server are effectively the same.
The difference is that kfs typically uses 2MB of file
system buffer while the real file server uses all
available memory, so of course the real file server
will outperform kfs.  I think that if you gave kfs as
much memory as the real server uses, you'd see
they were comparable.  Also, your kfs might be slow
because you haven't enabled dma -- it's turned off by
default in the IDE driver.  echo dma on >/dev/sdC0/ctl
and your system might get a lot faster.

There's nothing inherently slower about kfs vs fs.

Fossil+venti is slow at uncached reads, because venti
is slow at doing reads.  

> By the way, in venti document, there is a point to make it faster by
> separating index and log.

The Venti index is a giant on-disk hash table.
Read performance is dominated by random disk
seeks -- a random seek to load the right hash
bucket followed by a random seek to get to the
right place in the arenas.  Write performance is
also dominated by random disk seeks -- one random
seek to read the right hash bucket, then a write
to the arena, then a write to the hash bucket.

If you are trying to set up a production Venti server,
then you would stripe the index across ten small
disks so that there could be ten index operations
going on at once.  Even just keeping the index
on a separate disk from the arenas is a big win
for writes: if they're on the same disk, then you have
to seek away from the hash bucket to update the arena,
and then back again, so that's three big seeks instead
of one. 

At the moment, if you want blazingly fast performance,
then fossil+venti isn't the way to go.  But if you want
respectable performance for supporting a bunch of
users running Plan 9, then it's still a plenty good option.

Again, if you use IDE disks and don't turn dma on, 
your fossil will be very very slow.  Turn on dma,
give it some memory to cache with (I'm using 24MB
on my laptop, as I suggested in a previous post,
and I like it much better), and you'll be happy.

Also, Forsyth found a debugging statement I'd left
in the code that was making the free block allocator
much slower than it needed to be.  This was about
a week ago now.  It speeds things up a fair amount.

Russ