Bug 1969408

Summary: Removing the name of the backing file of a loopback device breaks the PV on it
Product: Red Hat Enterprise Linux 9 Reporter: Marius Vollmer <mvollmer>
Component: lvm2Assignee: David Teigland <teigland>
lvm2 sub component: Default / Unclassified QA Contact: cluster-qe <cluster-qe>
Status: CLOSED CURRENTRELEASE Docs Contact:
Severity: unspecified    
Priority: high CC: agk, cmarthal, heinzm, jbrassow, lmiksik, mcsontos, msnitzer, prajnoha, teigland, zkabelac
Version: 9.0Keywords: Triaged
Target Milestone: betaFlags: pm-rhel: mirror+
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: lvm2-2.03.13-1.el9 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-12-07 21:42:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Marius Vollmer 2021-06-08 11:41:28 UTC
Description of problem:

We use physical volumes on loopback devices in our tests and when we setup sucha  loopback device we immediately remove the name of the backing file from the filesystem. This makes clean up easier.

LVM2 didn't have any problems with this until now.  A physical volume can successfully be created on such a loopback device, but is immediately goes missing.

Version-Release number of selected component (if applicable):
lvm2-2.03.12-3.el9.x86_64

How reproducible:
Always

Steps to Reproduce:
[root@localhost ~]# F=$(mktemp /var/tmp/loop.XXXX)
[root@localhost ~]# dd if=/dev/zero of=$F bs=1M count=50
50+0 records in
50+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.0443863 s, 1.2 GB/s
[root@localhost ~]# losetup --find --show $F
/dev/loop0
[root@localhost ~]# rm $F
rm: remove regular file '/var/tmp/loop.oakm'? y
[root@localhost ~]# pvcreate /dev/loop0
  Devices file loop_file /var/tmp/loop.gVTf PVID ZFxaqJtwxSH0EoZUPX1uHXbhkP6rHHen last seen on /dev/loop0 not found.
  Devices file PVID ZFxaqJtwxSH0EoZUPX1uHXbhkP6rHHen clearing wrong DEVNAME /dev/loop0
  Physical volume "/dev/loop0" successfully created.
[root@localhost ~]# echo $?
0
[root@localhost ~]# pvs
  Devices file loop_file /var/tmp/loop.gVTf PVID ZFxaqJtwxSH0EoZUPX1uHXbhkP6rHHen not found.
  Devices file loop_file /var/tmp/loop.oakm PVID cVaxOnWrfzv120Zw1xx1W0ONXGNmqoQb last seen on /dev/loop0 not found.


Actual results:
/dev/loop0 is not listed as a pv

Expected results:
/dev/loop0 is listed as a pv and can be used for volume groups

Additional info:
This used to work with lvm2-2.03.11-1.fc34.x86_64.

/dev/loop0 itself is fully functional since the backing file still exists. Just its name has been removed from /var/tmp.

Comment 1 David Teigland 2021-06-08 16:40:27 UTC
OK, lvm will check for "(deleted)" in the backing_file string, and avoid using that as the device id in that case.  That won't be enough if you delete the backing file after you begin using the device, though.  Do you always delete the file before using the loop dev?

Until a fix is available, you can set use_devicesfile=0 in lvm.conf, or just rm /etc/lvm/devices/system.devices to avoid the problem.

Comment 2 David Teigland 2021-06-08 17:21:45 UTC
fixed in https://sourceware.org/git/?p=lvm2.git;a=commit;h=ca930bd936de2e7d4a83fa64add800baf6cfd116

$ cat /sys/block/loop0/loop/backing_file 
/root/looptmp (deleted)
$ losetup -l
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE
/dev/loop0         0      0         0  0 /root/looptmp (deleted)
$ lvmdevices --adddev /dev/loop0
$ lvmdevices 
  Device /dev/loop0 IDTYPE=devname IDNAME=/dev/loop0 DEVNAME=/dev/loop0 PVID=none
$ pvcreate /dev/loop0
  Physical volume "/dev/loop0" successfully created.

Comment 3 Marius Vollmer 2021-06-09 07:24:00 UTC
(In reply to David Teigland from comment #1)
> Do you always delete the file before using the loop dev?

Yes.

Comment 4 Marius Vollmer 2021-06-09 07:26:41 UTC
(In reply to David Teigland from comment #1)

> Until a fix is available, you can set use_devicesfile=0 in lvm.conf, or just
> rm /etc/lvm/devices/system.devices to avoid the problem.

Thanks for the information!  I think we actually prefer to not change the lvm2 configuration; we want to find bugs like this.  We will move the "rm" call to the cleanup steps.  (We will also mark this as a workaround for this bug so that we might remember to remove it once the fix has landed.)

Comment 8 Corey Marthaler 2021-08-30 22:54:37 UTC
Marking Verified:Tested in the latest rpms.

kernel-5.14.0-0.rc7.54.el9    BUILT: Tue Aug 24 02:54:42 PM CDT 2021
lvm2-2.03.13-1.el9    BUILT: Thu Aug 12 10:44:54 AM CDT 2021
lvm2-libs-2.03.13-1.el9    BUILT: Thu Aug 12 10:44:54 AM CDT 2021
 

SCENARIO - loopback_uuid_device
Test devicesfile addition and deletion using odd loopback devices, then remove the backing file (bug 1969408)
50+0 records in
50+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.0256899 s, 2.0 GB/s
creating PV on hayes-03 using device /dev/loop0

  Physical volume "/dev/loop0" successfully created.
1a. Check for valid devicesfile entry for loopback created 8gdPEqqiKK1MpiePIwqwdGEmRhGAycPL
IDTYPE=devname IDNAME=/dev/loop0 DEVNAME=/dev/loop0 PVID=8gdPEqqiKK1MpiePIwqwdGEmRhGAycPL
1b. Remove device file entry based on PV name /dev/loop0

removing entry from the devices file for /dev/loop0

2a. Add device file entry based on PVID 8gdPEqqiKK1MpiePIwqwdGEmRhGAycPL
  Found PVID 8gdPEqqiKK1MpiePIwqwdGEmRhGAycPL on /dev/loop0.
IDTYPE=devname IDNAME=/dev/loop0 DEVNAME=/dev/loop0 PVID=8gdPEqqiKK1MpiePIwqwdGEmRhGAycPL
2b. Remove device file entry based on PVID 8gdPEqqiKK1MpiePIwqwdGEmRhGAycPL
3. Add device file entry based on PV name
adding entry to the devices file for /dev/loop0

IDTYPE=devname IDNAME=/dev/loop0 DEVNAME=/dev/loop0 PVID=8gdPEqqiKK1MpiePIwqwdGEmRhGAycPL
removing pv /dev/loop0
 on hayes-03
  Labels on physical volume "/dev/loop0" successfully wiped.

Comment 14 Red Hat Bugzilla 2024-01-02 04:25:03 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days