On Tue, Mar 5, 2019 at 12:45 AM Cesare Leonardi <[email protected]> wrote:
> On 02/03/19 21:25, Nir Soffer wrote: > > # mkfs.xfs /dev/test/lv1 > > meta-data=/dev/test/lv1 isize=512 agcount=4, agsize=25600 > blks > > = sectsz=512 attr=2, projid32bit=1 > > = crc=1 finobt=1, sparse=0, > > rmapbt=0, reflink=0 > > data = bsize=4096 blocks=102400, imaxpct=25 > > = sunit=0 swidth=0 blks > > naming =version 2 bsize=4096 ascii-ci=0 ftype=1 > > log =internal log bsize=4096 blocks=855, version=2 > > = sectsz=512 sunit=0 blks, lazy-count=1 > > realtime =none extsz=4096 blocks=0, rtextents=0 > > Has the problem here the same root as for ext4? I guess sectsz should be > >=4096 to avoid troubles, isn't it? > > Just to draw some conlusion, could we say that currently, if we are > going to move data around with LVM, it's better to check that the > filesystem is using a block size >= than "blockdev --getbsz > DESTINATIONDEVICE"? At least with ext4 and xfs. > > Something that couldn't be true with really small devices (< 500 MB). > > Is there already an open bug regarding the problem discussed in this > thread? > There is this bug about lvextend: https://bugzilla.redhat.com/1669751 And this old bug from 2011, discussing mixing PVs with different block size. Comment 2 is very clear about this issue: https://bugzilla.redhat.com/732980#c2 Nir
_______________________________________________ linux-lvm mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
