Re: [PATCH v4 2/4] btrfs: cleanup btrfs_mount() using btrfs_mount_root()

["Misono, Tomohiro" <misono.tomohiro@jp.fujitsu.com>]

On 2018/01/16 20:45, Anand Jain wrote:
> 
> 
> On 01/16/2018 03:26 AM, David Sterba wrote:
>> On Fri, Jan 12, 2018 at 06:14:40PM +0800, Anand Jain wrote:
>>>
>>> Misono,
>>>
>>>    This change is causing subsequent (subvol) mount to fail when device
>>>    option is specified. The simplest eg for failure is ..
>>>      mkfs.btrfs -qf /dev/sdc /dev/sdb
>>>      mount -o device=/dev/sdb /dev/sdc /btrfs
>>>      mount -o device=/dev/sdb /dev/sdc /btrfs1
>>>         mount: /dev/sdc is already mounted or /btrfs1 busy
>>>
>>>     Looks like
>>>       blkdev_get_by_path() <-- is failing.
>>>       btrfs_scan_one_device()
>>>       btrfs_parse_early_options()
>>>       btrfs_mount()
>>>
>>>    Which is due to different holders (viz. btrfs_root_fs_type and
>>>    btrfs_fs_type) one is used for vfs_mount and other for scan,
>>>    so they form different holders and can't let EXCL open which
>>>    is needed for both scan and open.

BTW, I noticed "btrfs device scan/ready" fails for mounted filesystem
because of this reason. I will send a patch to fix this.
(Though I believe this is not the cause of the problem you mentioned.)

Thanks,
Tomohiro

>>
>> This looks close to what I see in the random test failures. I've
>> reverted your patch "btrfs: optimize move uuid_mutex closer to the
>> critical section" as I bisected to it. The uuid mutex around
>> blkdev_get_path probably protected the concurrent mount and scan so they
>> did not ask for EXCL at the same time.
>>
>> Reverting (or removing the patch from the current misc-next) queue is
>> simpler for me ATM as I want to get to a stable base now, we can add it
>> later if we understand the issue with the mount/scan.
> 
>   Right. I don't see above test case failing on your branch [1] which
>   does not have the uuid_mutex patch. Quite strange, there isn't any
>   concurrency (mount and scan) in this test case.
>   [1]
>     git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-next
> 
>   Ran xfstests, got stuck at btrfs/011 failures, (and will wait for
>   Liubo's v2 patch). OR is there any other test case you were referring
>   to as random test failures ?
> 
> Thanks, Anand
> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>