Dne 27. 09. 23 v 15:45 Jean-Marc Saffroy napsal(a):
On Wed, Sep 27, 2023 at 11:58 AM Zdenek Kabelac
<zdenek.kabelac@xxxxxxxxx> wrote:
Dne 27. 09. 23 v 1:10 Jean-Marc Saffroy napsal(a):
Hi,
On Tue, Sep 26, 2023 at 10:00 PM Zdenek Kabelac
<zdenek.kabelac@xxxxxxxxx> wrote:
Yep typical usage is to encrypt underlying PV - and then create LVs and its
snapshots on encrypted device.
Sure, I'd do that in other circumstances.
But in my case it would just be a waste: I am replacing several disks
on a desktop computer with a single 2TB NVME SSD for everything. Only
/home needs to be encrypted, and it's tiny, like 100-200GB. Going
through encryption for most application I/Os would use CPU time and
increase latency with no benefit.
So I prefer to manage available raw (un-encrypted) space with LVM.
Now, I also need to do backups of /home, and that's why I want
snapshots. But that first layer of LVM would only show a snapshot of
an encrypted volume, and the backup job shouldn't have the passphrase
to decrypt the volume.
Which is why I'm trying to find a way of doing snaphots of an "opened"
LUKS volume: this way, the backup job can do its job without requiring
a passphrase.
well that's where you will considerably 'complicate' your life :)
As you would need to 'orchestrace' this yourself with 'dmsetup' usage.
If you mean that I'd have to script a few things, then I am perfectly
fine with that.
running 'dmsetup suspend' on your home device,
that taking a snapshot of your underlying LV.
What is the role of "dmsetup suspend"? I am having trouble finding
decent documentation about its purpose and how it's related to
snapshots. I did not need it in my experiments, so I am curious.
Suspend is freezing device's i/o queue (together with freezing FS layer - so
the snapshot should be easily mountable without requiring extensive fsck
operation as it would be missing some important metadata to be written on disk)
So the goal of a suspend is to take a 'good point in time' where the content
of snapshot is having all 'committed' transaction on disk in valid state.
Clearly that needs a 'top-level device - which would be a crypto DM in your
case - and goes via 'tree' down to PV level.
Clearly lvm2 does this while taking snapshot - and you can easily observe
that 'magic' if you read carefully -vvvv trace of a command.
Then your script needs to replicate this at script level.
Fun would begin once you would start to resolve all the possible error paths...
If I were okay with giving the passphrase to my backup script, then I
could simply have the backup script create its snapshot from the
encrypted LV, and I wouldn't have started this thread in this case.
:-)
Maybe you could drop your whole disk encryption idea then and just use some
encrypted tarballs - since if you tend to place passwords into scripts - it's
kind of big security hole....
If all you want to have is encrypted files on disk - there are probably more
easier approaches with the use of encrypted filesystems...
But the level of complexity here is rather high - this it might be actually
way easier to just 'partition' your device for 'encrypted' and unecrypted'
parts and use 2 PVs for 2 VGs....
But then I can't resize the encrypted volume/partition.
Not sure how often do you need to do that - surely a 'split' between those 2
partitions is a decisive point...
But then whatever you do within those VG is fully resizable as before.
It seems LVM cannot do it directly, but it becomes possible (at least
in my simple tests) if I use a bunch of dmsetup commands, or if I use
the decrypted device as the PV for a new VG.
But I don't know if these approaches are safe to use, and that is what
drove me here.
In the mean time, I found this page:
https://access.redhat.com/articles/2106521
Apparently, LVM on LUKS on LVM would be case of "LVM recursion", and
so not entirely unheard of.
Does anyone here have experience with "LVM recursion"?
lvm2 does not advice to use 'stacking' - it's very complicated and in some
way inefficient - it's always true the less layers -> the better the
performance will be (especially true with modern NVMe devices...)
And lvm2 itself does NOT support/count with recursion - so while it may appear
to be working - there will be corner cases with unresolvable problems -
although this is mostly an issue if you are running your system from such
'stacked' solution (causing deadlocks...)
Anyway - placing VG on top of another VG is always good to avoid and use only
as a last resource if there is no better approach existing.
Regards
Zdenek
_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
