From: Anand Jain <anand.jain@oracle.com>
To: dsterba@suse.cz, linux-btrfs@vger.kernel.org, dsterba@suse.com,
Nikolay Borisov <nborisov@suse.com>,
wqu@suse.com
Subject: Re: [PATCH RESEND v2 1/3] btrfs: drop never met condition of disk_total_bytes == 0
Date: Fri, 6 Nov 2020 08:20:12 +0800 [thread overview]
Message-ID: <019a25c1-d4d2-02e3-3b82-2ae46384b8d3@oracle.com> (raw)
In-Reply-To: <20201105223654.GO6756@twin.jikos.cz>
On 6/11/20 6:36 am, David Sterba wrote:
> On Tue, Nov 03, 2020 at 01:49:42PM +0800, Anand Jain wrote:
>> btrfs_device::disk_total_bytes is set even for a seed device (the
>> comment is wrong).
>
> That's where I'm a bit lost. It was added in 1b3922a8bc74 ("btrfs: Use
> real device structure to verify dev extent").
>
The call chain where we update the btrfs_device::disk_total_bytes is as
below..
read_one_dev()
::
From the section below we get the cloned copy of the seed device.
-----
if (memcmp(fs_uuid, fs_devices->metadata_uuid, BTRFS_FSID_SIZE)) {
fs_devices = open_seed_devices(fs_info, fs_uuid);
if (IS_ERR(fs_devices))
return PTR_ERR(fs_devices);
}
device = btrfs_find_device(fs_info->fs_devices, devid, dev_uuid,
fs_uuid);
------
Further down in read_one_dev() at and in the
fill_device_from_item(..., device) we update the
btrfs_device::disk_total_bytes.
fill_device_from_item(..., device)
::
device->disk_total_bytes = btrfs_device_total_bytes(leaf,
dev_item);
Hope this clarifies.
V1 email discussion has more information.
>> The function fill_device_from_item() does the job of reading it from the
>> item and updating btrfs_device::disk_total_bytes. So both the missing
>> device and the seed devices do have their disk_total_bytes updated.
>>
>> Furthermore, while removing the device if there is a power loss, we could
>> have a device with its total_bytes = 0, that's still valid.
>
> Ok, that's the condition that the commit mentioned above used to detect
> the device and to avoid doing the tree-checker verification.
Ok. Please look at what did the commit 1b3922a8bc74 do? It re-ran the
btrfs_find_device(seed_devs,..., false), which anyway the
btrfs_find_device(sprout_devs,..., true) has run just before. In both of
these btrfs_find_device() runs, the dev returned will be the same. The
fix makes no sense to the problem as in the commit.
>
>> So this patch removes the check dev->disk_total_bytes == 0 in the
>> function verify_one_dev_extent(), which it does nothing in it.
>
> Removing a check that supposedly does notghing, but the referenced
> commit says otherwise.
>
IMO the reason for the problem found in that commit was wrong. Qu
commit's email thread has some discussion. But nothing more on the problem.
Also Nikolay had the same question here was my reply.
https://www.spinics.net/lists/linux-btrfs/msg105645.html
>> And take this opportunity to introduce a check if the device::total_bytes
>> is more than the max device size in read_one_dev().
>
> If this is not related to the the check removal, then it should be an
> independent patch explaing in full what is being fixed. As I read it
> this should be independent as it's checking the upper bound.
>
That came from the Josef comments, please refer to the v1 email
discussion. Most of the above concerns are already discussed there. I am
ok to move it to a new patch if required.
Thanks, Anand
next prev parent reply other threads:[~2020-11-06 0:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-03 5:49 [PATCH RESEND v2 0/3] cleanup btrfs_find_device and fix sysbot warning Anand Jain
2020-11-03 5:49 ` [PATCH RESEND v2 1/3] btrfs: drop never met condition of disk_total_bytes == 0 Anand Jain
2020-11-05 22:36 ` David Sterba
2020-11-06 0:20 ` Anand Jain [this message]
2020-11-11 15:33 ` David Sterba
2020-11-03 5:49 ` [PATCH RESEND v2 2/3] btrfs: fix btrfs_find_device unused arg seed Anand Jain
2020-11-03 5:49 ` [PATCH RESEND v2 3/3] btrfs: fix devid 0 without a replace item by failing the mount Anand Jain
2020-11-11 15:51 ` [PATCH RESEND v2 0/3] cleanup btrfs_find_device and fix sysbot warning 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=019a25c1-d4d2-02e3-3b82-2ae46384b8d3@oracle.com \
--to=anand.jain@oracle.com \
--cc=dsterba@suse.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=nborisov@suse.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).