Comment 23 for bug 1861941

I guess I don't understand why we see this in focal. The two events in Colin's trace always happen on any Ubuntu kernel. We should see if we can get another udev trace on bionic that captures both CHANGE events, one will be from the bcache driver itself, and one is from the block layer. THe order and content of the change event matter.

Another thing I don't understand is why does udev drop the a symlink created by another rule? This seems like the core issue.

Looking at systemd/udev source code; udev will do a FOREACH_DEVICE_DEVLINK and check if the name is in the database file for the device. Its not clear to me yet how or when the database file get's written.

The other question I have is: if we reversed the order of the focal CHANGE events, wouldn't we see just the opposite happen (the driver=bcache change event would not have all of the devlinks from a blkid probe) and all of the /dev/disk/by-{id, uuid, ...} get removed when running

I think the patch you're proposing should work; but I don't think we've root caused why the link gets removed in the first place. Once we understand the root cause, I think we can better understand what a fix should look like.

Lastly, I think we might also test this out on mainline kernel; I wonder if our SAUCE patch for emitting the CACHED_UUID needs an update (or could be dropped).