On Thu, 3 Feb 2000, Brian Gregor wrote:

> Does anyone know how JFS compares with LFS in NetBSD?

JFS is (i think?) the ancestor of the Veritas filesystem, so it is in
practically every VendorUnix, and maybe even some releases of Netware--not
sure.

One cool thing about the AIX implementation is that you can shrink and
grow _mounted_ filesystems.  Depending on how much code they actually
release--this is always a huge issue with these little attention-hogging
annoucements--JFS could have some polished features LFS doesn't.

I'd be willing to bet LFS is cleaner, smaller, and easier to maintain.  I
think this is a safe bet, knowing how code gets written inside big
companies, but I've never compared the two.  These are good things for LFS
because it means LFS is in a better position to incorporate research ideas
and actually come out working than JFS is.  ex., one such idea:

 http://mail-index.netbsd.org/current-users/1999/05/24/0013.html

I haven't answered your question.  The old thread will tell you that LFS
is used in the NetApp, so this will give you some idea what
speed/reliability goals are attainable by the original LFS code, given a
bit of funded development on NetApp's part.  I think we're basically
``there'' ourselves thanks to Konrad Schroeder's work, but I'm not in a
great position to tell.  LFS is obviously good performance-wise.  I am not
aware of any technical liabilities of LFS that limits its performance, and
we discussed this extensively last May.  I'd be surprised to hear that JFS
beats it usefully, and it's likely JFS doesn't beat it at all.  But, once
we get to a certain point (where, I think, we're at, with LFS and
FFS-softupdates), squeezing for milliseconds gets to be silly and
uncreative.  Instead, it's worth more to implement RT filesystem
scheduling like the BeFS, support online contraction/expansion like JFS,
intelligently use RAID stripes like LFS, or tweak the cleaner, integrate
better with Coda, do snapshots for backup, invent some clever hooks for
lightweight (complex!) databases like the Sleepycat stuff, pursue
McKusick's latest crazy idea--that sort of thing.

My point is partly the same point I made when SGI hyped up their useless
release of XFS.  LFS is stylistically superior.  Maintaining corporate
code under our development model, with our developer-hour limitations, is
a bad idea.  Licensing (say, SCSL) can be FUD or it can be a mess.  These
bandwagon code releasers are all too often more distracting than useful,
and I'm always immediately suspicious of them even before I've got any
facts.  They make people think, ``hey, look!  free code!  we can just
[click] snap that in right here and gain five years on the so-called
`competing' free software projects,'' while in practice we get to sit back
and laugh while Linux tries to cram a spaghetti-shaped peg into a square
hole.

If you're wondering why I'm ``suspicious,'' see my (horribly rough)
thoughts on how NetBSD got the big shaft w.r.t. Java, in the midst of a
flurry of announcements ``we wrote this, we released this, we ported this
to that!'':

 http://www.cs.colorado.edu/~nordinm/assignments/

IBM, in case you haven't noticed, is up to their ears in this sort of
announcement these days.  and, no, the IBM JRE is not open-source.  AFAIK
it's not even you-get-to-see-the-source.  These JFS/XFS announcements cost
them nothing, and are littered with so many special cases and gotchya's as
to literally seem like they're laughing in our face.  Anyone know if XFS
was ever actually used by a single open-source project?  I know which one
would use it, if any, and AFAIK it didn't.

-- 
Miles Nordin / v:+1 720 841-8308 fax:+1 530 579-8680
555 Bryant Street PMB 182 / Palo Alto, CA 94301-1700 / US