tech-kern archive

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

Home | Main Index | Thread Index | Old Index