1742815 – Online reencryption ignores optimal io size parameter

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1742815 - Online reencryption ignores optimal io size parameter

Summary: Online reencryption ignores optimal io size parameter

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 8
Classification:	Red Hat
Component:	cryptsetup
Sub Component:
Version:	8.1
Hardware:	x86_64
OS:	Linux
Priority:	urgent
Severity:	medium
Target Milestone:	rc
Target Release:	8.0
Assignee:	Ondrej Kozina
QA Contact:	guazhang@redhat.com
Docs Contact:
URL:
Whiteboard:
Duplicates (1):	1751003 (view as bug list)
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2019-08-16 21:02 UTC by Corey Marthaler
Modified:	2021-09-06 15:20 UTC (History)
CC List:	8 users (show)
Fixed In Version:	cryptsetup-2.2.0-2.el8
Doc Type:	No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed:	2019-11-05 22:17:22 UTC
Type:	Bug
Target Upstream Version:
Embargoed:
Dependent Products:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2019:3569	0	None	None	None	2019-11-05 22:17:24 UTC

Description Corey Marthaler 2019-08-16 21:02:07 UTC

Description of problem:
I just noticed these messages in the logs of the test machines doing online re-encryption testing, happening directly after the encryption. So far there has been no test failures but these are going to be concerning to users if they're not understood.


[root@hayes-01 ~]#  grep "caused an alignment inconsistency" /var/log/messages | wc -l
30298

[root@hayes-02 ~]# grep "caused an alignment inconsistency" /var/log/messages | wc -l
177


/var/log/messages:
Aug 16 15:21:19 hayes-01 qarshd[25868]: Running cmdline: echo Str0ngP455w0rd### | cryptsetup reencrypt --resilience journal --active-name luks_origin
Aug 16 15:21:27 hayes-01 kernel: device-mapper: table: 253:13: adding target device (start sect 31696 len 5104688) caused an alignment inconsistency
Aug 16 15:21:28 hayes-01 kernel: device-mapper: table: 253:13: adding target device (start sect 31696 len 31696) caused an alignment inconsistency
Aug 16 15:21:28 hayes-01 kernel: device-mapper: table: 253:13: adding target device (start sect 63392 len 5072992) caused an alignment inconsistency
Aug 16 15:21:28 hayes-01 kernel: device-mapper: table: 253:13: adding target device (start sect 63392 len 31696) caused an alignment inconsistency
[...]


Version-Release number of selected component (if applicable):
cryptsetup-2.2.0-1.el8    BUILT: Fri Aug 16 01:22:41 CDT 2019
cryptsetup-libs-2.2.0-1.el8    BUILT: Fri Aug 16 01:22:41 CDT 2019
cryptsetup-reencrypt-2.2.0-1.el8    BUILT: Fri Aug 16 01:22:41 CDT 2019

kernel-4.18.0-134.el8    BUILT: Thu Aug 15 13:08:19 CDT 2019
lvm2-2.03.05-2.el8    BUILT: Wed Jul 24 08:05:11 CDT 2019

Comment 1 Ondrej Kozina 2019-08-19 10:19:33 UTC

I'll try to reproduce it locally but could you please add some more info here so that I'm sure it's the same problem?

1) cryptsetup luksDump output for the device after encryption finished
2) "lsblk -t" output with device tree underneath the luks_origin mapping (after encryption is finished)
3) Initialize reencryption operation only by adding --init-only parameter and then paste here cryptsetup luksDump command output again?

Comment 2 Ondrej Kozina 2019-08-19 13:37:41 UTC

I've reproduced it locally but only in limited scope on a test drive with 4k sector size with 512B emulation (logical size 512, physical sector size 4096). I can hit that when I ask explicitly for weird sized reencryption hotzone via --hotzone-size parameter (in my case --hotzone-size 2047s). In default mode I can't hit it yet. So I think it mostly depends on how you encrypted the device and what's beneath the dm-crypt device when you perform reencryption. I don't say this is not a bug, but I definitely need more info before I start tinkering on patch :)

Comment 3 Corey Marthaler 2019-08-20 21:41:51 UTC

I haven't had time to boil this down yet, but this appears to be the test case causing these messages. I was just able to reproduce this now:


[root@hayes-03 ~]# vgcreate cache_sanity /dev/sd[bcdefghijklmnop]1
  Volume group "cache_sanity" successfully created
[root@hayes-03 ~]# pvchange --addtag slow /dev/sdf1
  Physical volume "/dev/sdf1" changed
  1 physical volume changed / 0 physical volumes not changed
[root@hayes-03 ~]# pvchange --addtag fast /dev/sdl1
  Physical volume "/dev/sdl1" changed
  1 physical volume changed / 0 physical volumes not changed
[root@hayes-03 ~]# lvcreate --wipesignatures y -L 4G -n corigin cache_sanity @slow
  Logical volume "corigin" created.
[root@hayes-03 ~]# lvcreate -L 4G -n resize cache_sanity @fast
WARNING: crypto_LUKS signature detected on /dev/cache_sanity/resize at offset 0. Wipe it? [y/n]: y
  Wiping crypto_LUKS signature on /dev/cache_sanity/resize.
WARNING: crypto_LUKS signature detected on /dev/cache_sanity/resize at offset 16384. Wipe it? [y/n]: y
  Wiping crypto_LUKS signature on /dev/cache_sanity/resize.
  Logical volume "resize" created.
[root@hayes-03 ~]# lvcreate -L 12M -n resize_meta cache_sanity @fast
  Logical volume "resize_meta" created.
[root@hayes-03 ~]# lvconvert --yes --type cache-pool --cachepolicy smq --cachemode writethrough -c 32 --poolmetadata cache_sanity/resize_meta cache_sanity/resize
  WARNING: Converting cache_sanity/resize and cache_sanity/resize_meta to cache pool's data and metadata volumes with metadata wiping.
  THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
  Converted cache_sanity/resize and cache_sanity/resize_meta to cache pool.
[root@hayes-03 ~]# lvconvert --yes --type cache --cachemetadataformat 2 --cachepool cache_sanity/resize cache_sanity/corigin
  Logical volume cache_sanity/corigin is now cached.
[root@hayes-03 ~]# lvs --noheadings -o lv_name --select 'cachemetadataformat=2' | grep corigin
  corigin
[root@hayes-03 ~]# echo Str0ngP455w0rd### | cryptsetup luksFormat /dev/cache_sanity/corigin
[root@hayes-03 ~]# echo Str0ngP455w0rd### | cryptsetup luksOpen /dev/cache_sanity/corigin luks_corigin
[root@hayes-03 ~]# mkfs.xfs -f /dev/mapper/luks_corigin
meta-data=/dev/mapper/luks_corigin isize=512    agcount=8, agsize=130560 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1
data     =                       bsize=4096   blocks=1044480, imaxpct=25
         =                       sunit=8      swidth=8 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
[root@hayes-03 ~]# mkdir -p /mnt/corigin
[root@hayes-03 ~]# mount /dev/mapper/luks_corigin /mnt/corigin
[root@hayes-03 ~]# /usr/tests/sts-rhel8.1/bin/checkit -w /mnt/corigin -f /tmp/checkit_origin_1 -n 1200
checkit starting with:
CREATE
Num files:          1200
Random Seed:        17661
Verify XIOR Stream: /tmp/checkit_origin_1
Working dir:        /mnt/corigin
[root@hayes-03 ~]# /usr/tests/sts-rhel8.1/bin/checkit -w /mnt/corigin -f /tmp/checkit_origin_1 -v
checkit starting with:
VERIFY
Verify XIOR Stream: /tmp/checkit_origin_1
Working dir:        /mnt/corigin
[root@hayes-03 ~]# sync
[root@hayes-03 ~]# lvs --noheadings -o lv_attr cache_sanity/corigin
  Cwi-aoC---
[root@hayes-03 ~]# lvcreate -s /dev/cache_sanity/corigin -c 64 -n snap1 -L 4100.00m
  Logical volume "snap1" created.
[root@hayes-03 ~]# lvs --noheadings -o lv_attr cache_sanity/snap1
  swi-a-s---
[root@hayes-03 ~]# lvconvert --uncache /dev/cache_sanity/corigin
  Logical volume "resize" successfully removed
  Logical volume cache_sanity/corigin is not cached.
[root@hayes-03 ~]# lvcreate -L 5G -n resize cache_sanity @fast
WARNING: crypto_LUKS signature detected on /dev/cache_sanity/resize at offset 0. Wipe it? [y/n]: y
  Wiping crypto_LUKS signature on /dev/cache_sanity/resize.
WARNING: crypto_LUKS signature detected on /dev/cache_sanity/resize at offset 16384. Wipe it? [y/n]: y
  Wiping crypto_LUKS signature on /dev/cache_sanity/resize.
  Logical volume "resize" created.
[root@hayes-03 ~]# lvcreate -L 12M -n resize_meta cache_sanity @fast
  Logical volume "resize_meta" created.
[root@hayes-03 ~]# lvconvert --yes --type cache-pool --cachepolicy smq --cachemode writeback -c 32 --poolmetadata cache_sanity/resize_meta cache_sanity/resize
  WARNING: Converting cache_sanity/resize and cache_sanity/resize_meta to cache pool's data and metadata volumes with metadata wiping.
  THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
  Converted cache_sanity/resize and cache_sanity/resize_meta to cache pool.
[root@hayes-03 ~]# lvconvert --yes --type cache --cachemetadataformat 1 --cachepool cache_sanity/resize cache_sanity/corigin
  Logical volume cache_sanity/corigin is now cached.
[root@hayes-03 ~]# lvs --noheadings -o lv_name --select 'cachemetadataformat=1' | grep corigin
  corigin
[root@hayes-03 ~]# echo Str0ngP455w0rd### | cryptsetup luksOpen /dev/cache_sanity/snap1 luks_snap1
[root@hayes-03 ~]# cryptsetup -v status luks_snap1
/dev/mapper/luks_snap1 is active.
  type:    LUKS2
  cipher:  aes-xts-plain64
  keysize: 512 bits
  key location: keyring
  device:  /dev/mapper/cache_sanity-snap1
  sector size:  512
  offset:  32768 sectors
  size:    8355840 sectors
  mode:    read/write
Command successful.
[root@hayes-03 ~]# mkdir -p /mnt/snap1
[root@hayes-03 ~]# mount -o nouuid /dev/mapper/luks_snap1 /mnt/snap1
[root@hayes-03 ~]# /usr/tests/sts-rhel8.1/bin/checkit -w /mnt/snap1 -f /tmp/checkit_origin_1 -v
checkit starting with:
VERIFY
Verify XIOR Stream: /tmp/checkit_origin_1
Working dir:        /mnt/snap1
[root@hayes-03 ~]# lvs -a -o +devices
  LV              VG           Attr       LSize  Pool     Origin          Data%  Meta%  Move Log Cpy%Sync Convert Devices         
  corigin         cache_sanity owi-aoC---  4.00g [resize] [corigin_corig] 0.07   10.87           0.00             corigin_corig(0)
  [corigin_corig] cache_sanity owi-aoC---  4.00g                                                                  /dev/sdf1(0)    
  [lvol0_pmspare] cache_sanity ewi------- 12.00m                                                                  /dev/sdb1(0)    
  [resize]        cache_sanity Cwi---C---  5.00g                          0.07   10.87           0.00             resize_cdata(0) 
  [resize_cdata]  cache_sanity Cwi-ao----  5.00g                                                                  /dev/sdl1(0)    
  [resize_cmeta]  cache_sanity ewi-ao---- 12.00m                                                                  /dev/sdl1(1280) 
  snap1           cache_sanity swi-aos---  4.00g          corigin         0.07                                    /dev/sdb1(3)    
[root@hayes-03 ~]# /usr/tests/sts-rhel8.1/bin/checkit -w /mnt/corigin -f /tmp/checkit_origin_2 -n 1200
checkit starting with:
CREATE
Num files:          1200
Random Seed:        18105
Verify XIOR Stream: /tmp/checkit_origin_2
Working dir:        /mnt/corigin
[root@hayes-03 ~]# lvs -a -o +devices
  LV              VG           Attr       LSize  Pool     Origin          Data%  Meta%  Move Log Cpy%Sync Convert Devices         
  corigin         cache_sanity owi-aoC---  4.00g [resize] [corigin_corig] 0.07   10.87           0.00             corigin_corig(0)
  [corigin_corig] cache_sanity owi-aoC---  4.00g                                                                  /dev/sdf1(0)    
  [lvol0_pmspare] cache_sanity ewi------- 12.00m                                                                  /dev/sdb1(0)    
  [resize]        cache_sanity Cwi---C---  5.00g                          0.07   10.87           0.00             resize_cdata(0) 
  [resize_cdata]  cache_sanity Cwi-ao----  5.00g                                                                  /dev/sdl1(0)    
  [resize_cmeta]  cache_sanity ewi-ao---- 12.00m                                                                  /dev/sdl1(1280) 
  snap1           cache_sanity swi-aos---  4.00g          corigin         7.83                                    /dev/sdb1(3)    
[root@hayes-03 ~]# echo Str0ngP455w0rd### | cryptsetup reencrypt --resilience journal --active-name luks_corigin
Finished, time 04:31.803, 4080 MiB written, speed  15.0 MiB/s   

# While the above is running:
[...]
Aug 20 15:00:27 hayes-03 kernel: device-mapper: table: 253:10: adding target device (start sect 7638736 len 31696) caused an alignment inconsistency
Aug 20 15:00:27 hayes-03 kernel: device-mapper: table: 253:10: adding target device (start sect 7670432 len 685408) caused an alignment inconsistency
Aug 20 15:00:28 hayes-03 kernel: device-mapper: table: 253:10: adding target device (start sect 7670432 len 31696) caused an alignment inconsistency
Aug 20 15:00:28 hayes-03 kernel: device-mapper: table: 253:10: adding target device (start sect 7702128 len 653712) caused an alignment inconsistency
Aug 20 15:00:29 hayes-03 kernel: device-mapper: table: 253:10: adding target device (start sect 7702128 len 31696) caused an alignment inconsistency
Aug 20 15:00:29 hayes-03 kernel: device-mapper: table: 253:10: adding target device (start sect 7733824 len 622016) caused an alignment inconsistency
Aug 20 15:00:30 hayes-03 kernel: device-mapper: table: 253:10: adding target device (start sect 7765520 len 590320) caused an alignment inconsistency
[...]

[root@hayes-03 ~]# pvs
  PV         VG           Fmt  Attr PSize   PFree   
  /dev/sdb1  cache_sanity lvm2 a--  446.62g <442.61g
  /dev/sdc1  cache_sanity lvm2 a--  446.62g  446.62g
  /dev/sdd1  cache_sanity lvm2 a--  446.62g  446.62g
  /dev/sde1  cache_sanity lvm2 a--  446.62g  446.62g
  /dev/sdf1  cache_sanity lvm2 a--   <1.82t    1.81t
  /dev/sdg1  cache_sanity lvm2 a--   <1.82t   <1.82t
  /dev/sdh1  cache_sanity lvm2 a--   <1.82t   <1.82t
  /dev/sdi1  cache_sanity lvm2 a--   <1.82t   <1.82t
  /dev/sdj1  cache_sanity lvm2 a--   <1.82t   <1.82t
  /dev/sdk1  cache_sanity lvm2 a--   <1.82t   <1.82t
  /dev/sdl1  cache_sanity lvm2 a--   <1.82t    1.81t
  /dev/sdm1  cache_sanity lvm2 a--   <1.82t   <1.82t
  /dev/sdn1  cache_sanity lvm2 a--   <1.82t   <1.82t
  /dev/sdo1  cache_sanity lvm2 a--   <1.82t   <1.82t
  /dev/sdp1  cache_sanity lvm2 a--   <1.82t   <1.82t


[root@hayes-03 ~]# cryptsetup luksDump /dev/cache_sanity/corigin 
LUKS header information
Version:        2
Epoch:          536
Metadata area:  16384 [bytes]
Keyslots area:  16744448 [bytes]
UUID:           94e9101a-d009-4d2f-990d-d4efb6516fd2
Label:          (no label)
Subsystem:      (no subsystem)
Flags:          (no flags)

Data segments:
  0: crypt
        offset: 16777216 [bytes]
        length: (whole device)
        cipher: aes-xts-plain64
        sector: 512 [bytes]

Keyslots:
  1: luks2
        Key:        512 bits
        Priority:   normal
        Cipher:     aes-xts-plain64
        Cipher key: 512 bits
        PBKDF:      argon2i
        Time cost:  4
        Memory:     1048576
        Threads:    4
        Salt:       34 ce 58 46 b5 d7 ed f5 09 fb 41 62 02 9c bd 6d 
                    01 17 98 d7 fa 13 7a 8e c1 cc b0 d0 6e a6 38 f2 
        AF stripes: 4000
        AF hash:    sha256
        Area offset:290816 [bytes]
        Area length:258048 [bytes]
        Digest ID:  1
Tokens:
Digests:
  1: pbkdf2
        Hash:       sha256
        Iterations: 1000
        Salt:       d3 c8 9f 25 8e 14 67 a0 02 5b da a1 20 b7 76 9e 
                    d0 9a cd 06 26 e5 80 20 ee 37 58 29 0f 81 c8 e9 
        Digest:     a4 45 de 2a 28 a8 dc a2 05 1c 76 e9 93 c3 22 29 
                    be 2e 22 b6 a9 60 91 27 a0 89 9d ca 6d b7 34 8f 


[root@hayes-03 ~]# cryptsetup luksDump /dev/cache_sanity/snap1 
LUKS header information
Version:        2
Epoch:          3
Metadata area:  16384 [bytes]
Keyslots area:  16744448 [bytes]
UUID:           94e9101a-d009-4d2f-990d-d4efb6516fd2
Label:          (no label)
Subsystem:      (no subsystem)
Flags:          (no flags)

Data segments:
  0: crypt
        offset: 16777216 [bytes]
        length: (whole device)
        cipher: aes-xts-plain64
        sector: 512 [bytes]

Keyslots:
  0: luks2
        Key:        512 bits
        Priority:   normal
        Cipher:     aes-xts-plain64
        Cipher key: 512 bits
        PBKDF:      argon2i
        Time cost:  4
        Memory:     1048576
        Threads:    4
        Salt:       ce d2 69 49 e0 64 49 7a f0 e9 7b 39 10 ab 84 ab 
                    0e 0c cc e9 e1 1d 46 f6 64 8e 27 c4 35 6a dc 5d 
        AF stripes: 4000
        AF hash:    sha256
        Area offset:32768 [bytes]
        Area length:258048 [bytes]
        Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
        Hash:       sha256
        Iterations: 90269
        Salt:       71 d4 ab 78 92 ef 64 36 59 22 b3 27 af 72 7d 4f 
                    65 64 87 c0 7f ea 90 ce 82 38 cd 5e 8f b6 ed 1a 
        Digest:     1c 97 3e 57 af 75 c6 e0 d1 d4 d9 99 a5 18 ca 04 
                    73 a9 50 a7 bd 51 24 5c a0 c7 bb e4 72 c0 dd 9a 


[root@hayes-03 ~]# lsblk -t
NAME                            ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED       RQ-SIZE   RA WSAME
sda                                     0   4096      0    4096     512    1 mq-deadline     256 4096    0B
ââsda1                                  0   4096      0    4096     512    1 mq-deadline     256 4096    0B
ââsda2                                  0   4096      0    4096     512    1 mq-deadline     256 4096    0B
ââsda3                                  0   4096      0    4096     512    1 mq-deadline     256 4096    0B
sdb                                     0   4096      0    4096     512    1 mq-deadline     256 4096    0B
ââsdb1                                  0   4096      0    4096     512    1 mq-deadline     256 4096    0B
  ââcache_sanity-snap1-cow              0   4096      0    4096     512    1                 128 4096    0B
    ââcache_sanity-snap1                0  32768  32768    4096     512    1                 128 4096    0B
      ââluks_snap1                      0  32768  32768    4096     512    1                 128 4096    0B
sdc                                     0   4096      0    4096     512    1 mq-deadline     256 4096    0B
ââsdc1                                  0   4096      0    4096     512    1 mq-deadline     256 4096    0B
sdd                                     0   4096      0    4096     512    1 mq-deadline     256 4096    0B
ââsdd1                                  0   4096      0    4096     512    1 mq-deadline     256 4096    0B
sde                                     0   4096      0    4096     512    1 mq-deadline     256 4096    0B
ââsde1                                  0   4096      0    4096     512    1 mq-deadline     256 4096    0B
sdf                                     0    512      0     512     512    1 mq-deadline     256 4096    0B
ââsdf1                                  0    512      0     512     512    1 mq-deadline     256 4096    0B
  ââcache_sanity-corigin_corig          0    512      0     512     512    1                 128 4096    0B
    ââcache_sanity-corigin-real         0  32768  32768     512     512    1                 128 4096    0B
      ââcache_sanity-corigin            0  32768  32768     512     512    1                 128 4096    0B
      â ââluks_corigin                  0  32768  32768     512     512    1                 128 4096    0B
      ââcache_sanity-snap1              0  32768  32768    4096     512    1                 128 4096    0B
        ââluks_snap1                    0  32768  32768    4096     512    1                 128 4096    0B
sdg                                     0    512      0     512     512    1 mq-deadline     256 4096    0B
ââsdg1                                  0    512      0     512     512    1 mq-deadline     256 4096    0B
sdh                                     0    512      0     512     512    1 mq-deadline     256 4096    0B
ââsdh1                                  0    512      0     512     512    1 mq-deadline     256 4096    0B
sdi                                     0    512      0     512     512    1 mq-deadline     256 4096    0B
ââsdi1                                  0    512      0     512     512    1 mq-deadline     256 4096    0B
sdj                                     0    512      0     512     512    1 mq-deadline     256 4096    0B
ââsdj1                                  0    512      0     512     512    1 mq-deadline     256 4096    0B
sdk                                     0    512      0     512     512    1 mq-deadline     256 4096    0B
ââsdk1                                  0    512      0     512     512    1 mq-deadline     256 4096    0B
sdl                                     0    512      0     512     512    1 mq-deadline     256 4096    0B
ââsdl1                                  0    512      0     512     512    1 mq-deadline     256 4096    0B
  ââcache_sanity-resize_cdata           0    512      0     512     512    1                 128 4096    0B
  â ââcache_sanity-corigin-real         0  32768  32768     512     512    1                 128 4096    0B
  â   ââcache_sanity-corigin            0  32768  32768     512     512    1                 128 4096    0B
  â   â ââluks_corigin                  0  32768  32768     512     512    1                 128 4096    0B
  â   ââcache_sanity-snap1              0  32768  32768    4096     512    1                 128 4096    0B
  â     ââluks_snap1                    0  32768  32768    4096     512    1                 128 4096    0B
  ââcache_sanity-resize_cmeta           0    512      0     512     512    1                 128 4096    0B
    ââcache_sanity-corigin-real         0  32768  32768     512     512    1                 128 4096    0B
      ââcache_sanity-corigin            0  32768  32768     512     512    1                 128 4096    0B
      â ââluks_corigin                  0  32768  32768     512     512    1                 128 4096    0B
      ââcache_sanity-snap1              0  32768  32768    4096     512    1                 128 4096    0B
        ââluks_snap1                    0  32768  32768    4096     512    1                 128 4096    0B
sdm                                     0    512      0     512     512    1 mq-deadline     256 4096    0B
ââsdm1                                  0    512      0     512     512    1 mq-deadline     256 4096    0B
sdn                                     0    512      0     512     512    1 mq-deadline     256 4096    0B
ââsdn1                                  0    512      0     512     512    1 mq-deadline     256 4096    0B
sdo                                     0    512      0     512     512    1 mq-deadline     256 4096    0B
ââsdo1                                  0    512      0     512     512    1 mq-deadline     256 4096    0B
sdp                                     0    512      0     512     512    1 mq-deadline     256 4096    0B
ââsdp1                                  0    512      0     512     512    1 mq-deadline     256 4096    0B
sr0                                     0    512      0     512     512    1 mq-deadline      64  128    0B

Comment 4 Ondrej Kozina 2019-08-21 13:52:32 UTC

Online reencryption ignores optiomal-io size reported by device. To reproduce it easily create following scsi debug device:

1) modprobe scsi_debug dev_size_mb=256 opt_blks=64 opt_xferlen_exp=6 (results in /dev/sdx)
2) cryptsetup luksFormat /dev/sdx --offset 32768
3) cryptsetup open /dev/sdx sdx_crypt
4) cryptsetup reencrypt --resilience journal /dev/sdx

Comment 5 Ondrej Kozina 2019-08-21 13:53:29 UTC

(There's no risk to data AFAICT but it most probably cause performance degradation on more complex storage setup)

Comment 8 Ondrej Kozina 2019-08-29 15:50:25 UTC

Fixed upstream with https://gitlab.com/cryptsetup/cryptsetup/commit/6af4f7ca3d2ddcbe512fcf24b900e368bb255cfd

Comment 11 Ondrej Kozina 2019-09-02 09:35:17 UTC

The bug was introduced and fixed during 8.1 devel phase, no docs text needed.

Comment 12 Corey Marthaler 2019-09-03 23:10:47 UTC

Fix verified in the latest rpms.

cryptsetup-2.2.0-2.el8    BUILT: Fri Aug 30 07:54:20 CDT 2019
cryptsetup-libs-2.2.0-2.el8    BUILT: Fri Aug 30 07:54:20 CDT 2019
cryptsetup-reencrypt-2.2.0-2.el8    BUILT: Fri Aug 30 07:54:20 CDT 2019

Both the scenarios (comment #3 and comment #4) above that cause this no longer do. 


 [root@hayes-01 ~]# modprobe scsi_debug dev_size_mb=256 opt_blks=64 opt_xferlen_exp=6
[root@hayes-01 ~]# cryptsetup luksFormat /dev/sdl --offset 32768

WARNING!
========
This will overwrite data on /dev/sdl irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase for /dev/sdl: 
Verify passphrase: 

[root@hayes-01 ~]# cryptsetup open /dev/sdl sdl_crypt
Enter passphrase for /dev/sdl: 
[root@hayes-01 ~]# cryptsetup reencrypt --resilience journal /dev/sdl
Enter passphrase for key slot 0: 
Auto-detected active dm device 'sdl_crypt' for data device /dev/sdl.
Finished, time 00:04.947,  240 MiB written, speed  48.5 MiB/s   

[root@hayes-01 ~]#  grep "caused an alignment inconsistency" /var/log/messages
[root@hayes-01 ~]# 






SCENARIO - [cache_pool_resize_in_between_luks_encryption_operations]
Create snapshots of encrypted luks cache origin with fs data, and then extend and reduce both the cache pool volume in between re-encryption stack operations

*** Cache info for this scenario ***
*  origin (slow):  /dev/sdm1
*  pool (fast):    /dev/sdo1
************************************

Adding "slow" and "fast" tags to corresponding pvs
Create origin (slow) volume
lvcreate --wipesignatures y  -L 4G -n corigin cache_sanity @slow
WARNING: crypto_LUKS signature detected on /dev/cache_sanity/corigin at offset 0. Wipe it? [y/n]: [n]
  Aborted wiping of crypto_LUKS.
  1 existing signature left on the device.

Create cache data and cache metadata (fast) volumes
lvcreate  -L 4G -n resize cache_sanity @fast
WARNING: crypto_LUKS signature detected on /dev/cache_sanity/resize at offset 16384. Wipe it? [y/n]: [n]
  Aborted wiping of crypto_LUKS.
  1 existing signature left on the device.
lvcreate  -L 12M -n resize_meta cache_sanity @fast

Create cache pool volume by combining the cache data and cache metadata (fast) volumes with policy: mq  mode: writeback
lvconvert --yes --type cache-pool --cachepolicy mq --cachemode writeback -c 32 --poolmetadata cache_sanity/resize_meta cache_sanity/resize
  WARNING: Converting cache_sanity/resize and cache_sanity/resize_meta to cache pool's data and metadata volumes with metadata wiping.
  THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Create cached volume by combining the cache pool (fast) and origin (slow) volumes
lvconvert --yes --type cache --cachemetadataformat 1 --cachepool cache_sanity/resize cache_sanity/corigin

Encrypting corigin volume
cryptsetup luksFormat /dev/cache_sanity/corigin
cryptsetup luksOpen /dev/cache_sanity/corigin luks_corigin 
Placing an xfs filesystem on origin volume
Mounting origin volume

Writing files to /mnt/corigin

Checking files on /mnt/corigin

syncing before snap creation...
Making 1st snapshot of origin volume
lvcreate  -s /dev/cache_sanity/corigin -c 64 -n snap1 -L 4296704
Hack until live pool resize is supported: uncache and recreate pool w/ a larger size (lvconvert --uncache) cache_sanity/corigin
Create cache data and cache metadata (fast) volumes
lvcreate  -L 5G -n resize cache_sanity @fast
WARNING: crypto_LUKS signature detected on /dev/cache_sanity/resize at offset 0. Wipe it? [y/n]: [n]
  Aborted wiping of crypto_LUKS.
  1 existing signature left on the device.
lvcreate  -L 12M -n resize_meta cache_sanity @fast

Create cache pool volume by combining the cache data and cache metadata (fast) volumes with policy: cleaner  mode: writethrough
lvconvert --yes --type cache-pool --cachepolicy cleaner --cachemode writethrough -c 32 --poolmetadata cache_sanity/resize_meta cache_sanity/resize
  WARNING: Converting cache_sanity/resize and cache_sanity/resize_meta to cache pool's data and metadata volumes with metadata wiping.
  THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Create cached volume by combining the cache pool (fast) and origin (slow) volumes
lvconvert --yes --type cache --cachemetadataformat 2 --cachepool cache_sanity/resize cache_sanity/corigin


cryptsetup luksOpen /dev/cache_sanity/snap1 luks_snap1 
Mounting 1st snap volume
Checking files on /mnt/snap1

Writing files to /mnt/corigin
(ONLINE) Re-encrypting corigin volume
cryptsetup reencrypt --resilience journal --active-name luks_corigin 
[root@hayes-03 ~]#  grep "caused an alignment inconsistency" /var/log/messages
[root@hayes-03 ~]#

Comment 13 Ondrej Kozina 2019-09-11 08:14:01 UTC

*** Bug 1751003 has been marked as a duplicate of this bug. ***

Comment 15 errata-xmlrpc 2019-11-05 22:17:22 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:3569

Note You need to log in before you can comment on or make changes to this bug.