Re: Filesystem corruption with LVM's pvmove onto a PV with a larger physical block size

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
Thank you.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
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/

[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux