Re: WAPBL and backwards compatibility

["Greg A. Woods; Planix, Inc." <woods%planix.ca@localhost>]

On 1-Aug-08, at 3:22 AM, Simon Burge wrote:
> - 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.

If the in-filesystem inode for the journal is (re)connected to lost 
+found by such a repair, and then the admin naively removes it, what  
will happen?

Ideally I think the next WAPBL-aware kernel to encounter the  
filesystem could maybe simply consider the filesystem to be  
"downgraded" completely to a pre-WAPBL filesystem.  Will it work this  
way now?


> - 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.

If the WAPBL journaled filesystem really is otherwise 100% backward  
compatible in on-disk layout terms (except for the unconnected journal  
inode), then I would agree that there's no need to bump the FFS magic  
number.

Operationally the combination of these things makes it safe to use  
WAPBL in production without special controls as it would be OK for  
anyone to boot an older CD, for example, to repair a damaged system  
that happened to have one or more WAPBL journaled filesystems.

--
                                        Greg A. Woods; Planix, Inc.
                                        <woods%planix.ca@localhost>