From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v1.tansi.org (mail.tansi.org [84.19.178.47]) by mail.server123.net (Postfix) with ESMTP for ; Thu, 21 Feb 2019 14:02:19 +0100 (CET) Received: from gatewagner.dyndns.org (unknown [81.6.44.245]) by v1.tansi.org (Postfix) with ESMTPA id 097911400FD for ; Thu, 21 Feb 2019 14:02:03 +0100 (CET) Date: Thu, 21 Feb 2019 14:02:16 +0100 From: Arno Wagner Message-ID: <20190221130216.GA20021@tansi.org> References: <39009205-57b3-b009-d256-0c1db64e9d80@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <39009205-57b3-b009-d256-0c1db64e9d80@linux.ibm.com> Subject: Re: [dm-crypt] Filesystem corruption with LVM's pvmove onto an encrypted volume with LUKS2 and a sector size of 4096 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de Hi, LUKS should still be using 512 Byte sectors. Any mismatch there should just impact performance, I suspect you have an offset problem and the sector-numbers (used as initialization for each secor's encryption) are=20 shifted, expecially if this happens in plain mode as well. Regards, Arno On Thu, Feb 21, 2019 at 13:03:51 CET, Ingo Franzki wrote: > Hi, >=20 > we just encountered an error when using LVM's pvmove command to move the = data from an un-encrypted LVM physical volume onto an encrypted volume.=20 > After the pvmove has completed, the file system on the logical volume tha= t resides on the moved physical volumes is corrupted. >=20 > It seems to be related to a sector size of 4096 used with LUKS2. Once I u= se the default sector size (512) then the problem does not happen. > It happens with LUKS2 and even plain mode, as soon as a sector size of 40= 96 is used. LUKS1 and the default sector size does not show the problem.=20 >=20 > Not sure if this is a problem in dm-crypt or LVM, or a combination of bot= h. >=20 > Here is how to reproduce (note the error messages on the very last comman= d):=20 >=20 > # sudo dd if=3D/dev/zero of=3Dloopbackfile1.img bs=3D500M count=3D1 > 1+0 records in > 1+0 records out > 524288000 bytes (524 MB, 500 MiB) copied, 2.32777 s, 225 MB/s >=20 > # sudo dd if=3D/dev/zero of=3Dloopbackfile2.img bs=3D500M count=3D1 > 1+0 records in > 1+0 records out > 524288000 bytes (524 MB, 500 MiB) copied, 1.89992 s, 276 MB/s >=20 > # losetup -fP /root/loopbackfile1.img >=20 > # losetup -fP /root/loopbackfile2.img >=20 > # pvcreate /dev/loop0 > Physical volume "/dev/loop0" successfully created. >=20 > # vgcreate LOOP_VG /dev/loop0 > Volume group "LOOP_VG" successfully created >=20 > # lvcreate -L 300MB LOOP_VG -n LV /dev/loop0 > Logical volume "LV" created. >=20 > # mkfs.ext4 /dev/mapper/LOOP_VG-LV > mke2fs 1.44.1 (24-Mar-2018) > Discarding device blocks: done > Creating filesystem with 307200 1k blocks and 76912 inodes > Filesystem UUID: 344289a3-e251-4d88-b03d-a71a4be2a8ec > Superblock backups stored on blocks: > 8193, 24577, 40961, 57345, 73729, 204801, 221185 >=20 > Allocating group tables: done > Writing inode tables: done > Creating journal (8192 blocks): done > Writing superblocks and filesystem accounting information: done >=20 > # mount /dev/mapper/LOOP_VG-LV /mnt >=20 > # cryptsetup luksFormat --type luks2 --sector-size 4096 /dev/loop1 >=20 > WARNING! > =3D=3D=3D=3D=3D=3D=3D=3D > This will overwrite data on /dev/loop1 irrevocably. >=20 > Are you sure? (Type uppercase yes): YES > Enter passphrase for /dev/loop1: loop > Verify passphrase: loop >=20 > # cryptsetup luksOpen /dev/loop1 enc-loop > Enter passphrase for /dev/loop1: loop >=20 > # pvcreate /dev/mapper/enc-loop > Physical volume "/dev/mapper/enc-loop" successfully created. >=20 > # vgextend LOOP_VG /dev/mapper/enc-loop > Volume group "LOOP_VG" successfully extended >=20 > # pvs > PV VG Fmt Attr PSize PFree > /dev/loop0 LOOP_VG lvm2 a-- 496.00m 196.00m > /dev/mapper/enc-loop LOOP_VG lvm2 a-- 492.00m 492.00m >=20 > # pvmove /dev/loop0 /dev/mapper/enc-loop > /dev/loop0: Moved: 30.67% > /dev/loop0: Moved: 100.00% >=20 > # pvs > /dev/LOOP_VG/LV: read failed after 0 of 1024 at 0: Invalid argument > /dev/LOOP_VG/LV: read failed after 0 of 1024 at 314507264: Invalid argu= ment > /dev/LOOP_VG/LV: read failed after 0 of 1024 at 314564608: Invalid argu= ment > /dev/LOOP_VG/LV: read failed after 0 of 1024 at 4096: Invalid argument > PV VG Fmt Attr PSize PFree > /dev/loop0 LOOP_VG lvm2 a-- 496.00m 496.00m > /dev/mapper/enc-loop LOOP_VG lvm2 a-- 492.00m 192.00m >=20 > In case the filesystem of the logical volume is not mounted at the time o= f pvmove, it gets corrupted anyway, but you only see errors when trying to = mount it. >=20 > --=20 > Ingo Franzki > eMail: ifranzki@linux.ibm.com =20 > Tel: ++49 (0)7031-16-4648 > Fax: ++49 (0)7031-16-3456 > Linux on IBM Z Development, Schoenaicher Str. 220, 71032 Boeblingen, Germ= any >=20 > IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsr= ats: Matthias Hartmann > Gesch=E4ftsf=FChrung: Dirk Wittkopp > Sitz der Gesellschaft: B=F6blingen / Registergericht: Amtsgericht Stuttga= rt, HRB 243294 > IBM DATA Privacy Statement: https://www.ibm.com/privacy/us/en/ >=20 > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > https://www.saout.de/mailman/listinfo/dm-crypt --=20 Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of=20 "news" is "something that hardly ever happens." -- Bruce Schneier