On 08/29/2016 11:42 AM, lejeczek wrote:
On 26/08/16 15:45, Ondrej Kozina wrote:
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.
gee, guys, thanks Ondrej,
this I was saying from the beginning did not work - option b
- does not work. I can Not encrypt top level cache pool LV.
It does work with any other LV I have, but cache pool fails
(like I said earlier) with:
Command failed with code 22.
Could you post here 'lsblk' and 'lvs' output together with exact
cryptsetup command you have executed to luksFormat your top level cached
LV? Please add also --debug option among your original cryptsetup options.
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/
