On 2018/10/11 下午8:31, David Sterba wrote: > On Thu, Oct 04, 2018 at 01:49:49PM +0800, Qu Wenruo wrote: >> We have btrfs_super_block::log_root_transid to record the transid of log >> tree root. >> >> However it's never populated and it's always 0, just as the following >> dump-super: >> log_root 30572544 >> log_root_transid 0 >> log_root_level 0 >> >> This patch will populate it with log tree root correctly, so the result >> will be: >> log_root 30572544 >> log_root_transid 6 >> log_root_level 0 >> >> This won't affect current kernel behavior or btrfs check result as we >> already expect log tree root generation always to be super block >> genration + 1. >> >> But it could be later used to detect log tree corruption early. > > The backward compatibility seems to be ok in general, I found one > scenario where the check will fail: > > * mount with unpatched kernel, log_root_transid = 0 > * mount with patched kernel, log_root_transid 100, generation 101 > * mount with unpatched kernel, log_root_transid 100 (unchanged), generation > 201 > * mount with patched kernel -> check fails
Indeed, this is a problem I missed. It provides the old principle, if we're going to change how kernel use/interprete a on-disk memeber, we have to introduce a new incompatible flag. Please just drop the series of patch. Thanks, Qu > > So the problem is when log_root_transid is not 0 and changes out of sync > with the generation. The above sequence of kernels can simply happen > when switching between old stable and current releases. >
signature.asc
Description: OpenPGP digital signature
