Re: WAPBL vs. lfs?

[Thor Lancelot Simon <tls%rek.tjls.com@localhost>]

On Mon, Aug 25, 2008 at 12:03:12AM +0200, Joerg Sonnenberger wrote:
> On Fri, Aug 22, 2008 at 04:54:06PM -0400, Thor Lancelot Simon wrote:
> > However, LFS in 4.x can use between 75% and 100% of the disk bandwidth for
> > writes whether those are small file writes, directory creates, removes,
> > you name it.  Try the same thing with WAPBL and you'll see that though it
> > is a lot faster than standard FFS, it's still able to use well under half
> > the maximum throughput of the disk in many such cases -- and that is even
> > if you don't subtract the extra-writes penalty for the journal (all
> > metadata is effectively written twice).
> 
> To be fair, the extra penalty you mention for WAPBL is not that large as
> the journal entries are consecutive storage on the disk and need only a
> single seek per flush. Especially if the journal can keep more than one
> version of a disk block (consider cvs up), it is a lot better on the
> disk as it doesn't force the ordered writes as softdep does. So saying
> that all metadata is written twice isn't excatly true and even if it
> does happen to be, wapbl allows the disk scheduler to work more
> efficient as it breaks the dependency cycles.

Regardless of the details (about which I believe you're mistaken) it is
still the case that, writing a continuous stream of directory or small
file creations, WAPBL does less than half the maximum throughput of the
underlying drive, while LFS can get close to 100% and is generally well
above 75%.  In normal operation there are no "dependency cycles" to break
in LFS.

How is it "not exactly true" that all metadata isn't written twice when
metadata is journalled?  After all, it has to get to its permanent location
on the disk somehow.

However, until someone steps up to fix LFS -- and our LFS code has some
fundamental design issues it inherited from its original Berkeley authors,
who should probably have left the original Sprite on-disk format alone! --
it's irrelevant.  This is a volunteer project; a number of the people who
are complaining that LFS no longer works are, in fact, capable of helping
fix it; from my point of view, if they're sufficiently disturbed that it
doesn't work, it's pretty clear what they should do!

I am very, very happy with WAPBL.  But it's important to understand its
inherent limitations.  For certain workloads, it will simply never perform
as well as LFS can.