Starting bcachefs-tools 1.9.0 bcachefs mounts fail. I suspect that only systems with bcache *and* bcachefs are affected, hence this is not very widespread. Please keep bcachefs-tools 1.7.0 in ::gentoo until this is fixed. As requested by csfore, this is the downstream bug report to track the issue. Upstream report is at https://github.com/koverstreet/bcachefs-tools/issues/308
What's the use case for bcache _and_ bcachefs on the same system? Wouldn't you be better off using the 'bcache' drives as 'foreground' and 'metadata' drives is bcachefs?
(In reply to Matt Jolly from comment #1) > What's the use case for bcache _and_ bcachefs on the same system? Wouldn't > you be better off using the 'bcache' drives as 'foreground' and 'metadata' > drives is bcachefs? It's an old system which had two bcache drives (one with data redundancy and one without) of which I migrated one to bcachefs (the scratch one, without redundancy). The other one is non trivial to migrate, due to the setup. However, I am not sure how relevant for the bug this question is. It is not even confirmed that the dual bcache/bcachefs setup is causing this. And even if this is found to be the root cause, different kernel subsystems should be able to work side-by-side without causing issues.
The root cause seems to be that starting with bcachefs-tools 1.9, mount.bcachefs is using the udev db for block devices. With multi-device bcachefs volumes, systemd may issue the mount.bcachefs as soon as the first block device with the provided UUID appears in the udev db. At this point, the other devices are potentially still missing in the udev db, causing the mount to fail. FTR, setting the `BCACHEFS_BLOCK_SCAN` environment variable for the bcachefs mount unit works around the issue. For example via for a mount unit named data-scratch. echo "BACACHEFS_BLOCK_SCAN=1 > /etc/systemd/system/data\\x2dscratch.mount.d/override.conf
