From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com (ext-mx10.extmail.prod.ext.phx2.redhat.com [10.5.110.39]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3472D60C1B for ; Tue, 5 Mar 2019 16:29:45 +0000 (UTC) Received: from mail-vs1-f71.google.com (mail-vs1-f71.google.com [209.85.217.71]) (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 0947759452 for ; Tue, 5 Mar 2019 16:29:45 +0000 (UTC) Received: by mail-vs1-f71.google.com with SMTP id g72so163660vsd.18 for ; Tue, 05 Mar 2019 08:29:45 -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> <1576db4f-1d7c-6894-d9b0-69c51852b11c@linux.ibm.com> <325bbb01-1b67-eafb-025e-4bfde1b16b54@gmail.com> <328b148e-61ff-1099-5362-3e799407580c@linux.ibm.com> <80ee50b6-4d44-90d1-b38e-4072ebbc7cbf@izyk.ru> In-Reply-To: <80ee50b6-4d44-90d1-b38e-4072ebbc7cbf@izyk.ru> From: Nir Soffer Date: Tue, 5 Mar 2019 18:29:31 +0200 Message-ID: Content-Type: multipart/alternative; boundary="00000000000074abce05835b61d8" 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: LVM general discussion and development Cc: Ingo Franzki , David Teigland --00000000000074abce05835b61d8 Content-Type: text/plain; charset="UTF-8" On Tue, Mar 5, 2019 at 11:30 AM Ilia Zykov wrote: > Hello. > > >> THAT is a crucial observation. It's not an LVM bug, but the filesystem > >> trying to read 1024 bytes on a 4096 device. > > Yes that's probably the reason. Nevertheless, its not really the FS's > fault, since it was moved by LVM to a 4069 device. > > The FS does not know anything about the move, so it reads in the block > size it was created with (1024 in this case). > > > > I still think LVM should prevent one from mixing devices with different > physical block sizes, or at least warn when pvmoving or lvextending onto a > PV with a larger block size, since this can cause trouble. > > > > In this case, "dd" tool and others should prevent too. > > Because after: > > dd if=/dev/DiskWith512block bs=4096 of=/dev/DiskWith4Kblock > > You couldn't mount the "/dev/DiskWith4Kblock" with the same error ;) > /dev/DiskWith512block has ext4 fs with 1k block. > > P.S. > LVM,dd .. are low level tools and doesn't know about hi level anything. > And in the your case and others cases can't know. You should test(if you > need) the block size with other tools before moving or copying. > Not a lvm bug. > I don't this way of thinking is useful. If we go in this way, then write() should not let you write data, and later maybe the disk controller should avoid this? LVM is not a low level tool like dd. It is high level tool for managing device mapper, and providing high level tools to create user level abstractions. We can expect it to prevent system administrator from doing the wrong thing. Maybe LVM should let you mix PVs with different logical block size, but it should require --force. David, what do you think? --00000000000074abce05835b61d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Mar= 5, 2019 at 11:30 AM Ilia Zykov <mail@iz= yk.ru> wrote:
Hello.

>> THAT is a crucial observation.=C2=A0 It's not an LVM bug, but = the filesystem
>> trying to read 1024 bytes on a 4096 device.=C2=A0
> Yes that's probably the reason. Nevertheless, its not really the F= S's fault, since it was moved by LVM to a 4069 device.
> The FS does not know anything about the move, so it reads in the block= size it was created with (1024 in this case).
>
> I still think LVM should prevent one from mixing devices with differen= t physical block sizes, or at least warn when pvmoving or lvextending onto = a PV with a larger block size, since this can cause trouble.
>

In this case, "dd" tool and others should prevent too.

Because after:

dd if=3D/dev/DiskWith512block bs=3D4096 of=3D/dev/DiskWith4Kblock

You couldn't mount the "/dev/DiskWith4Kblock" with the same e= rror ;)
/dev/DiskWith512block has ext4 fs with 1k block.

P.S.
LVM,dd .. are low level tools and doesn't know about hi level anything.=
And in the your case and others cases can't know. You should test(if yo= u
need) the block size with other tools before moving or copying.
Not a lvm bug.

I don't this way of thi= nking is useful. If we go in this way, then write() should not
let you wr= ite data, and later maybe the disk controller should avoid this?

L= VM is not a low level tool like dd. It is high level tool for managing devi= ce mapper,
and providing high level tools to create user level abstractio= ns. We can expect it
to prevent system administrator from doing the wrong= thing.

Maybe LVM should let you mix PVs with different logical bl= ock size, but it should
require --force.

David, what do yo= u think?
--00000000000074abce05835b61d8--