Digging deeper and walking through this in a focal vm, I'm seeing some strange things.
Starting with a clean disk, and just creating the backing device like so:
make-bcache -B /dev/vdb
We see /dev/bcache0 get created with vdb as the backing device. Now, after this, I see:
/dev/bcache/by-uuid/<dev.uuid> -> ../../bcache0
This is unexpected. It should *only* appear once the bcache0 device is actively cached; that is the bcache driver should not emit CACHED_UUID, until the UUID is actually cached, which only happens once we've registered a cache device with the bcache0 device. We need to look at the kernel source to see if the SAUCE patch isn't quite right, or some other part of bcache code has changed.
Next issue, blkid now detects the bcache dev.uuid, and this shows up like so:
# udevadm test-builtin blkid /sys/class/block/vdb
...
vdb: Probe /dev/vdb with raid and offset=0
ID_FS_UUID=d7d7e025-b8d2-43cb-a5df-c240ba1418dc
ID_FS_UUID_ENC=d7d7e025-b8d2-43cb-a5df-c240ba1418dc
ID_FS_TYPE=bcache
ID_FS_USAGE=other
Note, it shows up as an FS_UUID, but it is *NOT* an fs_uuid; there is no filesystem on this device at all at this time; it does have a bcache superblock, note the FS_UUID matches the dev.uuid of the backing device.
Digging deeper and walking through this in a focal vm, I'm seeing some strange things.
Starting with a clean disk, and just creating the backing device like so:
make-bcache -B /dev/vdb
We see /dev/bcache0 get created with vdb as the backing device. Now, after this, I see:
/dev/bcache/ by-uuid/ <dev.uuid> -> ../../bcache0
This is unexpected. It should *only* appear once the bcache0 device is actively cached; that is the bcache driver should not emit CACHED_UUID, until the UUID is actually cached, which only happens once we've registered a cache device with the bcache0 device. We need to look at the kernel source to see if the SAUCE patch isn't quite right, or some other part of bcache code has changed.
Next issue, blkid now detects the bcache dev.uuid, and this shows up like so:
# udevadm test-builtin blkid /sys/class/ block/vdb d7d7e025- b8d2-43cb- a5df-c240ba1418 dc ENC=d7d7e025- b8d2-43cb- a5df-c240ba1418 dc
...
vdb: Probe /dev/vdb with raid and offset=0
ID_FS_UUID=
ID_FS_UUID_
ID_FS_TYPE=bcache
ID_FS_USAGE=other
Note, it shows up as an FS_UUID, but it is *NOT* an fs_uuid; there is no filesystem on this device at all at this time; it does have a bcache superblock, note the FS_UUID matches the dev.uuid of the backing device.
# bcache-super-show /dev/vdb
sb.magic ok
sb.first_sector 8 [match]
sb.csum 29D6774A332A280B [match]
sb.version 1 [backing device]
dev.label (empty) b8d2-43cb- a5df-c240ba1418 dc per_block 1 per_bucket 1024 first_sector 16 cache_state 0 [detached]
dev.uuid d7d7e025-
dev.sectors_
dev.sectors_
dev.data.
dev.data.cache_mode 0 [writethrough]
dev.data.
cset.uuid 37b37bc1- e185-4825- 8900-579df102b7 d6
It's also curious that cset.uuid has a UUID, as there are no csets created; IMO this is also a bug and it should be 0, null, or empty.
Now, here's where the udev fights over the links. The backing device, vdb, triggers this rule in 60-persistent- storage. rules:
# by-label/by-uuid links (filesystem metadata) FS_USAGE} =="filesystem| other|crypto" , ENV{ID_ FS_UUID_ ENC}==" ?*", SYMLINK+ ="disk/ by-uuid/ $env{ID_ FS_UUID_ ENC}"
ENV{ID_
This creates confusion due to the CACHED_UUID also being emitted from the kernel, like so:
root@ubuntu: /run/udev/ links# ls -al /dev/disk/ by-uuid/ d7d7e025- b8d2-43cb- a5df-c240ba1418 dc by-uuid/ d7d7e025- b8d2-43cb- a5df-c240ba1418 dc -> ../../vdb /run/udev/ links# ls -al /dev/bcache/ by-uuid/ d7d7e025- b8d2-43cb- a5df-c240ba1418 dc by-uuid/ d7d7e025- b8d2-43cb- a5df-c240ba1418 dc -> ../../bcache0
lrwxrwxrwx 1 root root 9 May 21 16:39 /dev/disk/
root@ubuntu:
lrwxrwxrwx 1 root root 13 May 21 16:39 /dev/bcache/
There we have two devices both claiming the backing devices dev.uuid value, with two different block names.
So, in summary, there are two problems to fix:
1) blkid on bcache devices should not report FS_UUID values when FS_TYPE=bcache; there is no filesystem on it; this will need to be discussed upstream
2) our kernel (need to check mainline vs. ours) emits CACHED_UUID when the bcache0 is created, but no cache is attached: see this udev event:
KERNEL[2217.605118] change /devices/ virtual/ block/bcache0 (block) /devices/ virtual/ block/bcache0 UUID=d7d7e025- b8d2-43cb- a5df-c240ba1418 dc /dev/bcache0
ACTION=change
DEVPATH=
SUBSYSTEM=block
DRIVER=bcache
CACHED_
CACHED_LABEL=
DEVNAME=
DEVTYPE=disk
SEQNUM=5890
MAJOR=251
MINOR=0