[linux-lvm] Filesystem corruption with LVM's pvmove onto a PVwith a larger physical block size

[Bernd Eckenfels]

Hello,

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

However the physical size might be relevant for alignment/sizing decisions of mkfs  (but you would expect 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 ext3/4 I think the mkfs will use -b 4k by Default if your FS is at least 0,5GB.

BTW: some applications (like SQL Server) also care about the physical size to make sure they always write complete sectors in transactions and avoid read-modify-write scenarios.
 
Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Cesare Leonardi
Gesendet: Freitag, 1. März 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 larger physical block size

On 28/02/19 09:41, Ingo Franzki wrote:
> Well, there are the following 2 commands:
> 
> Get physical block size:
>   blockdev --getpbsz <device>
> Get logical block size:
>   blockdev --getbsz <device>

I didn't know the blockdev command and, to recap, we have:
--getpbsz: physical sector size
--getss: logical sector size
--getbsz: blocksize used internally by the kernel

getpbsz/getss correspond to physical/logical sector size reported by 
fdisk, smartctl, 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 reported 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. Unfortunately I 
haven't any native 4k disk to repeat the same test.

Here is what I've done.
/dev/sdb: SSD with 512/512 sector size
/dev/sdc: mechanical disk with 512/4096 sector size

# blockdev -v --getss --getpbsz --getbsz /dev/sdb
get logical block (sector) size: 512
get physical block (sector) size: 512
get blocksize: 4096

# blockdev -v --getss --getpbsz --getbsz /dev/sdc
get logical block (sector) size: 512
get physical block (sector) size: 4096
get blocksize: 4096

# pvcreate /dev/sdb4
# vgcreate vgtest /dev/sdb4
# lvcreate -L 1G vgtest /dev/sdb4
# mkfs.ext4 /dev/mapper/vgtest-lvol0
# mkdir /media/test
# mount /dev/mapper/vgtest-lvol0 /media/test
# cp -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 
physical size:

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

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

Looks like physical sector size didn't matter here. Or I'm missing 
something?

Cesare.

_______________________________________________
linux-lvm mailing list
linux-lvm at redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20190301/b6eeb04c/attachment.htm>