From: Ingo Franzki <ifranzki@linux.ibm.com>
To: Cesare Leonardi <celeonar@gmail.com>,
LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Filesystem corruption with LVM's pvmove onto a PV with a larger physical block size
Date: Wed, 27 Feb 2019 09:49:35 +0100 [thread overview]
Message-ID: <443f1e98-1dec-17e5-f38d-cbbd52cd541c@linux.ibm.com> (raw)
In-Reply-To: <2c295ce3-2766-ba41-4bba-575c799b3d46@gmail.com>
On 27.02.2019 01:00, Cesare Leonardi wrote:
> On 25/02/19 16:33, Ingo Franzki wrote:
>> 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 and all data on this LV is lost.
>
> Hello, your message is interesting. And also this thread:
> https://www.redhat.com/archives/linux-lvm/2019-February/msg00002.html
>
> But I'd like to know if I understood correctly.
> Should I care about the physical disk size when I use LVM? Mixing disk with different sector size (512b and 4k) is dangerous?
As far as I can tell: Yes if you pvmove data around or lvextend an LV onto another PV with a larger physical block size that is dangerous.
Creating new LVs and thus new file systems on mixed configurations seem to be OK.
>
> Your message and others from the other thread, seems to say that LVM doesn't handle correctly that situation and that if I pvmove data between a 512b disk and a 4k disk (or viceversa), it will lead to a massive filesystem corruption. If I understood correctly, the problem that you described looks unrelated to encrypted volume and was only exacerbated by that. Right?
Moving from 512 to 4096 seems to cause FS corruption, moving from 4096 to 512 does not. So I guess its only a problem when moving to larger physical block sizes.
And yes, its unrelated to encrypted volumes, it can happen with any block device of different physical block sizes that you use as PV.
E.g. SCSI disks exist in 512 bytes block size and 4096 bytes block size. Or s390-DASDs which always have 4096 bytes blocks.
We just encountered it using encrypted disks with the sector-size option to increase encryption performance.
So actually we want people to use larger sector sizes, but this seems to cause problems with LVM.
The good thing about the example with encrypted volumes on loopback devices is that you can reproduce the problem on any platform, without having certain hardware requirements.
>
> Cesare.
>
>
--
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/
next prev parent reply other threads:[~2019-02-27 8:49 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-25 15:33 [linux-lvm] Filesystem corruption with LVM's pvmove onto a PV with a larger physical block size Ingo Franzki
2019-02-27 0:00 ` Cesare Leonardi
2019-02-27 8:49 ` Ingo Franzki [this message]
2019-02-27 14:59 ` Stuart D. Gathman
2019-02-27 17:05 ` Ingo Franzki
2019-03-02 1:37 ` L A Walsh
2019-02-28 1:31 ` Cesare Leonardi
2019-02-28 1:52 ` Stuart D. Gathman
2019-02-28 8:41 ` Ingo Franzki
2019-02-28 9:48 ` Ilia Zykov
2019-02-28 10:10 ` Ingo Franzki
2019-02-28 10:41 ` Ilia Zykov
2019-02-28 10:50 ` Ilia Zykov
2019-02-28 13:13 ` Ilia Zykov
2019-03-01 1:24 ` Cesare Leonardi
2019-03-01 2:56 ` [linux-lvm] Filesystem corruption with LVM's pvmove onto a PVwith " Bernd Eckenfels
2019-03-01 8:00 ` Ingo Franzki
2019-03-01 3:41 ` [linux-lvm] Filesystem corruption with LVM's pvmove onto a PV with " Stuart D. Gathman
2019-03-01 7:59 ` Ingo Franzki
2019-03-01 8:05 ` Ingo Franzki
2019-03-02 1:36 ` Cesare Leonardi
2019-03-02 20:25 ` Nir Soffer
2019-03-04 22:45 ` Cesare Leonardi
2019-03-04 23:22 ` Nir Soffer
2019-03-05 7:54 ` Ingo Franzki
2019-03-04 9:12 ` Ingo Franzki
2019-03-04 22:10 ` Cesare Leonardi
2019-03-05 0:12 ` Stuart D. Gathman
2019-03-05 7:53 ` Ingo Franzki
2019-03-05 9:29 ` Ilia Zykov
2019-03-05 11:42 ` Ingo Franzki
2019-03-05 16:29 ` Nir Soffer
2019-03-05 16:36 ` David Teigland
2019-03-05 16:56 ` Stuart D. Gathman
2019-02-28 14:36 ` Ilia Zykov
2019-02-28 16:30 ` Ingo Franzki
2019-02-28 18:11 ` Ilia Zykov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=443f1e98-1dec-17e5-f38d-cbbd52cd541c@linux.ibm.com \
--to=ifranzki@linux.ibm.com \
--cc=celeonar@gmail.com \
--cc=linux-lvm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).