On Wed, Sep 27, 2023 at 5:41 PM Zdenek Kabelac <zdenek.kabe...@gmail.com> wrote: > > > 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.
Is this still required or useful with a journaling FS like ext4? It is robust to pulling the plug at any time, so any point in time should be good, no? > 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... Clearly I have no plan to reimplement LVM with homegrown scripts. :-) That said, I am curious about what can be achieved with dmsetup commands. By any chance, do you have pointers to documentation besides what's in the kernel (Documentation/admin-guide/device-mapper/)? > > 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.... So I think I've found a decent alternative to putting passwords into scripts or files: kernel key rings. It turns out crypttab (at least on Debian) can leverage keyctl to enable reusing some secrets without exposing them too much. I half-tested a crypttab file like this: # <target name> <source device> <key file> <options> home /dev/vg1/crypthome home luks,noearly,keyscript=/root/decrypt_keyctl snap /dev/vg1/snap home luks,noauto,keyscript=/root/decrypt_keyctl The referenced script above is merely a copy Debian's decrypt_keyctl with the "keyctl timeout" lines commented. In this way, each re-creation of the snapshot should reuse the secret stored in root's "user" keyring with the "cryptsetup:home" description, and this secret should be first stored in the keyring when prompting the user at boot time. The backup job can later do something like this: > + lvcreate -n snap --snapshot -L 1G /dev/vg1/crypthome > Logical volume "snap" created. > + cryptdisks_start snap > Starting crypto disk...snap (starting)...Using cached passphrase for snap. > snap (started)...done. > + mount /dev/mapper/snap /mnt/snap ... perform the actual file backup... > + umount /mnt/snap > + cryptdisks_stop snap > Stopping crypto disk...snap (stopping)...done. > + lvremove -y /dev/vg1/snap > Logical volume "snap" successfully removed. And so in this case, LUKS on LVM can do the job and meet all my requirements. The minor drawback is that the passphrase can still be seen by root with a command like: keyctl print $(keyctl search @u user cryptsetup:home) But that's good enough for me. Cheers, JM _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
