Re: softdeps and NetBSD 6.0

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

On Wed, Sep 30, 2009 at 08:44:38PM +0200, Marc Balmer wrote:
>
> there is also a middle ground.  the code/filesystem could just be left  
> there for people to use it, with all it's "known bugs".

Not really.  As Andy pointed out when he originally proposed removing
softdep, the softdep implementation we actually have (as opposed to the
one we might perhaps like to have) is entangled in various horrible ways
with the FFS, UFS, and VM code.  Having it in there makes maintaining all
of that code harder and makes developing new code that interacts with any
of those parts of the system harder.  And in more than one case, the
softdep code -- when not in use! -- has caused serious bugs in the other
components of the system which is touches.

In other words, there's a huge opportunity cost to leaving the softdep
code in the kernel.  By comparison, the wapbl code is much cleaner and
better modularized -- its one major wart is that it duplicates ufs_rename(),
which means bugs can need to be fixed twice, but on the other hand that
means wapbl bugs are isolated to wapbl; they don't infect the rest of the
I/O code the way softdep does.

If we had a softdep implementation that didn't have the bizarre history
and implementation Kirk's does, things would be different.  But we do not
have such an implementation, there is no such implementation available,
and I hardly see any of the people who are complaining about softdep
going away stepping up to write one!

So, unless we want to keep the rest of the filesystems buggy and impede
most future progress in that area as part of some notional "middle ground",
there really is no middle ground.  We have a replacement that is acceptable
for most purposes, and better for many purposes, and softdep has to go.

The only real advantage softdep offers over journaling is a decreased total
amount of I/O, because journaling duplicates some transactions while softdep
can eliminate others completely.  However, there are other filesystems
available that offer the same advantage without stretching slimy tentacles
through the ufs code and the rest of the kernel -- ZFS, for example.  If we
keep the softdep code in the kernel, we make _everything_ to do with new
filesystems harder, and that means we are much less likely to get new good
filesystems like ZFS and keep them maintained.  Not a good "middle ground"
if you ask me.

-- 
Thor Lancelot Simon                                        
tls%rek.tjls.com@localhost
    "Even experienced UNIX users occasionally enter rm *.* at the UNIX
     prompt only to realize too late that they have removed the wrong
     segment of the directory structure." - Microsoft WSS whitepaper