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.