On Tue, Aug 29, 2023 at 04:09:35PM -0700, Darrick J. Wong wrote: > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > Fix log recovery to proceed on a readonly mount if the primary sb > advertises unknown rocompat bits. We used to allow this, but due to a > misunderstanding between Eric and Darrick back in 2018, we accidentally > changed the superblock write verifier to shutdown the fs over that exact > scenario. As a result, the log cleaning that occurs at the end of the > mounting process fails. > > We now allow writing of the superblock if there are unknown rocompat > bits set, but only if the filesystem is read only. Hence we still have > to remove all ro state toggling that occurs around the log mount calls. APart from the wording of the commit message, this all looks good. It took me a little while to parse what it meant paragraph meant, so can I suggest something like: Log recovery has always run on read only mounts, even where the primary superblock advertises unknown rocompat bits. Due to a misunderstanding between Eric and Darrick back in 2018, we accidentally changed the superblock write verifier to shutdown the fs over that exact scenario. As a result, the log cleaning that occurs at the end of the mounting process fails if there are unknown rocompat bits set. As we now allow writing of the superblock if there are unknown rocompat bits set on a RO mount, we no longer want to turn off RO state to allow log recovery to succeed on a RO mount. Hence we also remove all the (now unnecessary) RO state toggling from the log recovery path. Other than that, Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx> -- Dave Chinner david@xxxxxxxxxxxxx
