[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: speed of ffs (OpenBSD / 4.3BSD)
> From: Bas Oude Nijeweme <firstname.lastname@example.org>
> Date: Sun, 17 May 1998 04:27:14 +0200 (CEST)
> Wondering, when mounted on a linux box, the OpenBSD fs partitions are
> _much_ faster than under OpenBSD itselves.
Are you sure it's the fs code that is faster? My guess is that you
are running on a modern IDE disk and that the Linux IDE driver is much
faster than ours. That is not much of a surprise really. We'd
welcome anyone who wants to improve our IDE driver. Now, if you are
running SCSI it'd be more interesting to know more about this
situation. What SCSI controller? What is the raw read performance,
both for big blocks (64k) and for small (8k)? What's the read and the
write performance through the fs? Of course it's be good to see both
the OpenBSD and the Linux figures. Always do the tests over
several megabytes, like 100 or so, if you do less there are
possibilities you are measuring your buffercache instead. Hmm that's
another difference between Linux and OpenBSD of course. If you test
on an idle system with small sizes, chances are you don't even hit the
disk in the Linux test. I believe Linux is asynch always (is this
so?) and the cache is dynamically sized to eat up your RAM effectively
so the test scenario might be very optimistic compared to a real world
> Howcome ? And besides asynchronous mounts, how can I speed things up ?
Bigger fs blocks, but that will waste more disk. On fast setups I use
16K blocksize and 2k fragment size (usually over a striped 2-disk ccd).
On big memory systems you can raise BUFCACHEPERCENT to get a bigger
buffer cache. I run a fileserver with 128MB RAM with 50% cache.
> (read something on tunefs and softupdates but my tunefs (bin install from
> 2.2) doesn't have that option.)
That's right, get 2.3 when it comes out. It's a matter of weeks. The
CDs will go to the ones who pre-order first, so now's your chance to
be at the top of the list.