Date: Tue, 11 Dec 2001 01:08:23 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Greg Lehey <grog@FreeBSD.org> Cc: Alfred Perlstein <bright@mu.org>, Hiten Pandya <hitmaster2k@yahoo.com>, hackers@FreeBSD.org Subject: Re: [SUGGESTION] - JFS for FreeBSD Message-ID: <3C15CD07.6D5FC2E7@mindspring.com> References: <20011210220153.50612.qmail@web21102.mail.yahoo.com> <20011210161410.L92148@elvis.mu.org> <3C15AC5A.44BFD2BD@mindspring.com> <20011211183001.B67986@monorchid.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Greg Lehey wrote: > > FS porting to FreeBSD is actually pretty trivial(*), though some > > transactioning changes to the FreeBSD VFS layer consumers (the > > system calls and NFS server code) would be necessary to make > > the journal roll-back function correctly, following a failure. > > > > (*) Trivial: meaning grunt work is required; not necessarily an > > indicator of the amount of work, only the intellectual effort > > required for the job > > Considering that the current UFS implementation didn't need to be > ported, and people are still working on the details, I think that this > is a highly misleading statement. The current UFS has a number of issues which make it non-trivial; it was, in effect, a port; here is the short list: o Soft updates o Unified VM and buffer cache o Interface is still not entirely reflexive o VOP_READDIR restart via cookies, rather than seperate read/externalize VOPS, which would have avoided cookies o Gratuitous difference in cookie parameter order between FreeBSD and OpenBSD/NetBSD o "Default" VOPS considreably complicate stacking, which appears to be a goal nowm when it wasn't a goal before o New block size defaults (what happens to directories, which require atomicity and therefore use 512b blocks, is not explained in the 8K/1K case) o New directory acceleration code (dirhash; probably belongs in the directory name cache, not the FS) o NFS server code and system call code not treated as equal consumers of the VFS interface Live code always has issues, particularly if you are trying to pound a round peg into a square hole (hence Kirk taking up the task of a redesign). FWIW: I was a member of a very small team which ported the entire Heidemann framework, the UFS and FFS code of the time, and also implemented Soft Updates and Soft Read Only in 1996 or so. We had to port to the Windows 95 IFSMgr framework, add a second namespace, add Unicode support, deal with the 512b directory blocks growing to 1024b, while maintaining idempotence in the face of the loss of atomicity, etc.. Three people did almost all the work in about 5 months. The code is _not_ hard to get your head around. I think that everyone saying "Ut oh! SCARY!" gives people the wrong idea, and scares off potential contributors in these areas. Unlike most of the rest of the system, there are at least white papers available. I'd have to say the FS design was one of the better documented parts of FreeBSD, if you take the many McKusick, Heidemann, Ganager/Patt papers and articles into account. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C15CD07.6D5FC2E7>