On 11.10.2018 15:45, Qu Wenruo wrote:
>
>
> 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.
Since this member really doesn't have any purpose now I think the
prudent thing to do is to rename it to "reserved1" or "padding" or
whatever but basically signal that it's no longer in used. In the future
when a new incompaat bit will be required for some feature it can be
re-used.
>
> 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.
>>
>
