From owner-freebsd-current Mon Nov 11 16:11:37 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA23465 for current-outgoing; Mon, 11 Nov 1996 16:11:37 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA23448 for ; Mon, 11 Nov 1996 16:11:26 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id KAA12318; Tue, 12 Nov 1996 10:37:35 +1030 (CST) From: Michael Smith Message-Id: <199611120007.KAA12318@genesis.atrad.adelaide.edu.au> Subject: Re: ufs is too slow? In-Reply-To: <199611111704.MAA12463@fnur.3skel.com> from Dan Janowski at "Nov 11, 96 12:04:35 pm" To: danj@3skel.com (Dan Janowski) Date: Tue, 12 Nov 1996 10:37:34 +1030 (CST) Cc: bsdcur@shadows.aeon.net, jgreco@brasil.moneng.mei.com, freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Dan Janowski stands accused of saying: > > At one point I had inquired about lfs (log file system), in > part because of my experience with xfs (SGI's). Although lfs > is not xfs, they are both better performers than ufs/ffs (which > are both REALLY old, I think ufs dates from the 50's and ffs > from the 70's). I don't know where you get this idea from. FFS, especially with some of the performance tweaks available in FreeBSD, is pretty snappy. As has been observed, SGI's xfs is rather fragile, and Terry's comments about log-structured filsystems are worth bearing in mind. > I have seen that OpenBSD is doing something with lfs, but I > am not sure what. It would be worth while to get lfs running > for sure; if you ever wondered, a lot of that disk bandwith > goes to filesystem overhead. Theo's words on lfs were essentially "I've never heard of it working outside Margo's lab", in a context which I read as "lfs is bogus". > Maybe we can all talk about it a little and figure out > how hard it would be to get going. If we were running > a kick-ass big/fast file system, FreeBSD would capture > some more of the Int(er|tra)+Net market. In addition > to which, the infamous 'make world' time would surely > benefit. I doubt that a working lfs would actually offer much, if any, in the way of performance in anything other than the applications that it handles well. As a consequence of the data acquisition stuff that we do, we often end up with directories with literally thousands of fairly large files in them; a BSD ffs filesystem mounted async,noatime is _significantly_ faster at moving/copying/deleting this sort of stuff than any of the other (Solaris, OSF, NTFS, HPFS, FAT) filesystems that we've ever put data on. One of the most notable performance improvements can actually be had by using SCSI disks and controllers that support tagged queueing; don't ever make the mistake of benchmarking an IDE based disk subsystem against anything else. > Dan -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[