From: Anand Jain <anand.jain@oracle.com>
To: Josef Bacik <josef@toxicpanda.com>, linux-btrfs@vger.kernel.org
Cc: Johannes.Thumshirn@wdc.com
Subject: Re: [PATCH v2] btrfs: free device without BTRFS_MAGIC
Date: Wed, 30 Sep 2020 15:21:48 +0800 [thread overview]
Message-ID: <2d4b10fd-a5f4-7e6b-85f4-f92591e2a539@oracle.com> (raw)
In-Reply-To: <abf4c158-6b31-be1a-8645-59fc0ca7306a@toxicpanda.com>
On 29/9/20 2:14 am, Josef Bacik wrote:
> On 9/21/20 11:13 PM, Anand Jain wrote:
>> Many things can happen after the device is scanned and before the device
>> is mounted.
>>
>> One such thing is losing the BTRFS_MAGIC on the device.
>>
>> If it happens we still won't free that device from the memory and causes
>> the userland to confuse.
>>
>> For example: As the BTRFS_IOC_DEV_INFO still carries the device path
>> which
>> does not have the BTRFS_MAGIC, the btrfs fi show still shows device
>> which does not belong. As shown below.
>>
>> mkfs.btrfs -fq -draid1 -mraid1 /dev/sda /dev/sdb
>>
>> wipefs -a /dev/sdb
>> mount -o degraded /dev/sda /btrfs
>> btrfs fi show -m
>>
>> /dev/sdb does not contain BTRFS_MAGIC and we still show it as part of
>> btrfs.
>> Label: none uuid: 470ec6fb-646b-4464-b3cb-df1b26c527bd
>> Total devices 2 FS bytes used 128.00KiB
>> devid 1 size 3.00GiB used 571.19MiB path /dev/sda
>> devid 2 size 3.00GiB used 571.19MiB path /dev/sdb
>>
>
> Wouldn't this also happen if the bytenrs didn't match? In that case you
> aren't freeing anything, and we'd still show the improper device
> correct? So why not deal with that case in a similar way? Thanks,
Freeing the device without the BTRFS_MAGIC is mandatory because the
device does not belong to btrfs even though we could notice from the
sysfs that there is missing flag on this devid.
I think I should check for the BTRFS_MAGIC first before bytenr check,
I shall swap them in v2 if there are no other comments. We need this
patch as a fix for the test case btrfs/198.
However bytenrs mismatch indicates corruption. If the degraded mount
option is not provided we would fail the mount. The user shall have the
opportunity to fix the corrupted superblock. We don't automatically
recover the corrupted superblock from the backup superblock copies. If
the degraded mount option is provided the corrupted device still be in
the device_list but with the missing flag set. Just by looking at btrfs
fi show the user won't know that one of the devices is not part of the
volume however when he looks into the /sys/fs/btrfs/fsid/devinfo/<devid>
/missing it shall show 1. Our serviceability part of the degraded volume
has some unfinished business when we evaluate it against the standard
RAS features, but we are slowly getting there.
Thanks, Anand
>
> Josef
next prev parent reply other threads:[~2020-09-30 7:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-19 2:52 [PATCH] btrfs: free device without BTRFS_MAGIC Anand Jain
2020-09-21 9:44 ` Johannes Thumshirn
2020-09-21 10:52 ` Johannes Thumshirn
2020-09-21 11:19 ` Anand Jain
2020-09-22 3:13 ` [PATCH v2] " Anand Jain
2020-09-23 11:09 ` Nikolay Borisov
2020-09-24 11:55 ` Anand Jain
2020-09-28 18:14 ` Josef Bacik
2020-09-30 7:21 ` Anand Jain [this message]
2020-09-30 12:41 ` Josef Bacik
2020-09-30 13:09 ` [PATCH v3] " Anand Jain
2020-10-01 1:05 ` Anand Jain
2020-10-01 10:49 ` 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=2d4b10fd-a5f4-7e6b-85f4-f92591e2a539@oracle.com \
--to=anand.jain@oracle.com \
--cc=Johannes.Thumshirn@wdc.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
/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).