WAPBL and backwards compatibility

[Simon Burge <simonb%NetBSD.org@localhost>]

Hi folks,

Now that WAPBL is available in -current, there's one issue that I know
of that needs to be resolved - how to deal with backwards compatibility.

The problem is in a nutshell that there's no way for old fsck or
kernel to tell if there's any way that it shouldn't deal with the
current journaled filesystem.  Pavel Cahyna has previously suggested
that we look at adding something like ext2's "Feature Compatibility"
functionality to FFS.  In hindsight it would have been nice to have this
sort of thing two or three releases ago...

There's a couple of issues here:

 - Currently an old fsck will not know of the existance of the journal.
   If it sees a filesystem that wasn't unmounted cleanly with WAPBL
   active it will just think it was a "normal" crash and repair it as it
   normally would.  The problem is that next time you use a WAPBL-aware
   kernel or fsck_ffs will see the untouched dirty journal and replay
   it, possibly (probably?) causing damage.

 - Older fsck will not know what to do with the in-filesystem journal
   inode.  I think it'll probably just reconnect the log inode into
   lost+found, but I haven't tested this yet.

 - WAPBL has relaxed ordering constraints, since it knows it can replay
   the journal if there is a crash.  I'm not sure if in practice this
   can cause the filesystem to get into a state where a non-WAPBL-aware
   fsck_ffs can get too confused, and am also not too sure how to verify
   if this is really an issue.

There's a couple of approaches for dealing with this:

 - Loudly warn "DON'T DO THIS".  This seems like a bit of a cop-out.

 - Add a check in the current FFS WAPBL code (and fsck_ffs) to
   explicitly not replay the log if the filesystem is marked as clean.
   This would be on the assumption that something else has fixed it for
   you since you last mounted it with a WAPBL-aware kernel.

 - Bump the FFS magic number.  This seems like a bit of a sledge hammer
   approach, but may indeed be the most practical solution.  Someone
   asked privately about inter-operating system compatibility with
   FreeBSD and OpenBSD - the magic number change does solve this too.
   It was also suggested that we could have a tool (tunefs?) that could
   "downgrade" the magic number if there was a clean (or no?) journal.

 - Add the ext2's "Feature Compatibility" functionality.  Unfortunately
   that doesn't buy us backwards compatability with any previous NetBSD
   version.

I'm currently of the opinion that the second option above is the best
fix, but I can certainly see the benefits of a magic number change.

Can anyone else think of different approaches for dealing with this, or
have opinions on which approach is the best way?

Cheers,
Simon.