First of all there is a known issue in handling multiple paths /
instances of the same device image in btrfs. Fixing this caused
regression earlier. And my survey
[survey] BTRFS_IOC_DEVICES_READY return status
almost told me not to fix the bug.
But these are just a reporting issue which would confuse users, should
be fixed.
There is now a new behaviour: after the btrfs mount, I can see shortly the
wrong raw device /dev/sde and a few seconds later there is the correct
/dev/drbd3 :
yep possible. but it does not mean that btrfs kernel is using the new
path its just a reporting (bug).
(pls use -m option)
root@toy02:/etc# umount /data
root@toy02:/etc# mount /data
root@toy02:/etc# btrfs filesystem show
Label: data uuid: 411af13f-6cae-4f03-99dc-5941acb3135b
Total devices 2 FS bytes used 109.56GiB
devid 3 size 1.82TiB used 63.03GiB path /dev/drbd2
devid 4 size 1.82TiB used 63.03GiB path /dev/sde
Btrfs v3.12
root@toy02:/etc# btrfs filesystem show
Label: data uuid: 411af13f-6cae-4f03-99dc-5941acb3135b
Total devices 2 FS bytes used 109.56GiB
devid 3 size 1.82TiB used 63.03GiB path /dev/drbd2
devid 4 size 1.82TiB used 63.03GiB path /dev/drbd3
Btrfs v3.12
root@toy02:/etc# btrfs filesystem show -m
Label: data uuid: 411af13f-6cae-4f03-99dc-5941acb3135b
Total devices 2 FS bytes used 109.56GiB
devid 3 size 1.82TiB used 63.03GiB path /dev/drbd2
devid 4 size 1.82TiB used 63.03GiB path /dev/drbd3
Btrfs v3.12
Still, the kernel sees 3 instead of (really) 2 HGST drives:
root@toy02:/etc# hdparm -I /dev/sdb | grep Number:
Model Number: HGST HUS724020ALA640
Serial Number: PN2134P5G2P2AX
root@toy02:/etc# hdparm -I /dev/sde | grep Number:
Model Number: HGST HUS724020ALA640
Serial Number: PN2134P5G2P2AX
This is important to know but not a btrfs issue. Do you have multiple
host paths reaching this this device with serial # PN2134P5G2P2AX ?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
