Date: Tue, 12 Nov 1996 11:50:47 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: michaelh@cet.co.jp (Michael Hancock) Cc: jgreco@brasil.moneng.mei.com, bsdcur@shadows.aeon.net, freebsd-current@FreeBSD.ORG Subject: Re: ufs is too slow? Message-ID: <199611121850.LAA20717@phaeton.artisoft.com> In-Reply-To: <Pine.SV4.3.95.961112154926.3824A-100000@parkplace.cet.co.jp> from "Michael Hancock" at Nov 12, 96 03:58:01 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611121850.LAA20717>