[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-btrfs
Subject:    Re: [PATCH 02/11] btrfs-progs: misc-tests/034: mount the second device if first device mount failed
From:       Nikolay Borisov <nborisov () suse ! com>
Date:       2020-01-31 12:47:14
Message-ID: 0145aaff-0e5f-af9d-4bc3-057c983ab52a () suse ! com
[Download RAW message or body]



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
[prev in list] [next in list] [prev in thread] [next in thread]