Re: [linux-lvm] LVM cache/dm-cache questions.

[Ondrej Kozina <okozina@redhat.com>]

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