From: Nikolay Borisov <nborisov@suse.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>,
dsterba@suse.cz, Qu Wenruo <wqu@suse.com>,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 1/2] btrfs: Populate btrfs_super_block::log_root_transid
Date: Thu, 11 Oct 2018 16:11:32 +0300 [thread overview]
Message-ID: <2971327e-aa24-534c-cbfb-3ba9f399c6f2@suse.com> (raw)
In-Reply-To: <ba395b06-ff1a-1926-5339-3a2927e3af0f@gmx.com>
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.
>>
>
next prev parent reply other threads:[~2018-10-11 13:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-04 5:49 [PATCH 0/2] btrfs: btrfs_super_block::log_root_transid related enhancement Qu Wenruo
2018-10-04 5:49 ` [PATCH 1/2] btrfs: Populate btrfs_super_block::log_root_transid Qu Wenruo
2018-10-04 8:07 ` Anand Jain
2018-10-04 8:28 ` Qu Wenruo
2018-10-11 12:31 ` David Sterba
2018-10-11 12:45 ` Qu Wenruo
2018-10-11 13:11 ` Nikolay Borisov [this message]
2018-10-11 13:13 ` Qu Wenruo
2018-10-04 5:49 ` [PATCH 2/2] btrfs: Validate btrfs_super_block::log_root_transid Qu Wenruo
2018-10-04 6:57 ` Nikolay Borisov
2018-10-04 7:30 ` Qu Wenruo
2018-10-11 12:19 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2971327e-aa24-534c-cbfb-3ba9f399c6f2@suse.com \
--to=nborisov@suse.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=wqu@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).