Re: WAPBL and backwards compatibility

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Fri, Aug 01, 2008 at 05:22:09PM +1000, Simon Burge wrote:
> 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?

I suggested some time ago (on a private list most probably):
  Maybe we can use the fs_clean field of the superblock for this, 
  with a new FS_ISLOG flag defined as 0xc0 (i.e. last 2 bits). Non-wapl tools
  will either
  do
        fs->fs_clean =<< 1
  or
        fs->fs_clean =  FS_ISCLEAN 
  
  and in any case I don't think you can end up with the last 2 bits set once
  a filesystem has been mounted or fsck'd by old tools/kernel.
  Using only FS_ISCLEAN can lead to an old log being applied to a filesytem 
  that was mounted R/W on an non-logging kernel, and not unmounted cleanly.

This doesn't prevent adding, at the same time, feature fields a la ext2fs.

-- 
Manuel Bouyer, LIP6, Universite Paris VI.           
Manuel.Bouyer%lip6.fr@localhost
     NetBSD: 26 ans d'experience feront toujours la difference
--