I updated my kernel to 6.6.67 on my desktop (openrc) then rebooted, now the lsblk output doesn't show all my mountpoints (btrfs subvolume) All mountpoints are correctly mounted by the way. Confirmed with "df -h". With kernel 6.6.62: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 9,1T 0 disk └─sda1 8:1 0 9,1T 0 part └─hdd3 254:7 0 9,1T 0 crypt /mnt/hdd3 /mnt/dump sdb 8:16 0 9,1T 0 disk └─sdb1 8:17 0 9,1T 0 part └─hdd2 254:6 0 9,1T 0 crypt /mnt/hdd2 /var/cache/distfiles /var/cache/binpkgs cat /proc/mounts /dev/mapper/hdd2 /mnt/hdd2 btrfs rw,relatime,space_cache=v2,subvolid=258,subvol=/hdd2 0 0 /dev/mapper/hdd3 /mnt/hdd3 btrfs rw,relatime,space_cache=v2,subvolid=256,subvol=/hdd3 0 0 With kernel 6.6.67: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 9,1T 0 disk └─sda1 8:1 0 9,1T 0 part └─hdd3 254:7 0 9,1T 0 crypt /mnt/hdd3 sdb 8:16 0 9,1T 0 disk └─sdb1 8:17 0 9,1T 0 part └─hdd2 254:6 0 9,1T 0 crypt /mnt/hdd2 cat /proc/mounts /dev/dm-6 /mnt/hdd2 btrfs rw,relatime,space_cache=v2,subvolid=258,subvol=/hdd2 0 0 /dev/dm-7 /mnt/hdd3 btrfs rw,relatime,space_cache=v2,subvolid=256,subvol=/hdd3 0 0 So as you can, see /dev/mapper/*name* is not used but resolved the final destination "/dev/dm-*". And only one mountpoint is displayed which causes a lot of pain. I'm not sure if that's what cause lsblk (util-linux) to fail to correctly display mountpoints. See linux commit (backported in 6.6.66 kernel): a5d74fa247529f8d2169e68a47c32497f565263a for *maybe* possible cause and https://bugzilla.suse.com/show_bug.cgi?id=1230641 Rebooting to 6.6.62 fixes the issue and output of both /proc/mounts & lsblk (mountpoints) back to normal. Reproducible: Always
Forgot to paste fstab (no change between kernel of course) There are other hdd (& mountpoints) but I only copy the first ones for easier reading. UUID=8ae40d83-6010-41a9-a29c-f3c3039da7fa /mnt/hdd2 btrfs defaults,subvol=hdd2 0 0 UUID=8ae40d83-6010-41a9-a29c-f3c3039da7fa /var/cache/binpkgs btrfs defaults,subvol=binpkgs 0 0 UUID=8ae40d83-6010-41a9-a29c-f3c3039da7fa /var/cache/distfiles btrfs defaults,subvol=distfiles 0 0 UUID=7aeace2c-4e59-418f-bbea-278fa726811a /mnt/hdd3 btrfs defaults,subvol=hdd3 0 0 UUID=7aeace2c-4e59-418f-bbea-278fa726811a /mnt/dump btrfs defaults,subvol=dump 0 0
Small update: I'm having the exact same issue with my laptop which I updated to 6.6.67 too. Two subvolumes on hdd2 mapper: hdd2 & dump /etc/fstab UUID=6b5818e3-5693-43b3-a9f8-6b4b48e3096e /mnt/hdd2 btrfs defaults,subvol=hdd2 0 0 UUID=6b5818e3-5693-43b3-a9f8-6b4b48e3096e /mnt/dump btrfs defaults,subvol=dump 0 0 With kernel 6.6.67, only "dump" is shown by lsblk sdb 8:16 0 298,1G 0 disk └─sdb1 8:17 0 298,1G 0 part └─hdd2 254:1 0 298,1G 0 crypt /mnt/dump If I umount dump: umount /mnt/dump ; then sdb 8:16 0 298,1G 0 disk └─sdb1 8:17 0 298,1G 0 part └─hdd2 254:1 0 298,1G 0 crypt /mnt/hdd2 So as you can see, the subvolumes are mounted but lsblk cannot print more than one. /proc/mounts /dev/dm-1 /mnt/hdd2 btrfs rw,relatime,space_cache=v2,subvolid=382,subvol=/hdd2 0 0 /dev/dm-1 /mnt/dump btrfs rw,relatime,space_cache=v2,subvolid=393,subvol=/dump 0 0 ---- With kernel 6.6.62, no problem. sdb 8:16 0 298,1G 0 disk └─sdb1 8:17 0 298,1G 0 part └─hdd2 254:1 0 298,1G 0 crypt /mnt/hdd2 /mnt/dump /proc/mounts /dev/mapper/hdd2 /mnt/hdd2 btrfs rw,relatime,space_cache=v2,subvolid=382,subvol=/hdd2 0 0 /dev/mapper/hdd2 /mnt/dump btrfs rw,relatime,space_cache=v2,subvolid=393,subvol=/dump 0 0 ---- I tried with gentoo-sources-6.6.68, same problem. Then I tried again with gentoo-sources-6.6.68 with this commit reverted: btrfs: avoid unnecessary device path update for the same device a5d74fa247529f8d2169e68a47c32497f565263a and now lsblk outputs is fine and /proc/mounts correctly shows /dev/mapper/*name*, same as with 6.6.62 ! I only tried with my laptop because I can't reboot (or mess) with my desktop for now.
Created attachment 915421 [details, diff] btrfs: avoid unnecessary device path update for the same device (revert)
This is a little weird, as in the latest upstream kernel (6.13-rc4) the patch is not causing any problems (already in the mainline kernel). E.g: ``` vdb 254:16 0 80G 0 disk |-test-test 253:1 0 10G 0 lvm |-test-scratch1 253:3 0 10G 0 lvm /mnt/data | /mnt/btrfs ``` And the /proc/mounts shows the correct result: ``` /dev/mapper/test-scratch1 /mnt/btrfs btrfs rw,relatime,discard=async,space_cache=v2,subvolid=256,subvol=/subv1 0 0 /dev/mapper/test-scratch1 /mnt/data btrfs rw,relatime,discard=async,space_cache=v2,subvolid=257,subvol=/subv2 0 0 ``` My guess is, my patch is relying on the newer fsconfig mount API, which is only introduced in 6.8, and since it's a pretty big change, it doesn't get backported to v6.6. BTW, since the device path resolution only happens if the source is not a path inside "/dev", have you tried to mount the fs using the device path instead of UUID? (Tried it on the latest kernel, still no problem though) And mind to test the latest kernel also?
I talked to the author of this patch: "Although not yet fully confirmed, my current guess is the patch should not be backported to any kernel older than 6.8, where btrfs migrated to the new fsconfig based mount API." "...I believe the patch should be reverted."
Unfortunately I'm not able to reproduce the problem, even with 6.6.68 kernel (from Archlinux though). ``` vdb 254:16 0 80G 0 disk |-test-test 253:0 0 10G 0 lvm |-test-scratch1 253:1 0 10G 0 lvm /mnt/data | /mnt/btrfs ``` And I tried both UUID= and device path mount, all of them results the same result using the mapper name, not the dm-* path in /proc/mounts: /dev/mapper/test-scratch1 /mnt/btrfs btrfs rw,relatime,discard=async,space_cache=v2,subvolid=256,subvol=/subv1 0 0 /dev/mapper/test-scratch1 /mnt/data btrfs rw,relatime,discard=async,space_cache=v2,subvolid=257,subvol=/subv2 0 0 I'm afraid it's not that straightforward to revert the patch now, as we need to dig deeper to find out why it failed on gentoo 6.6.67 kernel.
Thanks for your answer Qu Wenruo. Results with 6.13.0-rc5 (released a few hours ago): lsblk /dev/sdb NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sdb 8:16 0 298,1G 0 disk └─sdb1 8:17 0 298,1G 0 part ################################ cryptsetup luksOpen /dev/sdb1 hdd2 -d keyfile_hdd2 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sdb 8:16 0 298,1G 0 disk └─sdb1 8:17 0 298,1G 0 part └─hdd2 254:1 0 298,1G 0 crypt ################################ ls -alh /dev/mapper... lrwxrwxrwx 1 root root 7 Dec 30 09:08 /dev/mapper/hdd2 -> ../dm-1 ################################ mount -v -o subvol=hdd2 /dev/mapper/hdd2 /mnt/hdd2 mount: /dev/mapper/hdd2 mounted on /mnt/hdd2. mount -v -o subvol=dump /dev/mapper/hdd2 /mnt/dump mount: /dev/mapper/hdd2 mounted on /mnt/dump. # note: Also tried by calling "mount /mnt/hdd2" (reading fstab entries), works fine too. ################################ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/hdd2 299G 209G 86G 72% /mnt/hdd2 /dev/mapper/hdd2 299G 209G 86G 72% /mnt/dump ################################ lsblk /dev/sdb NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sdb 8:16 0 298,1G 0 disk └─sdb1 8:17 0 298,1G 0 part └─hdd2 254:1 0 298,1G 0 crypt /mnt/hdd2 /mnt/dump grep hdd2 /proc/mounts /dev/mapper/hdd2 /mnt/hdd2 btrfs rw,relatime,space_cache=v2,subvolid=382,subvol=/hdd2 0 0 /dev/mapper/hdd2 /mnt/dump btrfs rw,relatime,space_cache=v2,subvolid=393,subvol=/dump 0 0 So as you can see, all good with 6.13-rc5 ! I should have tried that first indeed.. Let me know if you need more info or if I forgot something.
@david, thanks a lot for confirming the newer kernel is fine. So far it really looks like there is no way on newer kernels to use "/dev/dm-*" as mount source at all. Newer fsconfig based mount is doing a lot of helpful magic to avoid the lsblk/blkid bug. On the other hand, I also reproduced the bug in 6.6.x stable kernel, the key point is to make sure the mount/udev is registering the device using "/dev/dm-*" name first. The direct problem of that backported patch is, it prevents future rename, as long as the new name is pointing to the same block device. But the deeper cause is the race between udev/mount where if "/dev/mapper/*" is registered first, everything is fine. If "/dev/dm-*" is registered first, the lsblk bug is hit. Meanwhile the real problem is, lsblk is buggy when the source file is "/dev/dm-*". But at least we should keep the kernel behavior consistent. I have sent out the patch titled `btrfs: prefer to use "/dev/mapper/name" soft link instead of "/dev/dm-*"`, which should allow "/dev/mapper/*" names to replace "/dev/dm-*" ones. Mind to give the 6.6.x kernel a try with that patch backported? I believe it would help a lot by allowing later mount process to refresh the name. (Dmesg would show something like "devid 1 device path /dev/dm-1 changed to /dev/mapper/hdd3 scanned by mount (<pid>)".
(In reply to Qu Wenruo from comment #8) > Mind to give the 6.6.x kernel a try with that patch backported? Yes, it is compiling. I applied it on a clean 6.6.68 tarball. I'll report in two hours (really old cpu! I usually compile the kernel for this laptop on my desktop but it is busy currently)
I confirm the patch: https://lore.kernel.org/linux-btrfs/30aefd8b4e8c1f0c5051630b106a1ff3570d28ed.1735537399.git.wqu@suse.com/T/#u is 100% working with 6.6.68. Thank you Qu Wenruo ! Cheers
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9a11eac7262cc603734522982ab5ea89d3ecd3a0 commit 9a11eac7262cc603734522982ab5ea89d3ecd3a0 Author: Mike Pagano <mpagano@gentoo.org> AuthorDate: 2024-12-30 11:42:12 +0000 Commit: Mike Pagano <mpagano@gentoo.org> CommitDate: 2024-12-30 11:42:12 +0000 sys-kernel/gentoo-sources: btrfs mount device fix Remove uneeded revert: 1900_revert-btrfs-device-path-update.patch Thanks to David Duchesne for reporting and testing and Qu Wenruo for the fix. Closes: https://bugs.gentoo.org/947126 Signed-off-by: Mike Pagano <mpagano@gentoo.org> sys-kernel/gentoo-sources/Manifest | 3 +++ .../gentoo-sources/gentoo-sources-6.6.68-r1.ebuild | 27 ++++++++++++++++++++++ 2 files changed, 30 insertions(+)
Unfortunately the mount source validation is causing other regressions, thus in the future this may be reverted eventually. Instead I tend to report the lsblk bug to upstream linux-utils, so that it can do proper path resolution in user space, and not rely on whatever path inside mount info.
