From: Stefan Hajnoczi <stefanha@gmail.com>
To: Fam Zheng <famz@redhat.com>
Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH v3 6/6] vmdk: add bdrv_co_write_zeroes
Date: Thu, 25 Apr 2013 15:20:11 +0200 [thread overview]
Message-ID: <20130425132011.GA10799@stefanha-thinkpad.redhat.com> (raw)
In-Reply-To: <1366807475-26350-7-git-send-email-famz@redhat.com>
On Wed, Apr 24, 2013 at 08:44:35PM +0800, Fam Zheng wrote:
> @@ -905,6 +905,13 @@ static int get_cluster_offset(BlockDriverState *bs,
> l2_index = ((offset >> 9) / extent->cluster_sectors) % extent->l2_size;
> *cluster_offset = le32_to_cpu(l2_table[l2_index]);
>
> + if (m_data) {
> + m_data->valid = 1;
> + m_data->l1_index = l1_index;
> + m_data->l2_index = l2_index;
> + m_data->offset = *cluster_offset;
> + m_data->l2_offset = extent->l1_table[m_data->l1_index];
This line can simply be:
m_data->l2_offset = l2_offset;
> + }
Filling in m_data up here means that only the ->offset field needs to be
filled in when we allocate a cluster further down. Right now the code
is duplicated, but it just overwrites the fields with the same value
again.
> @@ -1222,17 +1238,34 @@ static int vmdk_write(BlockDriverState *bs, int64_t sector_num,
> if (n > nb_sectors) {
> n = nb_sectors;
> }
> -
> - ret = vmdk_write_extent(extent,
> - cluster_offset, index_in_cluster * 512,
> - buf, n, sector_num);
> - if (ret) {
> - return ret;
> - }
> - if (m_data.valid) {
> - /* update L2 tables */
> - if (vmdk_L2update(extent, &m_data) == -1) {
> - return -EIO;
> + if (zeroed) {
> + /* Do zeroed write, buf is ignored */
> + if (extent->has_zero_grain &&
> + index_in_cluster == 0 &&
> + n >= extent->cluster_sectors) {
> + n = extent->cluster_sectors;
> + if (!zero_dry_run) {
> + m_data.offset = cpu_to_le32(VMDK_GTE_ZEROED);
offset is host endian now!
> + /* update L2 tables */
> + if (vmdk_L2update(extent, &m_data) != VMDK_OK) {
Zeroing cluster-by-cluster is slow - vmdk_L2update() uses sync to flush
the L2 update. The vmdk.c code isn't great for buffering up metadata
changes and flushing them in a single operation though, so this is fine
for now.
> + return -EIO;
> + }
l2_cache[] has not been updated with the new VMDK_GTE_ZEROED offset.
next prev parent reply other threads:[~2013-04-25 13:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-24 12:44 [Qemu-devel] [PATCH v3 0/6] vmdk: zeroed-grain GTE support Fam Zheng
2013-04-24 12:44 ` [Qemu-devel] [PATCH v3 1/6] vmdk: named return code Fam Zheng
2013-04-24 12:44 ` [Qemu-devel] [PATCH v3 2/6] vmdk: add support for “zeroed‐grain” GTE Fam Zheng
2013-04-24 12:44 ` [Qemu-devel] [PATCH v3 3/6] vmdk: Add option to create zeroed-grain image Fam Zheng
2013-04-24 12:44 ` [Qemu-devel] [PATCH v3 4/6] vmdk: change magic number to macro Fam Zheng
2013-04-24 12:44 ` [Qemu-devel] [PATCH v3 5/6] vmdk: store fields of VmdkMetaData in cpu endian Fam Zheng
2013-04-25 13:20 ` Stefan Hajnoczi
2013-04-24 12:44 ` [Qemu-devel] [PATCH v3 6/6] vmdk: add bdrv_co_write_zeroes Fam Zheng
2013-04-25 13:20 ` Stefan Hajnoczi [this message]
2013-04-25 13:25 ` [Qemu-devel] [PATCH v3 0/6] vmdk: zeroed-grain GTE support Stefan Hajnoczi
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=20130425132011.GA10799@stefanha-thinkpad.redhat.com \
--to=stefanha@gmail.com \
--cc=famz@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).