From owner-freebsd-current Tue Nov 12 00:44:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA02884 for current-outgoing; Tue, 12 Nov 1996 00:44:53 -0800 (PST) Received: from whale.gu.kiev.ua ([194.93.190.4]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA02878 for ; Tue, 12 Nov 1996 00:44:43 -0800 (PST) Received: from creator.gu.kiev.ua (stesin@creator.gu.kiev.ua [194.93.190.3]) by whale.gu.kiev.ua (8.7.5/8.7.3) with SMTP id KAA93618; Tue, 12 Nov 1996 10:42:56 +0200 Date: Tue, 12 Nov 1996 10:42:54 +0200 (EET) From: Andrew Stesin X-Sender: stesin@creator.gu.kiev.ua To: Michael Smith cc: jgreco@brasil.moneng.mei.com, freebsd-current@freebsd.org Subject: Re: ufs is too slow? In-Reply-To: <199611120007.KAA12318@genesis.atrad.adelaide.edu.au> Message-ID: X-NCC-RegID: ua.gu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello people, just some (presumably bogus ;) comments of mine... > > 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. If only some filesystem and kernel Guru considered writing FFS-B -- FFS with B-tree used for directory structures, no other modifications; _that_ would probably be the best bet for FS with a BIG (3000+ files per dir) directories? Or another (plain bogus ;) approach for NewsFS: take a raw partition, and create a BerkeleyDB, "One Big B-tree" over it... put everything there, including article bodies, and all indices nessesary, set a size of memory-pool buffer inside innd as appropriate -- and what will happen? Just a plain big multi-table database, should be pretty simple and fast. > 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. Anyway, good algorithms will give you some win even on cheap and crappy HW. As for me, I won't be able to afford anything but cheap IDE for my home PC for a long time yet. :) This doesn't mean of course that I will never want to run some small, 1Gb or even smaller, news spool on it. ;) -- Best, Andrew Stesin nic-hdl: ST73-RIPE