On 01/17/2018 04:30 PM, Misono, Tomohiro wrote:
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.
Oh yes I can reproduce too using [1], very consistently.
> 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.
David,
Sorry I was wrong. Looks like I have booted wrong kernel to test.
So I see the same problem even you have reverted the patch:
'btrfs: optimize move uuid_mutex closer to the critical section'
in [1].
Quite strange, there isn't any
concurrency (mount and scan) in this test case.
Now this strangeness is explained.
[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 ?
Anything on this ? I can take a look.
Thanks, Anand
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
