linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.
>>
> 

  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).