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 majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
