Hello,

&n= bsp;

I think the filesystems address in Logic= al blocks, so this is the size which should match.

However the physical size might b= e relevant for alignment/sizing decisions of mkfs =C2=A0(but you would expe= ct the to be encoded in the metadata of the filesystem so you can transport= them (losing proper alignment which might affect Performance or robustness= ).

For ex= t3/4 I think the mkfs will use -b 4k by Default if your FS is at least 0,5G= B.

BTW: s= ome applications (like SQL Server) also care about the physical size to mak= e sure they always write complete sectors in transactions and avoid read-mo= dify-write scenarios.

Gru= ss

Bernd

--
http://bern= d.eckenfels.net

Von: Cesare LeonardiGesendet: Freitag, 1. M=C3=A4rz 2019 02:24
An: Ingo Franzki; LVM general discussion and development
Betreff: Re: [linux-lvm] Filesystem corruption with LVM's pvmove onto a PVwith a l= arger physical block size

On 28/02/19 09:41, Ingo Franzki wrote:

> Well, there are the following 2 commands:

> Get physical block size:

>=C2=A0=C2=A0 blockdev --getpbsz <device>

> Get logical block size:

>= =C2=A0=C2=A0 blockdev --getbsz <device>

I didn't know the blockdev command and= , to recap, we have:

--getpbsz: physical sector siz= e

--getss: logical sector size

--getbsz: blocksize used internally by the kernel

getpbsz/getss correspond to ph= ysical/logical sector size reported by

fdisk, smar= tctl, etc.

> Filesystems seem to care about the physical block size only, not the= logical block size.

= > So as soon as you have PVs with different physical block sizes (as rep= orted by blockdev --getpbsz) I would be very careful...

I've done the test suggested= by Stuart and it seems to contradict this.

I have = pvmoved data from a 512/512 (logical/physical) disk to a newly

added 512/4096 disk but I had no data corruption. Unfortunatel= y I

haven't any native 4k disk to repeat the same = test.

Her= e is what I've done.

/dev/sdb: SSD with 512/512 sec= tor size

/dev/sdc: mechanical disk with 512/4096 se= ctor size

# blockdev -v --getss --getpbsz --getbsz /dev/sdb

= get logical block (sector) size: 512

get physical b= lock (sector) size: 512

get blocksize: 4096

# blockdev -v --= getss --getpbsz --getbsz /dev/sdc

get logical block= (sector) size: 512

get physical block (sector) siz= e: 4096

get blocksize: 4096

# pvcreate /dev/sdb4

# vgcreate vgtest /dev/sdb4

# lvcreate= -L 1G vgtest /dev/sdb4

# mkfs.ext4 /dev/mapper/vgt= est-lvol0

# mkdir /media/test

# mount /dev/mapper/vgtest-lvol0 /media/test

# c= p -a SOMEDATA /media/test/

# umount /media/test

=
# fsck.ext4 -f /dev/mapper/vgtest-lvol0

Filesystem created and = no error on it. Now the disk with different
physic= al size:

= # pvcreate /dev/sdc1
# vgextend vgtest /dev/sdc1
# pvmove /dev/sdb4 /dev/sdc1
= # fsck.ext4 -f /dev/mapper/vgtest-lvol0
# mount /de= v/mapper/vgtest-lvol0 /media/test
# ls /media/test/=

The fsck= command reports no errors, the filesystem is mountable and the
data is there.

<= p class=3DMsoNormal>Looks like physical sector size didn't matter here. Or = I'm missing
something?

Cesare.

_____________________________________= __________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/= mailman/listinfo/linux-lvm
read the LVM HOW-TO at h= ttp://tldp.org/HOWTO/LVM-HOWTO/