udev: skip disk/by-uuid for bcache devices #16317

rbalint · 2020-06-30T11:29:11Z

blkid reports bcache superblock dev.uuid as a filesystem UUID but it
actually is not a filesystem, it's the UUID of the backing device, which
is maintained at /dev/bcache/by-uuid instead of /dev/disk/by-uuid.

Fixes: https://launchpad.net/bugs/1861941

blkid reports bcache superblock dev.uuid as a filesystem UUID but it actually is not a filesystem, it's the UUID of the backing device, which is maintained at /dev/bcache/by-uuid instead of /dev/disk/by-uuid. Fixes: https://launchpad.net/bugs/1861941

poettering · 2020-06-30T13:06:25Z

Hmm, isn't this a bug in liblklid then? i.e. it probably should report this UUID as file system UUID if it actually isn't.

@karelzak what's your take on this?

arvidjaar · 2020-07-01T07:05:59Z

How can not creating links in /dev/disk/by-uuid help in creating links in /dev/bcache? This is just yet another link, which does not affect existence of any other link in any way.

The real problem is that current (upstream) bcache rules rely on CACHED_UUID device property:

# Cached devices: symlink
DRIVER=="bcache", ENV{CACHED_UUID}=="?*", \
        SYMLINK+="bcache/by-uuid/$env{CACHED_UUID}"
DRIVER=="bcache", ENV{CACHED_LABEL}=="?*", \
        SYMLINK+="bcache/by-label/$env{CACHED_LABEL}"

and kernel block layer sends change events without this property when something "interesting" happens:

KERNEL[1466.145739] change   /devices/virtual/block/bcache0 (block)
ACTION=change
DEVPATH=/devices/virtual/block/bcache0
SUBSYSTEM=block
SYNTH_UUID=0
DEVNAME=/dev/bcache0
DEVTYPE=disk
SEQNUM=6248
MAJOR=252
MINOR=0

At which point CACHED_UUID gets lost because on change event all existing properties are gone. This is also clearly shown in mentioned Ubuntu bug report. PR https://github.com/g2p/bcache-tools/pull/29/files changes rules to not rely on device property but probe it instead. If this PR is not enough, I'd love to see actual udev debug output for the case when it does not work.

Another possible fix (although it depends on exact sequence of events) is to use import{db}="CACHED_UUID" on change events; it should propagate previous value into newly created device properties.

it probably should [not] report this UUID as file system UUID if it actually isn't.

This is not a problem here. Changing udev property name will break unknown number of programs. blkid returns enough information to clearly identify bcache as bcache if needed (ID_FS_USAGE=other, ID_FS_TYPE=bcache).

raharper · 2020-07-01T14:57:02Z

How can not creating links in /dev/disk/by-uuid help in creating links in /dev/bcache? This is just yet another link, which does not > affect existence of any other link in any way.

Analysis here:

https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1861941/comments/27

But the short of it is: creating a bcache device on top of an empty disk will create a by-uuid symlink pointing to bcache backing device as blkid reports FS_UUID with the bcache dev.uuid value which is not a filesystem uuid. This causes two separate block devices to use the same UUID and when we create a filesystem, the FS_UUID Of the fs will remove the original /dev/bcache/by-uuid symlink when it should not.

% make-bcache -B /dev/vdb
% ls -al /dev/disk/by-uuid/d7d7e025-b8d2-43cb-a5df-c240ba1418dc
lrwxrwxrwx 1 root root 9 May 21 16:39 /dev/disk/by-uuid/d7d7e025-b8d2-43cb-a5df-c240ba1418dc -> ../../vdb
# ls -al /dev/bcache/by-uuid/d7d7e025-b8d2-43cb-a5df-c240ba1418dc
lrwxrwxrwx 1 root root 13 May 21 16:39 /dev/bcache/by-uuid/d7d7e025-b8d2-43cb-a5df-c240ba1418dc -> ../../bcache0
% # 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)
dev.uuid d7d7e025-b8d2-43cb-a5df-c240ba1418dc
dev.sectors_per_block 1
dev.sectors_per_bucket 1024
dev.data.first_sector 16
dev.data.cache_mode 0 [writethrough]
dev.data.cache_state 0 [detached]

cset.uuid 37b37bc1-e185-4825-8900-579df102b7d6

Then when after running mkfs.ext4 on bcache0 blkid will then report the ext4 FS_UUID instead of the dev.uuid update the symlink to the filesystem UUID and point to bcache0; and udev will claim that nothing owns the /dev/bcache/by-uuid symlink any more and remove /dev/bcache/by-uuid/<dev.uuid> link since it had two devices (vdb and bcache0) using the same UUID.

Apr 21 14:15:43 ubuntu-focal systemd-udevd[1916]: bcache0: Updating old name, '/dev/bcache/by-uuid/1522715e-a390-40db-8d47-06fb728014e5' no longer belonging to '/devices/virtual/block/bcache0'
Apr 21 14:15:43 ubuntu-focal systemd-udevd[1916]: bcache0: No reference left, removing '/dev/bcache/by-uuid/1522715e-a390-40db-8d47-06fb728014e5'
Apr 21 14:15:43 ubuntu-focal systemd-udevd[1916]: bcache0: Handling device node '/dev/bcache0', devnum=b251:0

IMO, blkid should not report an FS_UUID for devices with a bcache header using the dev.uuid field of bcache; that's a device id, not related to the content it is caching.

it probably should [not] report this UUID as file system UUID if it actually isn't.

This is not a problem here. Changing udev property name will break unknown number of programs. blkid returns enough information to clearly identify bcache as bcache if needed (ID_FS_USAGE=other, ID_FS_TYPE=bcache).

Indeed it does, but the persistent storage rules will create a /dev/disk/by-uuid symlink for ID_FS_USAGE=other and if ID_FS_UUID_ENC non-empty. The attached patch skips this for bcache backing devices only.

The alternative to changing the rules file is to see if blkid should not emit FS_UUID_ENC for bcache backing devices which do not have a filesystem on them. I suspect to do that, blkid would need to detect the bcache device type (sb.version) and then seek past the bcache header to check for any fs magic present.

raharper · 2020-07-01T15:43:43Z

and kernel block layer sends change events without this property when something "interesting" happens:
...
At which point CACHED_UUID gets lost because on change event all existing properties are gone. This is also clearly shown in > mentioned Ubuntu bug report. PR https://github.com/g2p/bcache-tools/pull/29/files changes rules to not rely on device property > but probe it instead. If this PR is not enough, I'd love to see actual udev debug output for the case when it does not work.

Yes. The changes to the bcache udev rules work around this kernel issue; it's certainly going to be more reliable in the face of different kernel versions. We still need either blkid to not report ID_FS_UUID_ENC on bcache backing devices, or these changes to the rules to skip over attempting to provide by-uuid symlinks for bcache backing devices.

When I tested with just the bcache rule changes, I would still get broken/missing /dev/disk/by-uuid links due to the UUID change on probing of the backing device (with and without a fileystem on the backing device).

arvidjaar · 2020-07-02T06:05:51Z

The changes to the bcache udev rules work around this kernel issue

So the problem of missing /dev/bcache links is solved and this is what Ubuntu bug was about, so we can forget about it.

I would still get broken/missing /dev/disk/by-uuid links due to the UUID change on probing of the backing device

I do not understand what you mean. Here is what I get on openSUSE Timbleweed which has reasonably current versions of software:

tw:/home/bor # bcache-super-show /dev/vdb
...
sb.version		1 [backing device]

dev.label		(empty)
dev.uuid		3266200b-e093-41c0-b124-3721a9c8dec6
...
tw:/home/bor # bcache-super-show /dev/vdc
...
sb.version		3 [cache device]

dev.label		(empty)
dev.uuid		8c6c1912-ac0b-4769-a330-6d5bb94d3dcb
...
tw:/home/bor # blkid
/dev/vda1: UUID="ce0caa57-7140-4374-8534-3443d21f3edc" TYPE="swap" PARTUUID="d2714b67-01"
/dev/vda2: UUID="cc072e56-f671-4388-a4a0-2ffee7c98fdb" UUID_SUB="eaeb4c78-da94-43b3-acc7-c3e963f1108d" BLOCK_SIZE="4096" TYPE="btrfs" PTTYPE="dos" PARTUUID="d2714b67-02"
/dev/vdb: UUID="3266200b-e093-41c0-b124-3721a9c8dec6" TYPE="bcache"
/dev/vdc: UUID="8c6c1912-ac0b-4769-a330-6d5bb94d3dcb" TYPE="bcache"
/dev/bcache0: UUID="041f614b-4d19-424c-9aec-81b9f623dafe" BLOCK_SIZE="4096" TYPE="ext2"
tw:/home/bor # ll /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 13 Jul  2 08:50 041f614b-4d19-424c-9aec-81b9f623dafe -> ../../bcache0
lrwxrwxrwx 1 root root  9 Jul  2 08:50 3266200b-e093-41c0-b124-3721a9c8dec6 -> ../../vdb
lrwxrwxrwx 1 root root  9 Jul  2 08:50 8c6c1912-ac0b-4769-a330-6d5bb94d3dcb -> ../../vdc
lrwxrwxrwx 1 root root 10 Jul  2 08:50 cc072e56-f671-4388-a4a0-2ffee7c98fdb -> ../../vda2
lrwxrwxrwx 1 root root 10 Jul  2 08:50 ce0caa57-7140-4374-8534-3443d21f3edc -> ../../vda1
tw:/home/bor #

So content of /dev/vdb is bcache backing device which is has UUID 3266200b-e093-41c0-b124-3721a9c8dec6 and /dev/vdb is connectly identified by link /dev/disk/by-uuid/3266200b-e093-41c0-b124-3721a9c8dec6. In turn content of /dev/bcache0 device is filesystem with UUID 041f614b-4d19-424c-9aec-81b9f623dafe and /dev/bcache0 is correctly identified by link /dev/disk/by-uuid/041f614b-4d19-424c-9aec-81b9f623dafe.

If the above is wrong from your point of view, please explain why and what problem does it cause. If you see something different, show what you actually see and explain why you think it is upstream systemd/udev issue.

raharper · 2020-07-02T16:40:23Z

If the above is wrong from your point of view, please explain why and what problem does it cause. If you see something different, show what you actually see and explain why you think it is upstream systemd/udev issue.

# ll /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 13 Jul  2 08:50 041f614b-4d19-424c-9aec-81b9f623dafe -> ../../bcache0
lrwxrwxrwx 1 root root  9 Jul  2 08:50 3266200b-e093-41c0-b124-3721a9c8dec6 -> ../../vdb
lrwxrwxrwx 1 root root  9 Jul  2 08:50 8c6c1912-ac0b-4769-a330-6d5bb94d3dcb -> ../../vdc
lrwxrwxrwx 1 root root 10 Jul  2 08:50 cc072e56-f671-4388-a4a0-2ffee7c98fdb -> ../../vda2
lrwxrwxrwx 1 root root 10 Jul  2 08:50 ce0caa57-7140-4374-8534-3443d21f3edc -> ../../vda1

The missing symlink is a persistent pointer to the bcache0 device that can be used directly.
The UUID that currently points to bcache0 in your example is the ext4 fs uuid, which may be wiped or changed;
The UUID that points to the backing device (vdb in your case) is not directly usable; as it has a bcache header and one must access it through the bcache0 device.

The /dev/bcache/by-uuid symlink is precisely the symlink we need which uses the backing device's dev.uuid (3266200b*) to point to the current usable block device (bcache0).

While the probe change to the bcache rules is needed to consistently create the /dev/bcache/by-uuid symlink, the persistent-storage.rules is in conflict with the bcache rules, namely, if 60-persistent-storage.rules creates a content-based symlink (ext4 fs) to bcache0; then the 69-bcache.rules cannot create a different UUID (dev.uuid) symlink to bcache0.

I don't fully understand (yet) why we cannot always have both, but I've not been successful in getting udev to provide both links like so consistently:

/dev/bcache/by-uuid/3266200b-e093-41c0-b124-3721a9c8dec6 -> ../../bcache0
/dev/disk/by-uuid/041f614b-4d19-424c-9aec-81b9f623dafe -> ../../bcache0

In openSUSE 15.1, I noticed that the 69-bcache.rules does not use bcache-probe and does not attempt to create any /dev/bcache/by-uuid symlinks. I added my changes for the 69-bcache.rules from the PR mentioned earlier, and leaving the 60-persistent-storage.rules as they result in correctly creating the /dev/bcache/by-uuid symlink, however the /dev/disk/by-uuid link to bcache0 (content based) is not present, and a simple trigger on bcache0 will then add the disk/by-uuid content link, but remove the /dev/bcache/by-uuid (dev.uuid) symlink.

 ls -al /dev/bcache/by-uuid/
total 0
drwxr-xr-x 2 root root 60 Jul  2 16:06 .
drwxr-xr-x 3 root root 60 Jul  2 16:06 ..
lrwxrwxrwx 1 root root 13 Jul  2 16:06 2de2b766-f388-4f23-af99-0dbc89d9a02e -> ../../bcache0
+ echo 'Everything OK'
Everything OK
+ exit 0
localhost:/home/opensuse # ls -la /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root 120 Jul  2 16:06 .
drwxr-xr-x 7 root root 140 Jul  2 15:16 ..
lrwxrwxrwx 1 root root   9 Jul  2 15:39 2020-04-09-11-38-39-00 -> ../../vdb
lrwxrwxrwx 1 root root   9 Jul  2 16:06 2de2b766-f388-4f23-af99-0dbc89d9a02e -> ../../vdd
lrwxrwxrwx 1 root root  10 Jul  2 15:39 8f4f0118-9972-4e44-a1a6-23b4c7648141 -> ../../vda1
lrwxrwxrwx 1 root root   9 Jul  2 16:06 c1080cba-57b4-4d79-a0ec-df4ddae19a6c -> ../../vdc
localhost:/home/opensuse # udevadm trigger --action=add --subsystem-match=block /sys/class/block/bcache0 
localhost:/home/opensuse # ls -la /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root 140 Jul  2 16:06 .
drwxr-xr-x 7 root root 140 Jul  2 15:16 ..
lrwxrwxrwx 1 root root   9 Jul  2 15:39 2020-04-09-11-38-39-00 -> ../../vdb
lrwxrwxrwx 1 root root   9 Jul  2 16:06 2de2b766-f388-4f23-af99-0dbc89d9a02e -> ../../vdd
lrwxrwxrwx 1 root root  13 Jul  2 16:06 2e884479-3747-4467-b9bb-0631e75ff26f -> ../../bcache0
lrwxrwxrwx 1 root root  10 Jul  2 15:39 8f4f0118-9972-4e44-a1a6-23b4c7648141 -> ../../vda1
lrwxrwxrwx 1 root root   9 Jul  2 16:06 c1080cba-57b4-4d79-a0ec-df4ddae19a6c -> ../../vdc
localhost:/home/opensuse # ls -al /dev/bcache/by-uuid 
ls: cannot access '/dev/bcache/by-uuid': No such file or directory

However everything can come up alright, such as after a reboot, but if one runs the rules against bcache0 then
the /dev/bcache/by-uuid symlink is removed again. This makes the /dev/bcache/by-uuid rule unreliable; which is
exactly what we're trying to fix.

localhost:/home/opensuse # uptime
 16:30:55  up   0:00,  1 user,  load average: 0.14, 0.03, 0.01
localhost:/home/opensuse # ls -al /dev/bcache/by-uuid/
total 0
drwxr-xr-x 2 root root 60 Jul  2 16:30 .
drwxr-xr-x 3 root root 60 Jul  2 16:30 ..
lrwxrwxrwx 1 root root 13 Jul  2 16:30 f4bfb188-ab02-4170-ab59-dd1a1cec2465 -> ../../bcache0
localhost:/home/opensuse # ls -al /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root 140 Jul  2 16:30 .
drwxr-xr-x 7 root root 140 Jul  2 16:30 ..
lrwxrwxrwx 1 root root   9 Jul  2 16:30 2020-04-09-11-38-39-00 -> ../../vdb
lrwxrwxrwx 1 root root  13 Jul  2 16:30 409c2d97-2753-46ac-931e-973b32283d54 -> ../../bcache0
lrwxrwxrwx 1 root root  10 Jul  2 16:30 8f4f0118-9972-4e44-a1a6-23b4c7648141 -> ../../vda1
lrwxrwxrwx 1 root root   9 Jul  2 16:30 bfd3e9df-7bf9-4c95-815f-be103261a2ca -> ../../vdc
lrwxrwxrwx 1 root root   9 Jul  2 16:30 f4bfb188-ab02-4170-ab59-dd1a1cec2465 -> ../../vdd
localhost:/home/opensuse # udevadm trigger --action=add --subsystem-match=block /sys/class/block/bcache0 
localhost:/home/opensuse # ls -al /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root 140 Jul  2 16:30 .
drwxr-xr-x 7 root root 140 Jul  2 16:30 ..
lrwxrwxrwx 1 root root   9 Jul  2 16:30 2020-04-09-11-38-39-00 -> ../../vdb
lrwxrwxrwx 1 root root  13 Jul  2 16:31 409c2d97-2753-46ac-931e-973b32283d54 -> ../../bcache0
lrwxrwxrwx 1 root root  10 Jul  2 16:30 8f4f0118-9972-4e44-a1a6-23b4c7648141 -> ../../vda1
lrwxrwxrwx 1 root root   9 Jul  2 16:30 bfd3e9df-7bf9-4c95-815f-be103261a2ca -> ../../vdc
lrwxrwxrwx 1 root root   9 Jul  2 16:30 f4bfb188-ab02-4170-ab59-dd1a1cec2465 -> ../../vdd
localhost:/home/opensuse # ls -al /dev/bcache/by-uuid/
ls: cannot access '/dev/bcache/by-uuid/': No such file or directory

W.r.t to the provided patch, the /dev/bcache/by-uuid link stability is the primary goal and the patch is what I thought was the best way to achieve that. I'm happy to pursue other paths if there is an alternative that ensures /dev/bcache/by-uuid symlinks remain persistent.

arvidjaar · 2020-07-02T18:02:59Z

The UUID that points to the backing device (vdb in your case) is not directly usable

/dev/disk/by-uuid links identify device by UUID of its content. Whether you find this link directly usable for your purposes is irrelevant.

I've not been successful in getting udev to provide both links like so consistently

bor@tw:~> ll /dev/bcache/by-uuid/ /dev/disk/by-uuid/
/dev/bcache/by-uuid/:
total 0
lrwxrwxrwx 1 root root 13 Jul  2 20:48 3266200b-e093-41c0-b124-3721a9c8dec6 -> ../../bcache0

/dev/disk/by-uuid/:
total 0
lrwxrwxrwx 1 root root 13 Jul  2 20:48 041f614b-4d19-424c-9aec-81b9f623dafe -> ../../bcache0
lrwxrwxrwx 1 root root  9 Jul  2 20:48 3266200b-e093-41c0-b124-3721a9c8dec6 -> ../../vdb
lrwxrwxrwx 1 root root  9 Jul  2 20:48 8c6c1912-ac0b-4769-a330-6d5bb94d3dcb -> ../../vdc
lrwxrwxrwx 1 root root 10 Jul  2 20:48 cc072e56-f671-4388-a4a0-2ffee7c98fdb -> ../../vda2
lrwxrwxrwx 1 root root 10 Jul  2 20:48 ce0caa57-7140-4374-8534-3443d21f3edc -> ../../vda1
bor@tw:~>

bcache-super-show is not in PATH when bcache-export-cached is invoked from within udev rule.

Anyway, there is no way how link on one device may prevent creation of link on another device unless rules for another device gets confused by it. As these rules are not part of systemd, I would say this should be closed here.

raharper · 2020-07-02T19:40:34Z

The UUID that points to the backing device (vdb in your case) is not directly usable

/dev/disk/by-uuid links identify device by UUID of its content. Whether you find this link directly usable for your purposes is irrelevant.

I think there is a really strong argument that /dev/disk/by-uuid is meant for filesystem UUIDs. The the UUID reported for backing/caching devices aren't filesystems; To what end are we creating a FS UUID link to backing/caching devices then?

bcache-super-show is not in PATH when bcache-export-cached is invoked from within udev rule.

Indeed; with the full path the bcache-super-show; the trigger on bcache0 does not remove the link. Thanks!

Anyway, there is no way how link on one device may prevent creation of link on another device unless rules for another device gets confused by it. As these rules are not part of systemd, I would say this should be closed here.

I'd like to get a comment on whether the FS_UUID from blkid is correct for bcache backing/caching devices.

karelzak · 2020-07-07T09:03:14Z

Hmm, isn't this a bug in liblklid then? i.e. it probably should report this UUID as file system UUID if it actually isn't.
@karelzak what's your take on this?

This is what libblkid returns for bcache:

ID_FS_UUID=7a343627-ac87-4bf0-b76f-46067cbc9b8c
ID_FS_UUID_ENC=7a343627-ac87-4bf0-b76f-46067cbc9b8c
ID_FS_TYPE=bcache
ID_FS_USAGE=other

See the "USAGE", the supported values are filesystem, raid, crypto, and other. For bcache it is other.

libblkid does not return information about filesystems only, it returns information about all on-disk formats. We use ID_FS_ prefix for historical reasons (think about it as about a namespace), but the tag USAGE is important here.

UUID identifies the formations (superblocks) on the device -- "bcache" in this case. IMHO it's a bad idea to try to be smart and try to interpret the content of the cache and exchange the UUID according to the cached filesystem. We need stable, non-fragile semantic without any dynamic rules for these basic identifiers. It's probably pretty common that you want to work with the bcache device rather than with the cache content.

In some cases, we return more UUIDs -- for example for BTRFS or ZFS it returns UUID_SUB to identify underlying devices (UUID= is for main FS, UUID_SUB= is for the fragment (device)). Not sure how difficult is to extract UUID of the cached FS from bcache, but maybe we can add UUID_SUB= also for bcache to provide a more complete picture about the cache.

Anyway, the current libblkid output is correct and provides a way how to identify the bcache.

keszybz · 2020-07-07T15:04:19Z

My understanding now is things are OK with udev and the rules provided with udev, but that the rules provides with bcache itself don't work as expected and /dev/bcache/by-uuid/ symlinks are not created. Is this correct?

raharper · 2020-07-08T15:02:03Z

UUID identifies the formations (superblocks) on the device -- "bcache" in this case. IMHO it's a bad idea to try to be smart and try to interpret the content of the cache and exchange the UUID according to the cached filesystem. We need stable, non-fragile semantic without any dynamic rules for these basic identifiers. It's probably pretty common that you want to work with the bcache device rather than with the cache content.

For bcache there are at least two devices (backing, bcache) and optionally the
cache device (cset). blkid reads the real disk superblock and reports out
the dev.uuid of both the backing (sb.version 1) and caching (sb.version 3).

Neither of these devices are accessed directly, and the superblock data
provides no direct relation to how data on a bcache device is accessed: via
the bcacheN block device.

When the backing device is registered in the bcache driver, it allocates the
first bcacheN device; in the presence of multiple bcache devices, we also want
a persistent path to the same data; between reboots one might find bcache0
pointing to a different backing devices.

This is what the /dev/bcache/by-uuid/ rule/symlink is about; associating
the permenant UUID from the backing device to the currently assigned bcacheN
kernel block device.

I don't feel the /dev/disk/by-uuid links to the backing/caching devices are
helpful to bcache users. It doesn't make them incorrect, I agree.

In some cases, we return more UUIDs -- for example for BTRFS or ZFS it returns UUID_SUB to identify underlying devices (UUID= is for main FS, UUID_SUB= is for the fragment (device)).

That would be useful. It is possible for the backing device to be empty; but that's not the common case;

Not sure how difficult is to extract UUID of the cached FS from bcache, but maybe we can add UUID_SUB= also for bcache to provide a more complete picture about the cache.

The bcache header on the backing device is by default at 16 sectors (but controllable via make-bcache parameter);
this data is in the superblock:

# bcache-super-show /dev/vdd
sb.magic		ok
sb.first_sector		8 [match]
sb.csum			A05549C05838F6D5 [match]
sb.version		1 [backing device]

dev.label		(empty)
dev.uuid		3be2a469-db8f-42d6-8bae-56c309af0a52
dev.sectors_per_block	1
dev.sectors_per_bucket	1024
dev.data.first_sector	16
dev.data.cache_mode	0 [writethrough]
dev.data.cache_state	1 [clean]

cset.uuid		fffdd8da-f6fe-46d9-8f6d-aeb3d37c42ba
# echo $((16 * 512))
8192
# losetup -o 8192 /dev/loop0 /dev/vdd
# udevadm test-builtin  blkid /sys/class/block/loop0/
calling: test-builtin
Load module index
Network interface NamePolicy= disabled by default.
Parsed configuration file /usr/lib/systemd/network/99-default.link
Created link configuration context.
probe /dev/loop0 raid offset=0
ID_FS_UUID=161fc157-a567-4fb1-9b7c-2ca12d9cb87d
ID_FS_UUID_ENC=161fc157-a567-4fb1-9b7c-2ca12d9cb87d
ID_FS_VERSION=1.0
ID_FS_TYPE=ext4
ID_FS_USAGE=filesystem
Unload module index
Unloaded link configuration context.

The other really interesting bit of info to extract (which isn't available
in metadata is the parent bcacheN device; If bcache module is present/active
one can see the current binding via sysfs:

# basename $(readlink -f /sys/class/block/vdd/bcache/dev)
bcache0

raharper · 2020-07-08T17:14:21Z

My understanding now is things are OK with udev and the rules provided with udev

Yeah. I had requested some feedback on the blkid export of bcache backing/caching devices UUIDs in /dev/disk/by-uuid which is ongoing.

the rules provides with bcache itself don't work as expected and /dev/bcache/by-uuid/ symlinks are not created. Is this correct?

This is correct; the upstream rules for bcache rely on the CACHED_UUID change event; however that's not always sent from the kernel. There's a PR, https://github.com/g2p/bcache-tools/pull/29/files which fixes (it needs an update to use the full-path to bcache-super-show.)

It would be nice if we could drop the 69-bcache upstream rules altogether and have blkid export enough information to create the same persistent symlinks that 69-bcache rules intended to do.

poettering · 2020-09-04T09:16:43Z

I am not sure I follow here entirely, not knowing bcache, but do I understand correctly that the remaining issues are between libblkid and bcache upstream, and that we thus can close this PR? Or what's the state of this?

karelzak · 2020-10-06T09:51:32Z

@raharper please, if you have something we need to improve in libblkid then report it again https://github.com/karelzak/util-linux/issues. I guess we can add more from struct cache_sb_disk to the blkid export if there is some conclusion what we need.

The current prober code is pretty basic : https://github.com/karelzak/util-linux/blob/master/libblkid/src/superblocks/bcache.c

poettering · 2020-10-15T13:32:12Z

Let's close this. As I understand what remains to be done is between blkid and bcache, and udev/systemd are all good.

If I misunderstood things, let me know/reopen please.

yuwata added the udev label Jun 30, 2020

poettering added the needs-discussion 🤔 label Jun 30, 2020

keszybz added the needs-reporter-feedback ❓ There's an unanswered question, the reporter needs to answer label Jul 8, 2020

poettering closed this Oct 15, 2020

udev: skip disk/by-uuid for bcache devices #16317

udev: skip disk/by-uuid for bcache devices #16317

rbalint commented Jun 30, 2020

poettering commented Jun 30, 2020

arvidjaar commented Jul 1, 2020

raharper commented Jul 1, 2020

raharper commented Jul 1, 2020

arvidjaar commented Jul 2, 2020

raharper commented Jul 2, 2020

arvidjaar commented Jul 2, 2020

raharper commented Jul 2, 2020

karelzak commented Jul 7, 2020 •

edited

keszybz commented Jul 7, 2020

raharper commented Jul 8, 2020

raharper commented Jul 8, 2020

poettering commented Sep 4, 2020

karelzak commented Oct 6, 2020

poettering commented Oct 15, 2020

udev: skip disk/by-uuid for bcache devices #16317

udev: skip disk/by-uuid for bcache devices #16317

Conversation

rbalint commented Jun 30, 2020

poettering commented Jun 30, 2020

arvidjaar commented Jul 1, 2020

raharper commented Jul 1, 2020

raharper commented Jul 1, 2020

arvidjaar commented Jul 2, 2020

raharper commented Jul 2, 2020

arvidjaar commented Jul 2, 2020

raharper commented Jul 2, 2020

karelzak commented Jul 7, 2020 • edited

keszybz commented Jul 7, 2020

raharper commented Jul 8, 2020

raharper commented Jul 8, 2020

poettering commented Sep 4, 2020

karelzak commented Oct 6, 2020

poettering commented Oct 15, 2020

karelzak commented Jul 7, 2020 •

edited