Date: Tue, 1 Oct 1996 19:05:11 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: michaelh@cet.co.jp (Michael Hancock) Cc: roberto@keltia.freenix.fr, hackers@FreeBSD.org Subject: Re: VPS mailing list, BSD interest? Message-ID: <199610020205.TAA03025@phaeton.artisoft.com> In-Reply-To: <Pine.SV4.3.93.961002094349.1393C-100000@parkplace.cet.co.jp> from "Michael Hancock" at Oct 2, 96 10:01:11 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > According to Michael Hancock: > > > The ability to resize partitions in itself is worthwhile. > > > > Yes as long as we don't lose too much speed... Something I've always hated > > about JFS on AIX is that it is dog slow. > > VxFS isn't dog slow. VxFS and FFS are within 5% of the same speed on UnixWare, assuming you set your default block size for FFS to 8k (it defaults to 4k, apparently so that VXFS would look good). Which way the 5% goes depends on the operations. If you have ever worked on the VXFS source code (I did at USL), you will already know that it has piece of FFS in it; the directory entry management code is almost pure FFS, for instance. FFS in UnixWare 2.x implements delayed ordered writes (a patent-pending async write ordering guarantee mechanism belonging to USL -- it may have been patented by now). FFS in UnixWare 2.x kicks VXFS's ass by about 60%. JFS, on the other hand, is pretty dog slow. I always thought it was because of the GFS abstraction. > LFS, while very cool, is a very different animal. It requires a *lot* of > RAM by design because it assumes that the majority of reads will be done > on the cache. It optimizes disk writes at the expense of disk reads. > Probably a reasonable assumption for Future Cool Hardware, TM. 8-). > The LFS cleaner daemon scheduling algorithm might make for some > interesting work. When do you clean? The answer is going to be different > for different people. The cleaner code was only recently fixed up by Margo for Lite2. It didn't seem to work at all in Lite. > The current implementation still lacks an fsck, which you still would want > to have available. In a modern design, ther eis little need for an fsck barring catastrophic media failure -- you can fix everything in the mount. You would think that "Future Cool Hardware, TM" would be fault tolerant. 8-). 8-). > Contrast it with meta-data logging which is usually an extension of an > existing fs. Metadata logging isn't as interesting as logging in general. If you don't do logging in general, you don't buy yourself the ability to implement rollback/rollforward of transactions with implied state across several files. For instance, a data base record file and a database index file that uses a write of the new record to an unallocated record and a write of the index to a log to make the transaction atomic. File systems are the most interesting things... 8-). 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?199610020205.TAA03025>