Date: Tue, 12 Nov 1996 10:42:54 +0200 (EET) From: Andrew Stesin <stesin@gu.net> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: jgreco@brasil.moneng.mei.com, freebsd-current@freebsd.org Subject: Re: ufs is too slow? Message-ID: <Pine.BSI.3.95.961112103004.19510C-100000@creator.gu.kiev.ua> In-Reply-To: <199611120007.KAA12318@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.95.961112103004.19510C-100000>