From owner-freebsd-current Mon Nov 11 23:00:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA27390 for current-outgoing; Mon, 11 Nov 1996 23:00:54 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA27383 for ; Mon, 11 Nov 1996 23:00:51 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.2/CET-v2.1) with SMTP id GAA04113; Tue, 12 Nov 1996 06:58:01 GMT Date: Tue, 12 Nov 1996 15:58:01 +0900 (JST) From: Michael Hancock To: Joe Greco cc: mika ruohotie , freebsd-current@FreeBSD.ORG Subject: Re: ufs is too slow? In-Reply-To: <199611111503.JAA19277@brasil.moneng.mei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Nov 1996, Joe Greco wrote: > FFS is in general a great FS... but it is optimized for the general case. > > It is particularly poor at handling large directories or lots of writes, > and news is excellent at pounding on these qualities. NTFS uses btrees for large directories and a simple linear method for small directories. I've seen some tuning tips for SQLServer where they recommended NTFS for the db and FAT for the logs because NTFS had faster read performance but FAT had faster write performance. I agree that btree scheme would improve the large directory read performance, while a soft update scheme would improve write performance in ufs. Regards, Mike Hancock