** Changed in: linux (Ubuntu)
Status: New => Invalid
** Changed in: linux (Ubuntu Jammy)
Status: New => In Progress
** Changed in: linux (Ubuntu Jammy)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Jammy)
Assignee: (unassigned) => Matthew Ruffell (mruffell)
** Summary changed:
- Ubuntu 22.04 kernel 5.15.0.136 changes /proc/mounts for btfs volumes
+ Mounting btrfs LVM volumes changes mountpoint location and breaks lsblk output
** Description changed:
- We mount btrfs volumes, and we are seeing a change in behavior from the
- 5.15.0-126 kernel to 5.15.0.136
+ BugLink: https://bugs.launchpad.net/bugs/2107516
- In the old behavior (existing for as long as we have had the product),
- mounting a btrfs lvm results in:
+ [Impact]
- $: grep /DataStore0 /proc/mounts
- /dev/mapper/VG0-LV0 /DataStore0 btrfs
rw,seclabel,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0
+ Since 5.15.0-136-generic, mounting btrfs LVM volumes changes behaviour in two
+ subtle ways.
- however same mount with the new kernel results in a different output:
+ The first, changes the mountpoint from
- $: grep /DataStore0 /proc/mounts
- /dev/VG0/LV0 /DataStore0 btrfs
rw,seclabel,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0
+ /dev/mapper/VG0-LV0
- (notice the /dev/VG0/LV0 vs. /dev/mapper/VG0-LV0) for the same mount.
- Our application code uses /dev/mapper checking extensively and we would
- like to avoid a rewrite if possible.
+ to
- Online searches bring me to this bug: https://bugs.gentoo.org/947126
- which seems very similar
+ /dev/VG0/LV0
- We have this change as part of the new kernel:
+ breaking any existing applications which rely on the volume being accessible
at
+ /dev/mapper.
- $:git log --oneline --grep "btrfs: avoid unnecessary device path update for
the same device" Ubuntu-5.15.0-126.136..Ubuntu-5.15.0-136.147
- fc83c00ca63b btrfs: avoid unnecessary device path update for the same device
+ The second, breaks lsblk displaying volume mountpoints when the volume is
+ mounted in duplicated places, e.g.:
- https://lore.kernel.org/linux-
-
btrfs/30aefd8b4e8c1f0c5051630b106a1ff3570d28ed.1735537399.git....@suse.com/T/#u
- seems like a fix , I don't see this accepted yet though.
+ 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.
- If we could either revert this change or provide guidance how we should
- be reading this file that would be great. Thank you.
+ [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 <w...@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.
** Description changed:
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
-
+ 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 <w...@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.
+ 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.
+ Physical volume "/dev/vdc" successfully created.
$ sudo vgcreate VG0 /dev/vdc
- Volume group "VG0" successfully created
+ Volume group "VG0" successfully created
$ sudo lvcreate -n LV0 -l 100%FREE VG0
- Logical volume "LV0" created.
+ 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
+ /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.
** Description changed:
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
+ └─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
+ └─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 <w...@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.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2107516
Title:
Mounting btrfs LVM volumes changes mountpoint location and breaks
lsblk output
Status in linux package in Ubuntu:
Invalid
Status in linux source package in Jammy:
In Progress
Bug description:
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 <w...@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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2107516/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
