From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com (ext-mx01.extmail.prod.ext.phx2.redhat.com [10.5.110.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B35AD1001DCE for ; Mon, 4 Mar 2019 23:22:52 +0000 (UTC) Received: from mail-vk1-f199.google.com (mail-vk1-f199.google.com [209.85.221.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C831881DEC for ; Mon, 4 Mar 2019 23:22:51 +0000 (UTC) Received: by mail-vk1-f199.google.com with SMTP id f142so4285273vkd.18 for ; Mon, 04 Mar 2019 15:22:51 -0800 (PST) MIME-Version: 1.0 References: <253b63e7-e23b-9a0a-d677-a114c00a5134@linux.ibm.com> <2c295ce3-2766-ba41-4bba-575c799b3d46@gmail.com> <443f1e98-1dec-17e5-f38d-cbbd52cd541c@linux.ibm.com> <11dcbee0-ec65-d5d2-b07c-9937b99cc5b4@linux.ibm.com> <30346b34-c1e1-f7ba-be4e-a37d8ce8cf03@gmail.com> <840f278d-fc42-a2ea-03b2-cea5f32b4837@gmail.com> In-Reply-To: <840f278d-fc42-a2ea-03b2-cea5f32b4837@gmail.com> From: Nir Soffer Date: Tue, 5 Mar 2019 01:22:39 +0200 Message-ID: Content-Type: multipart/alternative; boundary="00000000000003faf805834d0916" Subject: Re: [linux-lvm] Filesystem corruption with LVM's pvmove onto a PV with a larger physical block size Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: To: Cesare Leonardi Cc: Ingo Franzki , David Teigland , LVM general discussion and development --00000000000003faf805834d0916 Content-Type: text/plain; charset="UTF-8" On Tue, Mar 5, 2019 at 12:45 AM Cesare Leonardi wrote: > On 02/03/19 21:25, Nir Soffer wrote: > > # mkfs.xfs /dev/test/lv1 > > meta-data=/dev/test/lv1 isize=512 agcount=4, agsize=25600 > blks > > = sectsz=512 attr=2, projid32bit=1 > > = crc=1 finobt=1, sparse=0, > > rmapbt=0, reflink=0 > > data = bsize=4096 blocks=102400, imaxpct=25 > > = sunit=0 swidth=0 blks > > naming =version 2 bsize=4096 ascii-ci=0 ftype=1 > > log =internal log bsize=4096 blocks=855, version=2 > > = sectsz=512 sunit=0 blks, lazy-count=1 > > realtime =none extsz=4096 blocks=0, rtextents=0 > > Has the problem here the same root as for ext4? I guess sectsz should be > >=4096 to avoid troubles, isn't it? > > Just to draw some conlusion, could we say that currently, if we are > going to move data around with LVM, it's better to check that the > filesystem is using a block size >= than "blockdev --getbsz > DESTINATIONDEVICE"? At least with ext4 and xfs. > > Something that couldn't be true with really small devices (< 500 MB). > > Is there already an open bug regarding the problem discussed in this > thread? > There is this bug about lvextend: https://bugzilla.redhat.com/1669751 And this old bug from 2011, discussing mixing PVs with different block size. Comment 2 is very clear about this issue: https://bugzilla.redhat.com/732980#c2 Nir --00000000000003faf805834d0916 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Mar 5, 2019 at 12:45 AM = Cesare Leonardi <celeonar@gmail.com> wrote:
On 02/03/19 21:2= 5, Nir Soffer wrote:
> # mkfs.xfs /dev/test/lv1
> meta-data=3D/dev/test/lv1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 isize=3D51= 2=C2=A0 =C2=A0 agcount=3D4, agsize=3D25600 blks
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sectsz=3D512=C2=A0 = =C2=A0attr=3D2, projid32bit=3D1
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0crc=3D1=C2=A0 =C2= =A0 =C2=A0 =C2=A0 finobt=3D1, sparse=3D0,
> rmapbt=3D0, reflink=3D0
> data=C2=A0 =C2=A0 =C2=A0=3D=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bsize=3D4096=C2=A0 =C2=A0blocks=3D= 102400, imaxpct=3D25
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sunit=3D0=C2=A0 =C2= =A0 =C2=A0 swidth=3D0 blks
> naming=C2=A0 =C2=A0=3Dversion 2=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 bsize=3D4096=C2=A0 =C2=A0ascii-ci=3D0 ftype=3D1
> log=C2=A0 =C2=A0 =C2=A0 =3Dinternal log=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0bsize=3D4096=C2=A0 =C2=A0blocks=3D855, version=3D2
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sectsz=3D512=C2=A0 = =C2=A0sunit=3D0 blks, lazy-count=3D1
> realtime =3Dnone=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0extsz=3D4096=C2=A0 =C2=A0blocks=3D0, rtextents=3D0

Has the problem here the same root as for ext4? I guess sectsz should be =C2=A0>=3D4096 to avoid troubles, isn't it?

Just to draw some conlusion, could we say that currently, if we are
going to move data around with LVM, it's better to check that the
filesystem is using a block size >=3D than "blockdev --getbsz
DESTINATIONDEVICE"? At least with ext4 and xfs.

Something that couldn't be true with really small devices (< 500 MB)= .

Is there already an open bug regarding the problem discussed in this thread= ?

There is this bug about lvextend:
<= div class=3D"gmail_default" style=3D"font-size:small;color:rgb(0,0,0)">https://bugzi= lla.redhat.com/1669751

And this old bug from 2011, discussin= g mixing PVs with different block size.
Comment 2 is very clear about thi= s issue:
https://bugzilla.redhat.com/7= 32980#c2

Nir
<= /div>
--00000000000003faf805834d0916--