On 08/26/2016 04:01 PM, lejeczek wrote:
whatever you might call it, it works, luks encrypting,
opening & mounting @boot - so I only wonder (which was my
question) why not cache pool LVs. Is it not supported...
would be great if a developer sees this question, I'm not
sure jut yet about filing a bug report.
In general LVM2 doesn't auto-activate or interpret unknown device types.
LUKS header is considered unknown from LVM2 perspective. Simply put LVM2
doesn't understand LUKS header data. Not sure what you tried to do with
cache pool LV, but in my opinion any effort to encrypt (live or
detached) cache pool LV may end with severe data corruption...
As of now I think you have in general two options:
a) encrypt both PVs because obviously if you only encrypt the origin PV
you end up with decrypted plaintext data stored in cache pool. Probably
this is the exact scenario you were about to avoid?
Unfortunately a) is suboptimal with regard to performance since you'd
perform the encryption of data blocks twice.
Option b): encrypt the top level LV (the one constructed from both cache
and origin LV). This way ciphertext would be stored twice in cache PV
and origin PV but the encryption would be performed only once.
Regards
Ondrej
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
