From: Nikolay Borisov <nborisov@suse.com>
To: Su Yue <Damenly_Su@gmx.com>,
damenly.su@gmail.com, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 02/11] btrfs-progs: misc-tests/034: mount the second device if first device mount failed
Date: Fri, 31 Jan 2020 14:47:14 +0200 [thread overview]
Message-ID: <0145aaff-0e5f-af9d-4bc3-057c983ab52a@suse.com> (raw)
In-Reply-To: <000a9744-a72d-88ff-51f1-2705be98bd75@gmx.com>
On 31.01.20 г. 12:01 ч., Su Yue wrote:
> On 2020/1/31 4:03 PM, Nikolay Borisov wrote:
>>
>>
>> On 12.12.19 г. 13:01 ч., damenly.su@gmail.com wrote:
>>> From: Su Yue <Damenly_Su@gmx.com>
>>>
>>> The 034 test may fail to mount, and dmesg says open_ctree() failed due
>>> to device missing.
>>>
>>> The partly work flow is
>>> step1 loop1 = losetup image1
>>> step2 loop2 = losetup image2
>>> setp3 mount loop1
>>>
>>> The dmesg says the loop2 device is missing.
>>> It's possible and known that while step3 is in open_ctree() and
>>> fs_devices->opened is nonzero, loop2 device has not been added into the
>>
>>
>> Care to give more details how this can happen? I haven't observed such a
>> failure, meaning it's likely due to some race condition. More details
>> are needed though. In your change log you say "it's known" but
>> apparently only to you in this case.
>>
>
> Sure. There's a device missing situation[1] if two
> devices(raid 1/0) were caught by udev. Yes, it's
> not related to the metadata fsid feature. It just
> makes the mount operation due to the missing device then
> the test fails.
Ok but in those mail posts it says the problem occurs if we have a
multi-device btrfs volume, in this case raid1, and one of the devices is
missing. The pertinent question is why would any of the testing devices
be missing? Did you actually experience such failure ? loop1 is acquired
after running losetup --find --show, implying that after the command is
finished the given loopback device is fully present to the system?
>
> In this script, $loop1 *may* be failed to be mounted because
> $loop2 is "missing". Mounting $loop2 device can verify the
> metadata fsid functionality but without the degraded option.
>
>
> [1]: https://www.spinics.net/lists/linux-btrfs/msg96312.html
next prev parent reply other threads:[~2020-01-31 12:47 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-12 11:01 [PATCH 00/11] btrfs-progs: metadata_uuid feature fixes and portation damenly.su
2019-12-12 11:01 ` [PATCH 01/11] btrfs-progs: misc-tests/034: reload btrfs module before running failure_recovery damenly.su
2020-01-31 8:01 ` Nikolay Borisov
2019-12-12 11:01 ` [PATCH 02/11] btrfs-progs: misc-tests/034: mount the second device if first device mount failed damenly.su
2020-01-31 8:03 ` Nikolay Borisov
2020-01-31 10:01 ` Su Yue
2020-01-31 12:47 ` Nikolay Borisov [this message]
2020-02-04 4:40 ` Su Yue
2019-12-12 11:01 ` [PATCH 03/11] btrfs-progs: metadata_uuid: add new member btrfs_fs_devices::fsid_change damenly.su
2019-12-12 11:01 ` [PATCH 04/11] btrfs-progs: handle split-brain scenario for scanned changing device without INCOMPAT_METADATA_UUID damenly.su
2019-12-12 11:01 ` [PATCH 05/11] btrfs-progs: handle split-brain scenario for scanned changing device with INCOMPAT_METADATA_UUID damenly.su
2019-12-12 11:01 ` [PATCH 06/11] btrfs-progs: handle split-brain scenario for scanned changed/unchanged " damenly.su
2019-12-12 11:02 ` [PATCH 07/11] btrfs-progs: handle split-brain scenario for scanned changed/unchanged device without INCOMPAT_METADATA_UUID damenly.su
2019-12-12 11:02 ` [PATCH 08/11] btrfs-progs: metadata_uuid: remove old logic to find fs_devices damenly.su
2019-12-12 11:02 ` [PATCH 09/11] btrfs-progs: metadata_uuid: rewrite fs_devices fsid and metadata_uuid if it's changing damenly.su
2019-12-12 11:02 ` [PATCH 10/11] btrfs-progs: metadata_uuid: clear FSID_CHANGING_V2 while open_ctree() damenly.su
2019-12-12 11:02 ` [PATCH 11/11] btrfs-progs: misc-tests/034: add new test images and modify the script damenly.su
2020-01-31 8:00 ` Nikolay Borisov
2020-01-31 8:05 ` [PATCH 00/11] btrfs-progs: metadata_uuid feature fixes and portation Nikolay Borisov
2020-01-31 10:04 ` Su Yue
2020-03-04 14:14 ` David Sterba
2020-03-05 1:18 ` Su Yue
2020-03-05 14:16 ` 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=0145aaff-0e5f-af9d-4bc3-057c983ab52a@suse.com \
--to=nborisov@suse.com \
--cc=Damenly_Su@gmx.com \
--cc=damenly.su@gmail.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