On Mon, Feb 05, 2024 at 12:09:23PM +1100, Dave Chinner wrote: > The issue arises if the host tries to mount the guest VM image to > configure the clone of a golden image prior to first start. If there > are log incompat fields set in the golden image that was generated > by a newer kernel/OS image builder then the provisioning > host cannot mount the filesystem even though the log is clean and > recovery is unnecessary to mount the filesystem. Well, even with the current code base in Darrick's queue a mount alone won't upgrade features, you need to do an explicit exchrange or online repair operation. And I think we should basically never do log or other format incompatible changes without an explicit user action. The only exception would be if the feature is so old that we finally want to get rid of the old implementation, in which case we can think of automatically doing the upgrade with a big fat warning. > Hence on unmount we really want the journal contents based log > incompat bits cleared because there is nothing incompatible in the > log and so there is no reason to prevent older kernels from > mounting the filesytsem. Doing the clearing at unmount time only (and maybe freeze if someone really cares) sounds perfectly fine.
