On Tue, Feb 15, 2000 at 10:34:54AM +1100, Luke Mewburn wrote:
> Miles Nordin writes:
> > 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 don't think that's corrent. As far as I am aware, NetApp's WAFL is
> not an enhanced 4.4BSD LFS. WAFL *does* have a transaction log, but
> that's to non-volatile RAM which is then applied against the buffers
> and written out in an optimised way to take advantage of free chunks
> of disk near the current disk head position.

IIRC the original WAFL papers rather copiously referenced the original
Sprite LFS work, but yeah, they're similar but not at all the same
filesystem.

The interesting thing, to me, is that most of the cases that are
pathological for LFS are also pathological for WAFL (of course NetApp
is highly unlikely to admit this, but it's easy enough to demonstrate)
because both are extremely sensitive to certain workloads, basically
anything that violates the temporal-locality-of-reference assumption
that's how each has even a chance in hell of providing reasonable
read performance.  Aggressive read-ahead as NetApps do by default,
of course, makes this even worse, and people aren't generally smart
enough to turn this off when it would be a good idea to do so...