loop¶

Labels: enhancement, minor bug, no-pr-activity

david-hill opened issue at 2022-08-31 12:48:¶

Type: Bug Fix / Enhancement
Impact: Normal
Reference to related issue (URL):
https://github.com/rear/rear/issues/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 commented at 2022-09-01 14:00:¶

#2853

jsmeix commented at 2022-09-08 13:11:¶

@david-hill
thank you for your code enhancements.

jsmeix commented at 2022-09-08 13:12:¶

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

pcahyna commented at 2022-09-08 16:01:¶

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 commented at 2022-09-08 16:05:¶

@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 commented at 2022-09-08 16:15:¶

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 commented at 2022-09-12 08:08:¶

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

pcahyna commented at 2022-09-19 13:32:¶

I tried the proposed patch and even if we agree that skipping loop devices is what we want (cf. https://github.com/rear/rear/issues/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 commented at 2022-09-19 13:41:¶

@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 commented at 2022-09-19 14:48:¶

@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 commented at 2022-09-19 16:28:¶

@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 commented at 2022-11-19 02:59:¶

Stale pull request message

[Export of Github issue for rear/rear.]

#2854 PR closed: skip LVM PVs mounted on /dev/loop¶