[linux-lvm] LVM cache/dm-cache questions.
lejeczek
peljasz at yahoo.co.uk
Mon Aug 29 14:22:47 UTC 2016
$ lvs -a h200front
LV VG Attr LSize Pool
Origin Data% Meta% Move Log Cpy%Sync Convert
0 h200front Cwi-aoC--- 9.10t
[cache0] [0_corig] 100.00 8.18 0.00
[0_corig] h200front rwi-aoC---
9.10t 100.00
[0_corig_rimage_0] h200front iwi-aor--- 1.82t
[0_corig_rimage_1] h200front iwi-aor--- 1.82t
[0_corig_rimage_2] h200front iwi-aor--- 1.82t
[0_corig_rimage_3] h200front iwi-aor--- 1.82t
[0_corig_rimage_4] h200front iwi-aor--- 1.82t
[0_corig_rimage_5] h200front iwi-aor--- 1.82t
[0_corig_rmeta_0] h200front ewi-aor--- 4.00m
[0_corig_rmeta_1] h200front ewi-aor--- 4.00m
[0_corig_rmeta_2] h200front ewi-aor--- 4.00m
[0_corig_rmeta_3] h200front ewi-aor--- 4.00m
[0_corig_rmeta_4] h200front ewi-aor--- 4.00m
[0_corig_rmeta_5] h200front ewi-aor--- 4.00m
[cache0] h200front Cwi---C---
220.00g 100.00 8.18 0.00
[cache0_cdata] h200front Cwi-aor---
220.00g 100.00
[cache0_cdata_rimage_0] h200front iwi-aor--- 220.00g
[cache0_cdata_rimage_1] h200front iwi-aor--- 220.00g
[cache0_cdata_rmeta_0] h200front ewi-aor--- 4.00m
[cache0_cdata_rmeta_1] h200front ewi-aor--- 4.00m
[cache0_cmeta] h200front ewi-aor---
512.00m 100.00
[cache0_cmeta_rimage_0] h200front iwi-aor--- 512.00m
[cache0_cmeta_rimage_1] h200front iwi-aor--- 512.00m
[cache0_cmeta_rmeta_0] h200front ewi-aor--- 4.00m
[cache0_cmeta_rmeta_1] h200front ewi-aor--- 4.00m
[lvol0_pmspare] h200front ewi------- 512.00m
I cannot debug now as for now I've given up the idea to
encrypt this LV, but I would say is should be easily
reproducible (maybe even waste of time looking at my setup)
I simply tried:
cryptsetup -v luksFormat /dev/mapper/h200front-0
and that works(ed) with "regurlar" LVs.
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE
MOUNTPOINT
sda 8:0 0 238.5G 0 disk
├─sda1 8:1 0 1G 0 part
/boot
└─sda2 8:2 0 237.5G 0 part
├─SL-root 253:0 0 150G 0 lvm /
└─SL-home 253:1 0 10G 0 lvm
sdb 8:16 0 223.6G 0 disk
├─h200front-cache0_cdata_rmeta_0 253:4 0 4M 0 lvm
│ └─h200front-cache0_cdata 253:8 0 220G 0 lvm
│ └─h200front-0 253:29 0 9.1T 0 lvm
├─h200front-cache0_cdata_rimage_0 253:5 0 220G 0 lvm
│ └─h200front-cache0_cdata 253:8 0 220G 0 lvm
│ └─h200front-0 253:29 0 9.1T 0 lvm
├─h200front-cache0_cmeta_rmeta_0 253:9 0 4M 0 lvm
│ └─h200front-cache0_cmeta 253:13 0 512M 0 lvm
│ └─h200front-0 253:29 0 9.1T 0 lvm
└─h200front-cache0_cmeta_rimage_0 253:10 0 512M 0 lvm
└─h200front-cache0_cmeta 253:13 0 512M 0 lvm
└─h200front-0 253:29 0 9.1T 0 lvm
sdc 8:32 0 223.6G 0 disk
├─h200front-cache0_cdata_rmeta_1 253:6 0 4M 0 lvm
│ └─h200front-cache0_cdata 253:8 0 220G 0 lvm
│ └─h200front-0 253:29 0 9.1T 0 lvm
├─h200front-cache0_cdata_rimage_1 253:7 0 220G 0 lvm
│ └─h200front-cache0_cdata 253:8 0 220G 0 lvm
│ └─h200front-0 253:29 0 9.1T 0 lvm
├─h200front-cache0_cmeta_rmeta_1 253:11 0 4M 0 lvm
│ └─h200front-cache0_cmeta 253:13 0 512M 0 lvm
│ └─h200front-0 253:29 0 9.1T 0 lvm
└─h200front-cache0_cmeta_rimage_1 253:12 0 512M 0 lvm
└─h200front-cache0_cmeta 253:13 0 512M 0 lvm
└─h200front-0 253:29 0 9.1T 0 lvm
sdd 8:48 0 894.3G 0 disk
└─h300Int1-0 253:2 0 1.8T 0 lvm
└─h300Int1.0_crypt 253:27 0 1.8T 0
crypt /__.aLocalStorages/2
sde 8:64 0 894.3G 0 disk
└─h300Int1-0 253:2 0 1.8T 0 lvm
└─h300Int1.0_crypt 253:27 0 1.8T 0
crypt /__.aLocalStorages/2
sdf 8:80 0 447.1G 0 disk
└─h300Int0-0 253:3 0 1.3T 0 lvm
└─h300Int0.0_crypt 253:28 0 1.3T 0
crypt /__.aLocalStorages/1
sdg 8:96 0 447.1G 0 disk
└─h300Int0-0 253:3 0 1.3T 0 lvm
└─h300Int0.0_crypt 253:28 0 1.3T 0
crypt /__.aLocalStorages/1
sdh 8:112 0 447.1G 0 disk
└─h300Int0-0 253:3 0 1.3T 0 lvm
└─h300Int0.0_crypt 253:28 0 1.3T 0
crypt /__.aLocalStorages/1
sdi 8:128 0 1.8T 0 disk
├─h200front-0_corig_rmeta_0 253:14 0 4M 0 lvm
│ └─h200front-0_corig 253:26 0 9.1T 0 lvm
│ └─h200front-0 253:29 0 9.1T 0 lvm
└─h200front-0_corig_rimage_0 253:15 0 1.8T 0 lvm
└─h200front-0_corig 253:26 0 9.1T 0 lvm
└─h200front-0 253:29 0 9.1T 0 lvm
sdj 8:144 0 1.8T 0 disk
├─h200front-0_corig_rmeta_1 253:16 0 4M 0 lvm
│ └─h200front-0_corig 253:26 0 9.1T 0 lvm
│ └─h200front-0 253:29 0 9.1T 0 lvm
└─h200front-0_corig_rimage_1 253:17 0 1.8T 0 lvm
└─h200front-0_corig 253:26 0 9.1T 0 lvm
└─h200front-0 253:29 0 9.1T 0 lvm
sdk 8:160 0 1.8T 0 disk
├─h200front-0_corig_rmeta_2 253:18 0 4M 0 lvm
│ └─h200front-0_corig 253:26 0 9.1T 0 lvm
│ └─h200front-0 253:29 0 9.1T 0 lvm
└─h200front-0_corig_rimage_2 253:19 0 1.8T 0 lvm
└─h200front-0_corig 253:26 0 9.1T 0 lvm
└─h200front-0 253:29 0 9.1T 0 lvm
sdl 8:176 0 1.8T 0 disk
├─h200front-0_corig_rmeta_3 253:20 0 4M 0 lvm
│ └─h200front-0_corig 253:26 0 9.1T 0 lvm
│ └─h200front-0 253:29 0 9.1T 0 lvm
└─h200front-0_corig_rimage_3 253:21 0 1.8T 0 lvm
└─h200front-0_corig 253:26 0 9.1T 0 lvm
└─h200front-0 253:29 0 9.1T 0 lvm
sdm 8:192 0 1.8T 0 disk
├─h200front-0_corig_rmeta_4 253:22 0 4M 0 lvm
│ └─h200front-0_corig 253:26 0 9.1T 0 lvm
│ └─h200front-0 253:29 0 9.1T 0 lvm
└─h200front-0_corig_rimage_4 253:23 0 1.8T 0 lvm
└─h200front-0_corig 253:26 0 9.1T 0 lvm
└─h200front-0 253:29 0 9.1T 0 lvm
sdn 8:208 0 1.8T 0 disk
├─h200front-0_corig_rmeta_5 253:24 0 4M 0 lvm
│ └─h200front-0_corig 253:26 0 9.1T 0 lvm
│ └─h200front-0 253:29 0 9.1T 0 lvm
└─h200front-0_corig_rimage_5 253:25 0 1.8T 0 lvm
└─h200front-0_corig 253:26 0 9.1T 0 lvm
└─h200front-0 253:29 0 9.1T 0 lvm
sdo 8:224 0 9.1T 0 disk
/__.aLocalStorages/3
LV is working fine, being a host for all sorts of data, only
cryptsetup does not work on it.
many thanks.
On 29/08/16 12:22, Ondrej Kozina wrote:
> 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
More information about the linux-lvm
mailing list