Re: Removing softdep

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, Jun 07, 2008 at 12:11:57AM +0100, Andrew Doran wrote:
 > Over the last year I spent quite a lot of time working on ffs and softdep.
 > With softdep there are many remaining deadlock conditions and bugs that we
 > know about, and it's very likely there are more to be discovered. I also
 > know from experience that softdep on NetBSD does not fulfill its data
 > integrity promises.

Many people have had little trouble with it, though. For me its record
has been noticeably better than ffs *without* softupdates.

Furthermore, it does generally prevent the silent data corruption that
traditional ffs is quite vulnerable to by design.

I don't think it's yet time to write it off, although it may be time
to do, er, `heavy revisions'.

Are the known bugs filed as PRs? Can you send me the list, for
reference?

 > After 5.0 is branched we're planning to merge in the ffs journalling code
 > contributed by Wasabi. It could use some performance improvements on
 > multiuser systems, and maybe a few other tweaks like auto-creating the
 > journal. However, it _is_ known to meet its data integrity promises, and is
 > a much easier code base to maintain and work with.

It does not, however, according to what I've been told, promise to
maintain data integrity; it does the same thing traditional ffs does,
that is, update block pointers before the data they point to. So files
will continue to exchange contents in crashes.

This should be fixed, but until it's fixed we shouldn't be considering
removing softupdates.

 > So, I propose to remove softdep when we import the journalling code, and to
 > go forward with the focus on improving journalling.

Also, from a release engineering standpoint we ought to have at least
one stable release with both softdep and journaling, so users can
switch over at *their* convenience rather than being forced to by an
upgrade.

So even if the long-term plan is removal I think actually *doing* the
removal would be highly premature at this point.

-- 
David A. Holland
dholland%netbsd.org@localhost