On 02.03.2019 02:36, Cesare Leonardi wrote: > Hello Ingo, I've made several tests but I was unable to trigger any filesystem corruption. Maybe the trouble you encountered are specific to encrypted device? > > Yesterday and today I've used: > Debian unstable > kernel 4.19.20 > lvm2 2.03.02 > e2fsprogs 1.44.5 > > On 01/03/19 09:05, Ingo Franzki wrote: >> Hmm, maybe the size of the volume plays a role as Bernd has pointed out. ext4 may use -b 4K by default on larger devices. >> Once the FS uses 4K block anyway you wont see the problem. >> >> Use tune2fs -l <device> after you created the file system and check if it is using 4K blocks on your 512/512 device. If so, then you won't see the problem when moved to a 4K block size device. > > I confirm that tune2fs reports 4096 block size for the 1 GB ext4 filesystem I've used. > I've also verified what Bernd said: mkfs.ext4 still use 4096 block size for a +512M partition, but use 1024 for +500M. > > As suggested by Stuart, I also made a test using a 4k loop device and pvmoving the LV into it. As you expected, no data corruption. > To do it I've recreated the same setup ad yesterday: /dev/mapper/vgtest-lvol0 on /dev/sdb4, a 512/512 disk, with some data on it. Then: > # fallocate -l 10G testdisk.img > # losetup -f -L -P -b 4096 testdisk.img > # pvcreate /dev/loop0 > # vgextend vgtest /dev/loop0 > # pvmove /dev/sdb4 /dev/loop0 > # fsck.ext4 -f /dev/mapper/vgtest-lvol0 > > While I was there, out of curiosity, I've created an ext4 filesystem on a <500MB LV (block size = 1024) and I've tried pvmoving data from the 512/512 disk to 512/4096, then to the 4096/4096 loop device. > New partitions and a new VG was used for that. > > The setup: > /dev/sdb5: 512/512 > /dev/sdc2: 512/4096 > /dev/loop0 4096/4096 > > # blockdev -v --getss --getpbsz --getbsz /dev/sdb > get logical block (sector) size: 512 > get physical block (sector) size: 512 > get blocksize: 4096 You display the physical block size of /dev/sdb here, but you use /dev/sdb5 later on. Not sure if this makes a difference .... > > # blockdev -v --getss --getpbsz --getbsz /dev/sdc > get logical block (sector) size: 512 > get physical block (sector) size: 4096 > get blocksize: 4096 Again, you display the physical block size of /dev/sdc here, but you use /dev/sdc2 later on. > > # blockdev -v --getss --getpbsz --getbsz /dev/loop0 > get logical block (sector) size: 4096 > get physical block (sector) size: 4096 > get blocksize: 4096 > > # pvcreate /dev/sdb5 > # vgcreate vgtest2 /dev/sdb5 > # lvcreate -L 400M vgtest2 /dev/sdb5 > # mkfs.ext4 /dev/mapper/vgtest2-lvol0 > > # tune2fs -l /dev/mapper/vgtest2-lvol0 > [...] > Block size: 1024 > [...] > > # mount /dev/mapper/vgtest2-lvol0 /media/test > # cp -a SOMEDATA /media/test/ > # umount /media/test > # fsck.ext4 -f /dev/mapper/vgtest2-lvol0 > > Now I've moved data from the 512/512 to the 512/4096 disk: > # pvcreate /dev/sdc2 > # vgextend vgtest2 /dev/sdc2 > # pvmove /dev/sdb5 /dev/sdc2 > # fsck.ext4 -f /dev/mapper/vgtest2-lvol0 Please note that fsck.ext4 does not seem to detect this kind of corruption. In my case fsck.ext4 reported that the FS would be clean (!), but a mount count not mount it anymore... Do a 'pvs' command here, this should show some error messages. > > No error reported. > Now I've moved data to the 4096/4096 loop device: > # pvcreate /dev/loop0 > # vgextend vgtest2 /dev/loop0 > # pvmove /dev/sdc2 /dev/loop0 > # fsck.ext4 -f /dev/mapper/vgtest2-lvol0 Again, fsck did not show the corruption for me, but pvs did show error messages. > > Still no data corruption. > > Cesare. > > _______________________________________________ > linux-lvm mailing list > linux-lvm@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-lvm > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ > > -- Ingo Franzki eMail: ifranzki@xxxxxxxxxxxxx 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/ _______________________________________________ linux-lvm mailing list linux-lvm@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
