[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: WAPBL and backwards compatibility
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
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
- 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
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.
Main Index |
Thread Index |