[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: WAPBL and backwards compatibility
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
> 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
fs->fs_clean =<< 1
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.
NetBSD: 26 ans d'experience feront toujours la difference
Main Index |
Thread Index |