Red Hat Bugzilla – Bug 1253833
renaming logical volumes to previously existing volume names causes confusion when lvresize calls fsadm
Last modified: 2017-08-01 17:47:18 EDT
+++ This bug was initially created as a clone of Bug #1196910 +++ Description of problem: renaming logical volumes to previously existing volume names causes confusion when lvresize calls fsadm Version-Release number of selected component (if applicable): lvm2-2.02.111-2.el6_6.1.x86_64 device-mapper-1.02.90-2.el6_6.1.x86_64 device-mapper-libs-1.02.90-2.el6_6.1.x86_64 How reproducible: every time Steps to Reproduce: 1. mount a volume (volume1) 2. take the volume (volume1) and rename it (volume3) 3. rename another volume (volume2) to the original volume name (volume1) 4. attempt to resize the second volume that has the old name (volume1) Actual results: the lvresize command requests that you unmount the mountpoint that is hosting the original volume (volume3) Expected results: lvm should be able to determine that this is NOT the same volume and not ask to unmount it Additional info: I hit this in a customer's environment, but was able to reproduce on the newest bits in RHEL 6.6 ------------------------------ [root@jack-rhel6 ~]# mount /dev/vgtest/volume1 /mnt [root@jack-rhel6 ~]# cd /mnt [root@jack-rhel6 mnt]# lvrename vgtest/volume1 volume3 Renamed "volume1" to "volume3" in volume group "vgtest" [root@jack-rhel6 mnt]# lvrename vgtest/volume2 volume1 Renamed "volume2" to "volume1" in volume group "vgtest" [root@jack-rhel6 mnt]# lvresize -rL512M /dev/vgtest/volume1 Do you want to unmount "/mnt"? [Y|n] n fsadm: Cannot proceed with mounted filesystem "/mnt" fsadm failed: 1 Filesystem resize failed. [root@jack-rhel6 mnt]# [root@jack-rhel6 mnt]# lvresize -rL512M /dev/vgtest/volume1 Do you want to unmount "/mnt"? [Y|n] y umount: /mnt: device is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1)) fsadm: Cannot proceed with mounted filesystem "/mnt" fsadm failed: 1 Filesystem resize failed. [root@jack-rhel6 mnt]# ------------------------------ lvm output shows that volume1 is NOT in open (and not mounted) ------------------------------ [root@jack-rhel6 mnt]# lvs -o +devices LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert Devices lv_root vg_jackrhel6 -wi-ao---- 8.51g /dev/vda2(0) lv_swap vg_jackrhel6 -wi-ao---- 1.00g /dev/vda2(2178) volume1 vgtest -wi-a----- 1.00g /dev/vdb(256) volume3 vgtest -wi-ao---- 1.00g /dev/vdb(0) [root@jack-rhel6 mnt]# lvresize -rL512M /dev/vgtest/volume1 Do you want to unmount "/mnt"? [Y|n] n fsadm: Cannot proceed with mounted filesystem "/mnt" fsadm failed: 1 Filesystem resize failed. [root@jack-rhel6 mnt]# [root@jack-rhel6 mnt]# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_jackrhel6-lv_root 8.3G 3.3G 4.6G 42% / tmpfs 499M 72K 499M 1% /dev/shm /dev/vda1 477M 75M 377M 17% /boot /dev/mapper/vgtest-volume1 1008M 34M 924M 4% /mnt ------------------------------ Using the resize2fs command instead of passing the -r flag to lvresize works as expected: ------------------------------ [root@jack-rhel6 mnt]# lvresize -rL512M /dev/vgtest/volume1 Do you want to unmount "/mnt"? [Y|n] n fsadm: Cannot proceed with mounted filesystem "/mnt" fsadm failed: 1 Filesystem resize failed. [root@jack-rhel6 mnt]# resize2fs /dev/mapper/vgtest-volume1 512M resize2fs 1.41.12 (17-May-2010) Resizing the filesystem on /dev/mapper/vgtest-volume1 to 131072 (4k) blocks. The filesystem on /dev/mapper/vgtest-volume1 is now 131072 blocks long. [root@jack-rhel6 mnt]# lvresize -rL512M /dev/vgtest/volume1 resize2fs 1.41.12 (17-May-2010) The filesystem is already 131072 blocks long. Nothing to do! Size of logical volume vgtest/volume1 changed from 1.00 GiB (256 extents) to 512.00 MiB (128 extents). Logical volume volume1 successfully resized [root@jack-rhel6 mnt]# lvresize -rL300M /dev/vgtest/volume1 Do you want to unmount "/mnt"? [Y|n] n fsadm: Cannot proceed with mounted filesystem "/mnt" fsadm failed: 1 Filesystem resize failed. [root@jack-rhel6 mnt]#
Exists in 7.2 as well. 3.10.0-302.el7.x86_64 lvm2-2.02.127-1.el7 BUILT: Mon Aug 10 03:22:35 CDT 2015 lvm2-libs-2.02.127-1.el7 BUILT: Mon Aug 10 03:22:35 CDT 2015 lvm2-cluster-2.02.127-1.el7 BUILT: Mon Aug 10 03:22:35 CDT 2015 device-mapper-1.02.104-1.el7 BUILT: Mon Aug 10 03:22:35 CDT 2015 device-mapper-libs-1.02.104-1.el7 BUILT: Mon Aug 10 03:22:35 CDT 2015 device-mapper-event-1.02.104-1.el7 BUILT: Mon Aug 10 03:22:35 CDT 2015 device-mapper-event-libs-1.02.104-1.el7 BUILT: Mon Aug 10 03:22:35 CDT 2015 device-mapper-persistent-data-0.5.4-1.el7 BUILT: Fri Jul 17 08:56:22 CDT 2015 cmirror-2.02.127-1.el7 BUILT: Mon Aug 10 03:22:35 CDT 2015 sanlock-3.2.4-1.el7 BUILT: Fri Jun 19 12:48:49 CDT 2015 sanlock-lib-3.2.4-1.el7 BUILT: Fri Jun 19 12:48:49 CDT 2015 lvm2-lockd-2.02.127-1.el7 BUILT: Mon Aug 10 03:22:35 CDT 2015 [root@host-115 ~]# lvs -a -o +devices LV Attr LSize Cpy%Sync Devices resizeA mwi-aom--- 200.00m 100.00 resizeA_mimage_0(0),resizeA_mimage_1(0) [resizeA_mimage_0] iwi-aom--- 200.00m /dev/sdd2(0) [resizeA_mimage_1] iwi-aom--- 200.00m /dev/sdd1(0) resizeB mwi-aom--- 200.00m 100.00 resizeB_mimage_0(0),resizeB_mimage_1(0) [resizeB_mimage_0] iwi-aom--- 200.00m /dev/sdd2(50) [resizeB_mimage_1] iwi-aom--- 200.00m /dev/sdd1(50) [root@host-115 ~]# mount /dev/mapper/mirror_sanity-resizeA on /mnt/resizeA type ext4 (rw,relatime,seclabel,data=ordered) /dev/mapper/mirror_sanity-resizeB on /mnt/resizeB type ext4 (rw,relatime,seclabel,data=ordered) [root@host-115 ~]# lvrename /dev/mirror_sanity/resizeA /dev/mirror_sanity/resizeC Renamed "resizeA" to "resizeC" in volume group "mirror_sanity" [root@host-115 ~]# lvrename /dev/mirror_sanity/resizeB /dev/mirror_sanity/resizeA Renamed "resizeB" to "resizeA" in volume group "mirror_sanity" [root@host-115 ~]# lvs -a -o +devices LV Attr LSize Cpy%Sync Devices resizeA mwi-aom--- 200.00m 100.00 resizeA_mimage_0(0),resizeA_mimage_1(0) [resizeA_mimage_0] iwi-aom--- 200.00m /dev/sdd2(50) [resizeA_mimage_1] iwi-aom--- 200.00m /dev/sdd1(50) resizeC mwi-aom--- 200.00m 100.00 resizeC_mimage_0(0),resizeC_mimage_1(0) [resizeC_mimage_0] iwi-aom--- 200.00m /dev/sdd2(0) [resizeC_mimage_1] iwi-aom--- 200.00m /dev/sdd1(0) [root@host-115 ~]# lvextend -r -n -f -L 400M /dev/mirror_sanity/resizeA Extending 2 mirror images. Size of logical volume mirror_sanity/resizeA changed from 200.00 MiB (50 extents) to 400.00 MiB (100 extents). Logical volume resizeA successfully resized resize2fs 1.42.9 (28-Dec-2013) resize2fs: Device or resource busy while trying to open /dev/mapper/mirror_sanity-resizeA Couldn't find valid filesystem superblock. fsadm: Resize ext4 failed fsadm failed: 1 [root@host-115 ~]# lvs -a -o +devices LV Attr LSize Cpy%Sync Devices resizeA mwi-aom--- 400.00m 100.00 resizeA_mimage_0(0),resizeA_mimage_1(0) [resizeA_mimage_0] iwi-aom--- 400.00m /dev/sdd2(50) [resizeA_mimage_1] iwi-aom--- 400.00m /dev/sdd1(50) resizeC mwi-aom--- 200.00m 100.00 resizeC_mimage_0(0),resizeC_mimage_1(0) [resizeC_mimage_0] iwi-aom--- 200.00m /dev/sdd2(0) [resizeC_mimage_1] iwi-aom--- 200.00m /dev/sdd1(0)
Yep - this will need some more tricky behaviour from fsadm size, since renamed LVs are unfortunately remembered under the old name in kernel.
So this bug is getting a bit more complicated. There are couple connected troubles. fsadm needs to provide better detection of mounted volume - as it appears most tools do a very basic detect from /etc/mtab content which keeps the old name. New systems may use /proc/self/mountinfo - but it's not giving all the needed info either (i.e. cgroups) but the advantage here is the we get major:minor. We can get a similar info in somewhat complicated way also via 'stat'. So the fix will try to address couple issues accross mutliple different tools. I'm aiming ATM to prevent and filesystem damage by disallowing overrides for cases were fsadm failed to recognize mounted filesystem. But few more related bugs will need to be opened against tools: resize2fs, reiser_resizefs, xfs_growfs - which needs to provide smarter logic to handle renamed device better.
So the approach for 7.4 is to update fsdam with additional checks to detect situations that the current code handles incorrectly and provide clear error messages. Beyond that, wider changes will be covered by separate bugzillas.
Fixed by several upstream fsadm commits: https://www.redhat.com/archives/lvm-devel/2017-May/msg00061.html this one was the most important - ensuring lvm2 will not use renamed mounted LV for filesystem utils.
Is this the fix for this scenario? This behavior is now in the latest rpms and causing this case to "fail". lvreduce -y -r -n -f -L 500M /dev/snapper_thinp/other1 fsadm: Cannot RESIZE device "/dev/mapper/snapper_thinp-other1" without umounting filesystem /mnt/other2 first. fsadm: Mounted filesystem is using device snapper_thinp-other1, but referenced device is snapper_thinp-other2. fsadm: Filesystem utilities currently do not support renamed devices. /usr/sbin/fsadm failed: 1 Filesystem resize failed. couldn't resize thin and filesystem on host-126 3.10.0-666.el7.x86_64 lvm2-2.02.171-2.el7 BUILT: Wed May 24 09:02:34 CDT 2017 lvm2-libs-2.02.171-2.el7 BUILT: Wed May 24 09:02:34 CDT 2017 lvm2-cluster-2.02.171-2.el7 BUILT: Wed May 24 09:02:34 CDT 2017 device-mapper-1.02.140-2.el7 BUILT: Wed May 24 09:02:34 CDT 2017 device-mapper-libs-1.02.140-2.el7 BUILT: Wed May 24 09:02:34 CDT 2017 device-mapper-event-1.02.140-2.el7 BUILT: Wed May 24 09:02:34 CDT 2017 device-mapper-event-libs-1.02.140-2.el7 BUILT: Wed May 24 09:02:34 CDT 2017 device-mapper-persistent-data-0.7.0-0.1.rc6.el7 BUILT: Mon Mar 27 10:15:46 CDT 2017
Yes - that's currently intended behavior - since filesystem utils needs quite some fixes to be able to handle this case. I'll attach created individual BZ here for tracking. Once utils are fixed - lvm2 will need to detect proper/fixed version of tools being present in system and let them proceed with operation in this case.
Marking verified in the latest rpms. Based on comment #11, checked that these reduce/extend operations are no longer allowed until the devices have been remounted. 3.10.0-672.el7.x86_64 lvm2-2.02.171-3.el7 BUILT: Wed May 31 08:36:29 CDT 2017 lvm2-libs-2.02.171-3.el7 BUILT: Wed May 31 08:36:29 CDT 2017 lvm2-cluster-2.02.171-3.el7 BUILT: Wed May 31 08:36:29 CDT 2017 device-mapper-1.02.140-3.el7 BUILT: Wed May 31 08:36:29 CDT 2017 device-mapper-libs-1.02.140-3.el7 BUILT: Wed May 31 08:36:29 CDT 2017 device-mapper-event-1.02.140-3.el7 BUILT: Wed May 31 08:36:29 CDT 2017 device-mapper-event-libs-1.02.140-3.el7 BUILT: Wed May 31 08:36:29 CDT 2017 device-mapper-persistent-data-0.7.0-0.1.rc6.el7 BUILT: Mon Mar 27 10:15:46 CDT 2017 # extend lvextend -r -n -f -L 1.5G /dev/snapper_thinp/other1 WARNING: Sum of all thin volume sizes (6.50 GiB) exceeds the size of thin pool snapper_thinp/POOL (1.00 GiB)! fsadm: Cannot RESIZE device "/dev/mapper/snapper_thinp-other1" without umounting filesystem /mnt/other2 first. fsadm: Mounted filesystem is using device snapper_thinp-other1, but referenced device is snapper_thinp-other2. fsadm: Filesystem utilities currently do not support renamed devices. /usr/sbin/fsadm failed: 1 # reduce lvreduce -y -r -n -f -L 500M /dev/snapper_thinp/other1 fsadm: Cannot RESIZE device "/dev/mapper/snapper_thinp-other1" without umounting filesystem /mnt/other2 first. fsadm: Mounted filesystem is using device snapper_thinp-other1, but referenced device is snapper_thinp-other2. fsadm: Filesystem utilities currently do not support renamed devices. /usr/sbin/fsadm failed: 1 Filesystem resize failed.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2222