skip LVM PVs mounted on /dev/loop

[david-hill]

• Type: Bug Fix / Enhancement

• Impact: Normal

• Reference to related issue (URL):
  Let ReaR deal with LVM VGs without LVs #2853

• How was this pull request tested?

• Brief description of the changes in this pull request:

Skip physical volumes that are created on loop back devices like

/dev/loop0p2:cinder_volume:996853760:-1:8:8:-1:4096:121686:41046:80640:something

[DEvil0000]

#2853

[jsmeix]

@david-hill
thank you for your code enhancements.

[jsmeix]

@rear/contributors
when there are no objections
I would like to merge it tomorrow afternoon.

[pcahyna]

It is not really an objection, but I would like to understand why is it needed when no such condition is needed for filesystems that sit directly on top of /dev/loop without LVM. At least, I don't see any such condition in the code.

[jsmeix]

@pcahyna
no problem - I will wait with merging it
until we understand how this happens because
perhaps the fix here is not (yet) the exact right one.

[david-hill]

I didn't personally hit this issue and it's probably easy to reproduce . Create a file in /var/run/tmp of 10GB, create a LVM PV/VG on it and no LVs. Mount it as a loopback device (I think it's the only way)

[pcahyna]

Thank you @david-hill for the information, I will attempt a reproducer myself.

[jsmeix]

The current fix here is not yet the right one, see
#2853 (comment)

[pcahyna]

I tried the proposed patch and even if we agree that skipping loop devices is what we want (cf. #2865 ), this approach is not entirely correct. While the patch fixes the case where there is no LV in the VG that resides on the loop device, it leads to another error when there actually is a LV - to demonstrate, this:

dd if=/dev/zero of=/var/tmp/loopvol bs=1024 count=102400
losetup /dev/loop0 /var/tmp/loopvol
pvcreate --yes /dev/loop0
vgcreate myvg /dev/loop0
lvcreate -y -n  my_lv  myvg -L 50M
rear savelayout

results in this error

LVM no 'lvmdev /dev/myvg' for 'lvmvol /dev/myvg'
ERROR: 
====================
BUG in /usr/share/rear/layout/save/default/950_verify_disklayout_file.sh line 254:
'Entries in /var/lib/rear/layout/disklayout.conf are broken ('rear recover' would fail)'

The problem apparently is that the patch skips PVs on loop devices, but it does not exclude the VGs and LVs residing on them - the resulting layout has:

lvmgrp /dev/myvg 4096 24 98304
lvmvol /dev/myvg my_lv 54525952b linear 

and no matching lvmdev /dev/myvg indeed. Exclusion would have to become more comprehensive in order to make this work.

[gdha]

@pcahyna @jsmeix What is a loop device?

The loop device is a block device that maps its data blocks not to a physical device such as a hard disk or optical disk drive, but to the blocks of a regular file in a filesystem or to another block device.

Is it not the purpose of ReaR to map only physical devices? Or, do we make our scope wider to also cover loop devices? When we decide on this we can continue to work on this PR or just skipt it...

[jsmeix]

@gdha
thank you for the explanation what a loop device really is.
(My personal usage of loop mounts was always only this way.)

As far as I understand it this means
ReaR should not care about loop devices
and what is mounted there.

My reasoning (as far as I understand it):

When something is mounted at a loop device
that something is a file or another block device.

When it is a file this file is restored from the backup.

When it is another block device and that other block device
is a physical device this physical device is recreated
by "rear recover" and its data is restored from the backup.

When it is another block device but this other block device
is not a physical device but a higher level storage device
this higher level storage device is also recreated
by "rear recover" and its data is restored from the backup.

When it is another block device but this other block device
is neither a physical device nor a higher level storage device
then I don't know what to do - I hope this case does not happen.

As far as I can imagine this are all possible cases.

For the above cases 1, 2, and 3 the actual data
must be restored from the backup.
When it is missing in the backup there is nothing
what ReaR could do (it is the user's task to ensure
his backup contains what he needs to recreate his system).

With the backup restore also config files get restored
so some config file could specify the loop mount
to let the system boot with automated loop mount
so also after "rear recover" the system will
reboot with that automated loop mount,
otherwise (when that loop mount is in no config file)
the system should boot without the loop mount
which means that loop mount was done manually
and ReaR should not care about manual loop mounts.

[pcahyna]

@jsmeix I suggest to continue the discussion of the merits of the proposal in #2865 , and discuss here only the details of the implementation (once we agree that it should be implemented). Concerning your last comment, "When something is mounted at a loop device that something is a file or another block device." this sounds confusing, because it seems you are speaking about the backing store the loop device is attached to (like a disk image file), rather than about what is mounted on the loop device (like a filesystem).

[github-actions]

Stale pull request message