Re: [Question] qemu-img convert block alignment
On 2021/8/3 23:03, Eric Blake wrote: > On Fri, Apr 02, 2021 at 11:52:25AM +0800, Zhenyu Ye wrote: >> Hi all, >> >> commit 8dcd3c9b91 ("qemu-img: align result of is_allocated_sectors") >> introduces block alignment when doing qemu-img convert. However, the >> alignment is: >> >> s.alignment = MAX(pow2floor(s.min_sparse), >> DIV_ROUND_UP(out_bs->bl.request_alignment, >>BDRV_SECTOR_SIZE)); >> >> (where the default s.min_sparse is 8) >> When the target device's bl.request_alignment is smaller than 4K, this >> will cause additional write-zero overhead and makes the size of target >> file larger. >> >> Is this as expected? Should we change the MAX() to MIN()? > > Yes it is expected, and no we shouldn't change it. Even when a target > advertises a bl.request_alignment of 512, our goal is to avoid needing > read-modify-write cycles when that target is really on top of a 4k > sector disk. Writing extra 0s out to the 4k boundaries does not > change the fact that allocation is in 4k chunks anyways, regardless of > whether the disk supports smaller 512-byte reads. > Thanks for your reply. Zhenyu
Re: [Question] qemu-img convert block alignment
On Fri, Apr 02, 2021 at 11:52:25AM +0800, Zhenyu Ye wrote: > Hi all, > > commit 8dcd3c9b91 ("qemu-img: align result of is_allocated_sectors") > introduces block alignment when doing qemu-img convert. However, the > alignment is: > > s.alignment = MAX(pow2floor(s.min_sparse), > DIV_ROUND_UP(out_bs->bl.request_alignment, >BDRV_SECTOR_SIZE)); > > (where the default s.min_sparse is 8) > When the target device's bl.request_alignment is smaller than 4K, this > will cause additional write-zero overhead and makes the size of target > file larger. > > Is this as expected? Should we change the MAX() to MIN()? Yes it is expected, and no we shouldn't change it. Even when a target advertises a bl.request_alignment of 512, our goal is to avoid needing read-modify-write cycles when that target is really on top of a 4k sector disk. Writing extra 0s out to the 4k boundaries does not change the fact that allocation is in 4k chunks anyways, regardless of whether the disk supports smaller 512-byte reads. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: [Question] qemu-img convert block alignment
ping? On 2021/4/2 11:52, Zhenyu Ye wrote: > Hi all, > > commit 8dcd3c9b91 ("qemu-img: align result of is_allocated_sectors") > introduces block alignment when doing qemu-img convert. However, the > alignment is: > > s.alignment = MAX(pow2floor(s.min_sparse), > DIV_ROUND_UP(out_bs->bl.request_alignment, >BDRV_SECTOR_SIZE)); > > (where the default s.min_sparse is 8) > When the target device's bl.request_alignment is smaller than 4K, this > will cause additional write-zero overhead and makes the size of target > file larger. > > Is this as expected? Should we change the MAX() to MIN()? > > > Thanks, > zhenyu >
[Question] qemu-img convert block alignment
Hi all, commit 8dcd3c9b91 ("qemu-img: align result of is_allocated_sectors") introduces block alignment when doing qemu-img convert. However, the alignment is: s.alignment = MAX(pow2floor(s.min_sparse), DIV_ROUND_UP(out_bs->bl.request_alignment, BDRV_SECTOR_SIZE)); (where the default s.min_sparse is 8) When the target device's bl.request_alignment is smaller than 4K, this will cause additional write-zero overhead and makes the size of target file larger. Is this as expected? Should we change the MAX() to MIN()? Thanks, zhenyu