RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1253833 - renaming logical volumes to previously existing volume names causes confusion when lvresize calls fsadm
Summary: renaming logical volumes to previously existing volume names causes confusion...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2
Version: 7.2
Hardware: All
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Zdenek Kabelac
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On: 1196910
Blocks: 1298243 1385242
TreeView+ depends on / blocked
 
Reported: 2015-08-14 20:17 UTC by Corey Marthaler
Modified: 2021-09-03 12:56 UTC (History)
15 users (show)

Fixed In Version: lvm2-2.02.171-2.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1196910
Environment:
Last Closed: 2017-08-01 21:47:18 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1320729 0 unspecified CLOSED renaming RAID volumes to previously existing volume names causes confusion when lvresize calls fsadm to reduce 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1320735 0 unspecified CLOSED renaming logical volumes to previously existing volume names causes confusion when lvresize calls fsadm to extend 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1458201 0 unspecified CLOSED resize2fs does not work with renamed device 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1458207 0 unspecified CLOSED xfs_growfs does not work with mounted renamed devices 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHBA-2017:2222 0 normal SHIPPED_LIVE lvm2 bug fix and enhancement update 2017-08-01 18:42:41 UTC

Internal Links: 1320729 1320735 1458201 1458207

Description Corey Marthaler 2015-08-14 20:17:23 UTC 
+++ 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]#
Comment 1 Corey Marthaler 2015-08-14 20:21:03 UTC 
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)
Comment 2 Zdenek Kabelac 2015-08-24 08:33:21 UTC 
Yep - this will need some more tricky behaviour from fsadm size, since renamed LVs are unfortunately remembered under the old name in kernel.
Comment 7 Zdenek Kabelac 2017-05-09 11:14:52 UTC 
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.
Comment 8 Alasdair Kergon 2017-05-11 23:04:52 UTC 
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.
Comment 9 Zdenek Kabelac 2017-05-24 15:56:41 UTC 
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.
Comment 10 Corey Marthaler 2017-05-25 20:15:23 UTC 
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
Comment 11 Zdenek Kabelac 2017-05-26 08:40:14 UTC 
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.
Comment 13 Corey Marthaler 2017-06-01 15:29:31 UTC 
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.
Comment 14 errata-xmlrpc 2017-08-01 21:47:18 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.