On Tue, Jun 07, 2022 at 07:48:24PM +0800, Qu Wenruo wrote: > [BUG] > If we have a btrfs image with dirty log, along with an unsupported RO > compatible flag: > > log_root 30474240 > ... > compat_flags 0x0 > compat_ro_flags 0x40000003 > ( FREE_SPACE_TREE | > FREE_SPACE_TREE_VALID | > unknown flag: 0x40000000 ) > > Then even if we can only mount it RO, we will still cause metadata > update for log replay: > > BTRFS info (device dm-1): flagging fs with big metadata feature > BTRFS info (device dm-1): using free space tree > BTRFS info (device dm-1): has skinny extents > BTRFS info (device dm-1): start tree-log replay > > This is definitely against RO compact flag requirement. > > [CAUSE] > RO compact flag only forces us to do RO mount, but we will still do log > replay for plain RO mount. > > Thus this will result us to do log replay and update metadata. > > This can be very problematic for new RO compat flag, for example older > kernel can not understand v2 cache, and if we allow metadata update on > RO mount and invalidate/corrupt v2 cache. > > [FIX] > Just reject the mount unless rescue=nologreplay is provided: I agree that it's better to fail the mount and keep the log. The way out of that is to use newer kernel that supports it or explicitly clear the log. > BTRFS error (device dm-1): cannot replay dirty log with unsupport optional features (0x40000000), try rescue=nologreplay instead > > We don't want to set rescue=nologreply directly, as this would make the > end user to read the old data, and cause confusion. > > Since the such case is really rare, we're mostly fine to just reject the > mount with an error message, which also includes the proper workaround. I think this is a use case for 'btrfs rescue zero-log' that is not caused by a bug in the tree log code (ie. the original purpose for the tool), so this should be also documented.
