APPLIED: [SRU][J][PATCH 0/1] Mounting btrfs LVM volumes changes mountpoint location and breaks lsblk output

Mehmet Basaran mehmet.basaran at canonical.com
Mon Jun 2 10:05:12 UTC 2025


Applied to jammy:master-next branch. Thanks.

-------------- next part --------------
Matthew Ruffell <matthew.ruffell at canonical.com> writes:

> BugLink: https://bugs.launchpad.net/bugs/2107516
>
> [Impact]
>
> Since 5.15.0-136-generic, mounting btrfs LVM volumes changes behaviour in two
> subtle ways.
>
> The first, changes the mountpoint from 
>
> /dev/mapper/VG0-LV0 
>
> to
>
> /dev/VG0/LV0
>
> breaking any existing applications which rely on the volume being accessible at
> /dev/mapper.
>
> The second, breaks lsblk displaying volume mountpoints when the volume is
> mounted in duplicated places, e.g.:
>
> 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
>
> becomes
>
> 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
>       
> Only the first mountpoint is now displayed, where previously it would show
> all of them.
>
> [Fix]
>
> The issue has been debugged in gentoo with the original patch author:
>
> https://bugs.gentoo.org/947126
>
> The findings were that the patch:
>
> commit fc83c00ca63bc3a29778957170ccb96fabccf44c
> Author: Qu Wenruo <wqu at suse.com>
> Date: Tue Sep 24 12:52:17 2024 +0930
> Subject: btrfs: avoid unnecessary device path update for the same device
> Link: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy/commit/?id=fc83c00ca63bc3a29778957170ccb96fabccf44c
>
> relies on the recent migration of btrfs to the new fsconfig mount API, available
> in 6.8 onwards. 
>
> The author tried to fix things up further, but only introduced more regressions,
> leading to the conclusion that this patch needs to be reverted for 5.15.
>
> Hence, submitting a SAUCE patch to revert.
>
> [Testcase]
>
> Create a fresh VM, and attach a scratch disk to be used as a btrfs volume.
>
> $ uname -rv
> 5.15.0-127-generic #137-Ubuntu SMP Fri Nov 8 15:21:01 UTC 2024
> $ lsblk
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
> vda 252:0 0 10G 0 disk
> ├─vda1 252:1 0 9.9G 0 part /
> ├─vda14 252:14 0 4M 0 part
> └─vda15 252:15 0 106M 0 part /boot/efi
> vdb 252:16 0 372K 0 disk
> vdc 252:32 0 5G 0 disk
>
> $ sudo pvcreate /dev/vdc
>   Physical volume "/dev/vdc" successfully created.
> $ sudo vgcreate VG0 /dev/vdc
>   Volume group "VG0" successfully created
> $ sudo lvcreate -n LV0 -l 100%FREE VG0
>   Logical volume "LV0" created.
> $ sudo mkfs.btrfs /dev/dm-0
>
> $ sudo mkdir /mnt/a
> $ sudo mkdir /mnt/b
> $ sudo mkdir /mnt/c
> $ sudo mount /dev/dm-0/mnt/a
> $ sudo mount /dev/dm-0/mnt/b
> $ sudo mount /dev/dm-0/mnt/c
> $ lsblk
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
> vda 252:0 0 10G 0 disk
> ├─vda1 252:1 0 9.9G 0 part /
> ├─vda14 252:14 0 4M 0 part
> └─vda15 252:15 0 106M 0 part /boot/efi
> vdb 252:16 0 372K 0 disk
> vdc 252:32 0 5G 0 disk
> └─VG0-LV0 253:0 0 5G 0 lvm /mnt/c
>                            /mnt/b
>                            /mnt/a
> $ grep /mnt /proc/mounts
> /dev/mapper/VG0-LV0 /mnt/a btrfs rw,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0
> /dev/mapper/VG0-LV0 /mnt/b btrfs rw,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0
> /dev/mapper/VG0-LV0 /mnt/c btrfs rw,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0
>
> $ sudo apt install linux-image-5.15.0-136-generic linux-modules-5.15.0-136-generic linux-modules-extra-5.15.0-136-generic linux-headers-5.15.0-136-generic
>
> $ uname -rv
> 5.15.0-136-generic #147-Ubuntu SMP Sat Mar 15 15:53:30 UTC 2025
> $ ls /mnt
> a b c
> $ sudo mount /dev/dm-0/mnt/a
> $ sudo mount /dev/dm-0/mnt/b
> $ sudo mount /dev/dm-0/mnt/c
> $ lsblk
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
> vda 252:0 0 10G 0 disk
> ├─vda1 252:1 0 9.9G 0 part /
> ├─vda14 252:14 0 4M 0 part
> └─vda15 252:15 0 106M 0 part /boot/efi
> vdb 252:16 0 372K 0 disk
> vdc 252:32 0 5G 0 disk
> └─VG0-LV0 253:0 0 5G 0 lvm /mnt/c
> $ grep /mnt /proc/mounts
> /dev/mapper/VG0-LV0 /mnt/a btrfs rw,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0
> /dev/mapper/VG0-LV0 /mnt/b btrfs rw,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0
> /dev/mapper/VG0-LV0 /mnt/c btrfs rw,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0
> $ sudo touch /dev/mapper/VG0-LV0
> $ grep /mnt /proc/mounts
> /dev/VG0/LV0 /mnt/a btrfs rw,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0
> /dev/VG0/LV0 /mnt/b btrfs rw,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0
> /dev/VG0/LV0 /mnt/c btrfs rw,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0
>
> [Where problems could occur]
>
> We are changing how we check if devices are the same, and what happens if they
> are. The original motivation behind the patch was to try avoid updating the
> device paths on rescan from udev, but there is no evidence that this is even
> a problem on 5.15, and the regressions from having the path names completely
> changed and lsblk missing mountpoints outweighs any benefit of perceived
> reductions in path updates on udev rescan.
>
> We will go back to the original behaviour in 5.15.0-134-generic and earlier,
> to keep things stable as they have been over jammy's lifecycle.
>
> If a regression were to occur, it would affect btrfs mountpoints, and output
> from lsblk showing duplicated mountpoints. 
>
> Matthew Ruffell (1):
>   UBUNTU: SAUCE: Revert "btrfs: avoid unnecessary device path update for
>     the same device"
>
>  fs/btrfs/volumes.c | 38 +-------------------------------------
>  1 file changed, 1 insertion(+), 37 deletions(-)
>
> -- 
> 2.45.2
>
>
> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20250602/6f440cc0/attachment-0001.sig>


More information about the kernel-team mailing list