All of lore.kernel.org
 help / color / mirror / Atom feed
* [dm-crypt] Filesystem corruption with LVM's pvmove onto an encrypted volume with LUKS2 and a sector size of 4096
@ 2019-02-21 12:03 Ingo Franzki
  2019-02-21 13:02 ` Arno Wagner
  2019-02-21 14:04 ` Ondrej Kozina
  0 siblings, 2 replies; 6+ messages in thread
From: Ingo Franzki @ 2019-02-21 12:03 UTC (permalink / raw)
  To: dm-crypt

Hi,

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. 
After the pvmove has completed, the file system on the logical volume that resides on the moved physical volumes is corrupted.

It seems to be related to a sector size of 4096 used with LUKS2. Once I use 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 4096 is used. LUKS1 and the default sector size does not show the problem. 

Not sure if this is a problem in dm-crypt or LVM, or a combination of both.

Here is how to reproduce (note the error messages on the very last command): 

# sudo dd if=/dev/zero of=loopbackfile1.img bs=500M count=1
1+0 records in
1+0 records out
524288000 bytes (524 MB, 500 MiB) copied, 2.32777 s, 225 MB/s

# sudo dd if=/dev/zero of=loopbackfile2.img bs=500M count=1
1+0 records in
1+0 records out
524288000 bytes (524 MB, 500 MiB) copied, 1.89992 s, 276 MB/s

# losetup -fP /root/loopbackfile1.img

# losetup -fP /root/loopbackfile2.img

# pvcreate /dev/loop0
  Physical volume "/dev/loop0" successfully created.

# vgcreate LOOP_VG /dev/loop0
  Volume group "LOOP_VG" successfully created

# lvcreate -L 300MB LOOP_VG -n LV /dev/loop0
  Logical volume "LV" created.

# 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

Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

# mount /dev/mapper/LOOP_VG-LV /mnt

# cryptsetup luksFormat --type luks2 --sector-size 4096 /dev/loop1

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

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

# cryptsetup luksOpen /dev/loop1 enc-loop
Enter passphrase for /dev/loop1: loop

# pvcreate /dev/mapper/enc-loop
  Physical volume "/dev/mapper/enc-loop" successfully created.

# vgextend LOOP_VG /dev/mapper/enc-loop
  Volume group "LOOP_VG" successfully extended

# 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

# pvmove /dev/loop0 /dev/mapper/enc-loop
  /dev/loop0: Moved: 30.67%
  /dev/loop0: Moved: 100.00%

# 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 argument
  /dev/LOOP_VG/LV: read failed after 0 of 1024 at 314564608: Invalid argument
  /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

In case the filesystem of the logical volume is not mounted at the time of pvmove, it gets corrupted anyway, but you only see errors when trying to mount it.

-- 
Ingo Franzki
eMail: ifranzki@linux.ibm.com  
Tel: ++49 (0)7031-16-4648
Fax: ++49 (0)7031-16-3456
Linux on IBM Z Development, Schoenaicher Str. 220, 71032 Boeblingen, Germany

IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: Matthias Hartmann
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM DATA Privacy Statement: https://www.ibm.com/privacy/us/en/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dm-crypt] Filesystem corruption with LVM's pvmove onto an encrypted volume with LUKS2 and a sector size of 4096
  2019-02-21 12:03 [dm-crypt] Filesystem corruption with LVM's pvmove onto an encrypted volume with LUKS2 and a sector size of 4096 Ingo Franzki
@ 2019-02-21 13:02 ` Arno Wagner
  2019-02-21 13:33   ` Ingo Franzki
  2019-02-21 14:04 ` Ondrej Kozina
  1 sibling, 1 reply; 6+ messages in thread
From: Arno Wagner @ 2019-02-21 13:02 UTC (permalink / raw)
  To: dm-crypt

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 
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,
> 
> 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. 
> After the pvmove has completed, the file system on the logical volume that resides on the moved physical volumes is corrupted.
> 
> It seems to be related to a sector size of 4096 used with LUKS2. Once I use 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 4096 is used. LUKS1 and the default sector size does not show the problem. 
> 
> Not sure if this is a problem in dm-crypt or LVM, or a combination of both.
> 
> Here is how to reproduce (note the error messages on the very last command): 
> 
> # sudo dd if=/dev/zero of=loopbackfile1.img bs=500M count=1
> 1+0 records in
> 1+0 records out
> 524288000 bytes (524 MB, 500 MiB) copied, 2.32777 s, 225 MB/s
> 
> # sudo dd if=/dev/zero of=loopbackfile2.img bs=500M count=1
> 1+0 records in
> 1+0 records out
> 524288000 bytes (524 MB, 500 MiB) copied, 1.89992 s, 276 MB/s
> 
> # losetup -fP /root/loopbackfile1.img
> 
> # losetup -fP /root/loopbackfile2.img
> 
> # pvcreate /dev/loop0
>   Physical volume "/dev/loop0" successfully created.
> 
> # vgcreate LOOP_VG /dev/loop0
>   Volume group "LOOP_VG" successfully created
> 
> # lvcreate -L 300MB LOOP_VG -n LV /dev/loop0
>   Logical volume "LV" created.
> 
> # 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
> 
> Allocating group tables: done
> Writing inode tables: done
> Creating journal (8192 blocks): done
> Writing superblocks and filesystem accounting information: done
> 
> # mount /dev/mapper/LOOP_VG-LV /mnt
> 
> # cryptsetup luksFormat --type luks2 --sector-size 4096 /dev/loop1
> 
> WARNING!
> ========
> This will overwrite data on /dev/loop1 irrevocably.
> 
> Are you sure? (Type uppercase yes): YES
> Enter passphrase for /dev/loop1: loop
> Verify passphrase: loop
> 
> # cryptsetup luksOpen /dev/loop1 enc-loop
> Enter passphrase for /dev/loop1: loop
> 
> # pvcreate /dev/mapper/enc-loop
>   Physical volume "/dev/mapper/enc-loop" successfully created.
> 
> # vgextend LOOP_VG /dev/mapper/enc-loop
>   Volume group "LOOP_VG" successfully extended
> 
> # 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
> 
> # pvmove /dev/loop0 /dev/mapper/enc-loop
>   /dev/loop0: Moved: 30.67%
>   /dev/loop0: Moved: 100.00%
> 
> # 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 argument
>   /dev/LOOP_VG/LV: read failed after 0 of 1024 at 314564608: Invalid argument
>   /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
> 
> In case the filesystem of the logical volume is not mounted at the time of pvmove, it gets corrupted anyway, but you only see errors when trying to mount it.
> 
> -- 
> Ingo Franzki
> eMail: ifranzki@linux.ibm.com  
> Tel: ++49 (0)7031-16-4648
> Fax: ++49 (0)7031-16-3456
> Linux on IBM Z Development, Schoenaicher Str. 220, 71032 Boeblingen, Germany
> 
> IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: Matthias Hartmann
> Geschäftsführung: Dirk Wittkopp
> Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
> IBM DATA Privacy Statement: https://www.ibm.com/privacy/us/en/
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt

-- 
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 
"news" is "something that hardly ever happens." -- Bruce Schneier

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dm-crypt] Filesystem corruption with LVM's pvmove onto an encrypted volume with LUKS2 and a sector size of 4096
  2019-02-21 13:02 ` Arno Wagner
@ 2019-02-21 13:33   ` Ingo Franzki
  0 siblings, 0 replies; 6+ messages in thread
From: Ingo Franzki @ 2019-02-21 13:33 UTC (permalink / raw)
  To: dm-crypt

On 21.02.2019 14:02, Arno Wagner wrote:
> Hi,
> 
> LUKS should still be using 512 Byte sectors. Any mismatch
> there should just impact performance,
Yes, LUKS(1) uses 512 and it does not show the problem, but LUKS2 supports larger sector sizes and it causes the problem if used.
> 
> I suspect you have an offset problem and the sector-numbers
> (used as initialization for each secor's encryption) are 
> shifted, expecially if this happens in plain mode as well.
Quite possible. Therefore I suspect a problem in dm-crypt and/or LVM. 
> 
> Regards,
> Arno
> 
> On Thu, Feb 21, 2019 at 13:03:51 CET, Ingo Franzki wrote:
>> Hi,
>>
>> 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. 
>> After the pvmove has completed, the file system on the logical volume that resides on the moved physical volumes is corrupted.
>>
>> It seems to be related to a sector size of 4096 used with LUKS2. Once I use 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 4096 is used. LUKS1 and the default sector size does not show the problem. 
>>
>> Not sure if this is a problem in dm-crypt or LVM, or a combination of both.
>>
>> Here is how to reproduce (note the error messages on the very last command): 
>>
>> # sudo dd if=/dev/zero of=loopbackfile1.img bs=500M count=1
>> 1+0 records in
>> 1+0 records out
>> 524288000 bytes (524 MB, 500 MiB) copied, 2.32777 s, 225 MB/s
>>
>> # sudo dd if=/dev/zero of=loopbackfile2.img bs=500M count=1
>> 1+0 records in
>> 1+0 records out
>> 524288000 bytes (524 MB, 500 MiB) copied, 1.89992 s, 276 MB/s
>>
>> # losetup -fP /root/loopbackfile1.img
>>
>> # losetup -fP /root/loopbackfile2.img
>>
>> # pvcreate /dev/loop0
>>   Physical volume "/dev/loop0" successfully created.
>>
>> # vgcreate LOOP_VG /dev/loop0
>>   Volume group "LOOP_VG" successfully created
>>
>> # lvcreate -L 300MB LOOP_VG -n LV /dev/loop0
>>   Logical volume "LV" created.
>>
>> # 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
>>
>> Allocating group tables: done
>> Writing inode tables: done
>> Creating journal (8192 blocks): done
>> Writing superblocks and filesystem accounting information: done
>>
>> # mount /dev/mapper/LOOP_VG-LV /mnt
>>
>> # cryptsetup luksFormat --type luks2 --sector-size 4096 /dev/loop1
>>
>> WARNING!
>> ========
>> This will overwrite data on /dev/loop1 irrevocably.
>>
>> Are you sure? (Type uppercase yes): YES
>> Enter passphrase for /dev/loop1: loop
>> Verify passphrase: loop
>>
>> # cryptsetup luksOpen /dev/loop1 enc-loop
>> Enter passphrase for /dev/loop1: loop
>>
>> # pvcreate /dev/mapper/enc-loop
>>   Physical volume "/dev/mapper/enc-loop" successfully created.
>>
>> # vgextend LOOP_VG /dev/mapper/enc-loop
>>   Volume group "LOOP_VG" successfully extended
>>
>> # 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
>>
>> # pvmove /dev/loop0 /dev/mapper/enc-loop
>>   /dev/loop0: Moved: 30.67%
>>   /dev/loop0: Moved: 100.00%
>>
>> # 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 argument
>>   /dev/LOOP_VG/LV: read failed after 0 of 1024 at 314564608: Invalid argument
>>   /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
>>
>> In case the filesystem of the logical volume is not mounted at the time of pvmove, it gets corrupted anyway, but you only see errors when trying to mount it.
>>
>> -- 
>> Ingo Franzki
>> eMail: ifranzki@linux.ibm.com  
>> Tel: ++49 (0)7031-16-4648
>> Fax: ++49 (0)7031-16-3456
>> Linux on IBM Z Development, Schoenaicher Str. 220, 71032 Boeblingen, Germany
>>
>> IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: Matthias Hartmann
>> Geschäftsführung: Dirk Wittkopp
>> Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
>> IBM DATA Privacy Statement: https://www.ibm.com/privacy/us/en/
>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> https://www.saout.de/mailman/listinfo/dm-crypt
> 


-- 
Ingo Franzki
eMail: ifranzki@linux.ibm.com  
Tel: ++49 (0)7031-16-4648
Fax: ++49 (0)7031-16-3456
Linux on IBM Z Development, Schoenaicher Str. 220, 71032 Boeblingen, Germany

IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: Matthias Hartmann
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM DATA Privacy Statement: https://www.ibm.com/privacy/us/en/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dm-crypt] Filesystem corruption with LVM's pvmove onto an encrypted volume with LUKS2 and a sector size of 4096
  2019-02-21 12:03 [dm-crypt] Filesystem corruption with LVM's pvmove onto an encrypted volume with LUKS2 and a sector size of 4096 Ingo Franzki
  2019-02-21 13:02 ` Arno Wagner
@ 2019-02-21 14:04 ` Ondrej Kozina
  2019-02-21 15:45   ` Ingo Franzki
  1 sibling, 1 reply; 6+ messages in thread
From: Ondrej Kozina @ 2019-02-21 14:04 UTC (permalink / raw)
  To: dm-crypt; +Cc: Ingo Franzki

Hi Ingo,

On 2/21/19 1:03 PM, Ingo Franzki wrote:
> Hi,
> 
> 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.
> After the pvmove has completed, the file system on the logical volume that resides on the moved physical volumes is corrupted.
> 
> It seems to be related to a sector size of 4096 used with LUKS2. Once I use 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 4096 is used. LUKS1 and the default sector size does not show the problem.
> 
> Not sure if this is a problem in dm-crypt or LVM, or a combination of both.

tldr; dm-crypt with encryption sector size set to 4096 may increase 
device limits to 4096 bytes (minimal i/o size and i/o alignment). It can 
corrupt filesystem originally created on top of 512B device and moved 
over to dm-crypt with increased encryption sector size (which you 
probably did with pvmove).

-----

You're right it's due to encryption sector size, but this is not a bug 
in dm-crypt nor in pvmove. Let me explain a bit:

dm-crypt advertise itself as a block device with physical sector size 
*at least* equal to encryption sector size. Traditionally it's been only 
512B. So classical dm-crypt mapped over device with phys. sector size = 
512B has no impact. If you mapped dm-crypt over block device with native 
physical sector size = 4096 you got dm-crypt exposing same limits as 
underlying block device. Again no problem. Just internally dm-crypt 
performed encryption on 512B blocks, but it had no impact on exposed limits.

But things get a bit different with encryption sector size > 512B.

If you map dm-crypt with encryption sector size set to 4096B over block 
device with physical sector size = 512B, dm-crypt must increase device 
limits to 4096. Because when it does encryption it must be aligned to 
4096 bytes (and same wrt minimal i/o size).

So to conclude it:

If you create dm-crypt with 4K enc. sector over *native* 4K block device 
it's ok and it must work everytime.

If you create dm-crypt with 4K enc. sector over 4K block device with 
512B emulation, you're ok to create new fs (only new!) on top of it.

Moving existing filesystem is always a bit tricky. You need to know with 
what limits the original fs was created. For example on those 4096/512e 
drives (emulating 512B), fs may have aligned its structures either to 
4096B or 512B during mkfs. For example ext4 does the decision based on 
device size (hope I recall it correctly).

Just a remark: with LVM2 you may get to similar problems using only 
lvextend command where you (even accidentally) mix PVs on 512B drives 
with 4K native drives (latest example: 
https://bugzilla.redhat.com/show_bug.cgi?id=1669751)

(We desperately need to start publishing blog posts related to these 
issues...sigh)

Kind regards
O.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dm-crypt] Filesystem corruption with LVM's pvmove onto an encrypted volume with LUKS2 and a sector size of 4096
  2019-02-21 14:04 ` Ondrej Kozina
@ 2019-02-21 15:45   ` Ingo Franzki
  2019-02-21 17:21     ` Arno Wagner
  0 siblings, 1 reply; 6+ messages in thread
From: Ingo Franzki @ 2019-02-21 15:45 UTC (permalink / raw)
  To: Ondrej Kozina, dm-crypt

On 21.02.2019 15:04, Ondrej Kozina wrote:
> Hi Ingo,
> 
> On 2/21/19 1:03 PM, Ingo Franzki wrote:
>> Hi,
>>
>> 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.
>> After the pvmove has completed, the file system on the logical volume that resides on the moved physical volumes is corrupted.
>>
>> It seems to be related to a sector size of 4096 used with LUKS2. Once I use 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 4096 is used. LUKS1 and the default sector size does not show the problem.
>>
>> Not sure if this is a problem in dm-crypt or LVM, or a combination of both.
> 
> tldr; dm-crypt with encryption sector size set to 4096 may increase device limits to 4096 bytes (minimal i/o size and i/o alignment). It can corrupt filesystem originally created on top of 512B device and moved over to dm-crypt with increased encryption sector size (which you probably did with pvmove).
> 
> -----
> 
> You're right it's due to encryption sector size, but this is not a bug in dm-crypt nor in pvmove. Let me explain a bit:
> 
> dm-crypt advertise itself as a block device with physical sector size *at least* equal to encryption sector size. Traditionally it's been only 512B. So classical dm-crypt mapped over device with phys. sector size = 512B has no impact. If you mapped dm-crypt over block device with native physical sector size = 4096 you got dm-crypt exposing same limits as underlying block device. Again no problem. Just internally dm-crypt performed encryption on 512B blocks, but it had no impact on exposed limits.
> 
> But things get a bit different with encryption sector size > 512B.
> 
> If you map dm-crypt with encryption sector size set to 4096B over block device with physical sector size = 512B, dm-crypt must increase device limits to 4096. Because when it does encryption it must be aligned to 4096 bytes (and same wrt minimal i/o size).
> 
> So to conclude it:
> 
> If you create dm-crypt with 4K enc. sector over *native* 4K block device it's ok and it must work everytime.
> 
> If you create dm-crypt with 4K enc. sector over 4K block device with 512B emulation, you're ok to create new fs (only new!) on top of it.
> 
> Moving existing filesystem is always a bit tricky. You need to know with what limits the original fs was created. For example on those 4096/512e drives (emulating 512B), fs may have aligned its structures either to 4096B or 512B during mkfs. For example ext4 does the decision based on device size (hope I recall it correctly).

I now understand the technical reasons for the behavior, but I still think that this can't be 'works as designed'.
You can easily destroy the filesystem and thus loose all your data on your logical volume, without a chance to notice upfront!

I really would expect pvmove to issue an error and reject the move when it is about to move between devices with different block sizes, to avoid FS corruption and data loss. At least it should reject the move when it detects that the moved LVs have file systems on it (I assume LVM already knows about this anyway). There probably should be an option to force the move anyway, that I can use when I know what I am doing.
But the default behavior can not lead to data loss. 

> 
> Just a remark: with LVM2 you may get to similar problems using only lvextend command where you (even accidentally) mix PVs on 512B drives with 4K native drives (latest example: https://bugzilla.redhat.com/show_bug.cgi?id=1669751)

Or reject to add PVs with different block sizes at vgextend time already, as mentioned in the bugzilla you mentioned.

Either way, it needs to be prevented that using mixed block size PVs lead to data loss! 
> 
> (We desperately need to start publishing blog posts related to these issues...sigh)
> 
> Kind regards
> O.
> 
> 


-- 
Ingo Franzki
eMail: ifranzki@linux.ibm.com  
Tel: ++49 (0)7031-16-4648
Fax: ++49 (0)7031-16-3456
Linux on IBM Z Development, Schoenaicher Str. 220, 71032 Boeblingen, Germany

IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: Matthias Hartmann
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM DATA Privacy Statement: https://www.ibm.com/privacy/us/en/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [dm-crypt] Filesystem corruption with LVM's pvmove onto an encrypted volume with LUKS2 and a sector size of 4096
  2019-02-21 15:45   ` Ingo Franzki
@ 2019-02-21 17:21     ` Arno Wagner
  0 siblings, 0 replies; 6+ messages in thread
From: Arno Wagner @ 2019-02-21 17:21 UTC (permalink / raw)
  To: dm-crypt

On Thu, Feb 21, 2019 at 16:45:43 CET, Ingo Franzki wrote:
> I now understand the technical reasons for the behavior, but I still think
> that this can't be 'works as designed'.  You can easily destroy the
> filesystem and thus loose all your data on your logical volume, without a
> chance to notice upfront!

For that let me refer you to FAQ Item 6.1
If you lose all your data, the problem is somewhere else.
In particular you should _never_ move partitions around without backup. 

Regards,
Arno

-- 
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 
"news" is "something that hardly ever happens." -- Bruce Schneier

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2019-02-21 17:21 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-21 12:03 [dm-crypt] Filesystem corruption with LVM's pvmove onto an encrypted volume with LUKS2 and a sector size of 4096 Ingo Franzki
2019-02-21 13:02 ` Arno Wagner
2019-02-21 13:33   ` Ingo Franzki
2019-02-21 14:04 ` Ondrej Kozina
2019-02-21 15:45   ` Ingo Franzki
2019-02-21 17:21     ` Arno Wagner

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.