From owner-freebsd-chat Mon Sep 4 01:40:20 1995 Return-Path: chat-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id BAA22361 for chat-outgoing; Mon, 4 Sep 1995 01:40:20 -0700 Received: from haywire.DIALix.COM (haywire.DIALix.COM [192.203.228.65]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id BAA22347 for ; Mon, 4 Sep 1995 01:40:13 -0700 Received: (from peter@localhost) by haywire.DIALix.COM (sendmail) id QAA14759; Mon, 4 Sep 1995 16:39:28 +0800 (WST) Date: Mon, 4 Sep 1995 16:39:27 +0800 (WST) From: Peter Wemm To: Brian Tao cc: dillon@best.com, freebsd-chat@freebsd.org Subject: Re: FreeBSD vs. BSD/OS disk performance In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: chat-owner@freebsd.org Precedence: bulk On Mon, 4 Sep 1995, Brian Tao wrote: > On 29 Aug 1995, Peter Wemm wrote: > > > > Didn't Matt Dillon mention that his Disk IO comparisons between BSD/OS > > and FreeBSD that showed that FreeBSD wiped the floor with BSD/OS? And > > didn't somebody from UUNET suggest he was mistaken and challenge him > > to post numbers, to which Matt responded by posting some benchmarks > > showing something like a 5-times improvement? > > I'd *love* to see these numbers. BSD/OS used to only support the > Buslogics controllers, and recently added NCR support, but I don't > know how good it is. Probably still can't use the Adaptec 2940/3940 > controllers. I didn't pay much attention when it was first posted, but I remember thinking that it sounded like BSD/OS wasn't doing clustering properly, and was seriously suffering as a result. I know the newfs/mkfs/tunefs settings make a big difference to FreeBSD.. Performance is pretty lousy if the filesystem has the older-style rotational block layout where the blocks are not contiguous. I redid a mkfs on the box next to me, and saw a performance boost from about 600K/sec to about 3.0MB/sec - and that was on an old, slowish seagate disk.. :-) The thing I wonder though, is if that would make much difference to a news filesystem.. Raw throughput is not the issue, it's more a problem of head seek latency, and reducing the delays caused by doing sync inode and directory updates. FreeBSD-current can now turn off the sync inode updates, but FreeBSD doesn't have a trickle buffer update like SVR3, SVR4 and Linux do, so it's a little risky to defer your inode updates to a flurry of updates every 30 seconds. And, of course, turning off the sync inode updates removes a syncronous access time update each time a file is read from your news spool by a reader/nntpd/nfs access. Cheers, -Peter > -- > Brian ("Though this be madness, yet there is method in't") Tao > taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org > >