From owner-freebsd-current Tue Nov 12 11:03:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA13755 for current-outgoing; Tue, 12 Nov 1996 11:03:34 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA13734 for ; Tue, 12 Nov 1996 11:03:23 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA20717; Tue, 12 Nov 1996 11:50:47 -0700 From: Terry Lambert Message-Id: <199611121850.LAA20717@phaeton.artisoft.com> Subject: Re: ufs is too slow? To: michaelh@cet.co.jp (Michael Hancock) Date: Tue, 12 Nov 1996 11:50:47 -0700 (MST) Cc: jgreco@brasil.moneng.mei.com, bsdcur@shadows.aeon.net, freebsd-current@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at Nov 12, 96 03:58:01 pm X-Mailer: ELM [version 2.4 PL24] 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 > > 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. For small files. FAT chains must be linearly traversed, so their performance decreases expotentially (after you normalize for base access rates which are not related to element structure). > I agree that btree scheme would improve the large directory read > performance, while a soft update scheme would improve write performance in > ufs. Yes. Actually, I've been wanting to divorce the VOP's for directory entry manipulation in the same way the FFS/UFS divorce was handled for about three years now (I wanted to do it to UnixWare UFS at Novell). This would allow you to replace the directory entry management with a btree (or whatever you wanted -- skiplists, etc. would probably be a better idea for flexname support) without touching the data store. The problem is that the directory entry I/O is done with block I/O instead of VOP_{READ|WRITE}. Bogus. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.