All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Zhenyu Ye <yezhenyu2@huawei.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	pl@kamp.de, qemu-devel@nongnu.org, qemu-block@nongnu.org,
	mreitz@redhat.com
Subject: Re: [Question] qemu-img convert block alignment
Date: Tue, 3 Aug 2021 10:03:16 -0500	[thread overview]
Message-ID: <20210803150316.eo5gm3xqxuetqahq@redhat.com> (raw)
In-Reply-To: <ed4ae175-1c67-b7fb-669d-c8c08ca1a7f7@huawei.com>

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



  parent reply	other threads:[~2021-08-03 15:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-02  3:52 [Question] qemu-img convert block alignment Zhenyu Ye
2021-08-03  1:53 ` Zhenyu Ye
2021-08-03 15:03 ` Eric Blake [this message]
2021-08-04  7:18   ` Zhenyu Ye

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210803150316.eo5gm3xqxuetqahq@redhat.com \
    --to=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pl@kamp.de \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=yezhenyu2@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.