From: Eric Blake <eblake@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>, Yi Fang <eric.fangyi@huawei.com>
Cc: kwolf@redhat.com, xieyingtai@huawei.com, subo7@huawei.com,
qemu-devel@nongnu.org, mreitz@redhat.com, wu.wubin@huawei.com,
pbonzini@redhat.com, sochin.jiang@huawei.com
Subject: Re: [Qemu-devel] [PATCH] nbd: Implement NBD_CMD_HAS_ZERO_INIT
Date: Mon, 5 Dec 2016 10:54:19 -0600 [thread overview]
Message-ID: <7c2e5e96-69e4-098c-2dca-22a03b823b5f@redhat.com> (raw)
In-Reply-To: <20161205110954.GF22443@stefanha-x1.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1789 bytes --]
On 12/05/2016 05:09 AM, Stefan Hajnoczi wrote:
> On Sun, Dec 04, 2016 at 11:44:57PM +0000, Yi Fang wrote:
>> NBD client has not implemented callback for .bdrv_has_zero_init. So
>> bdrv_has_zero_init always returns 0 when doing non-shared storage
>> migration.
>> This patch implemented NBD_CMD_HAS_ZERO_INIT and will avoid unnecessary
>> set-dirty.
>
> Please link to the NBD spec where this new command is defined. Has it
> already been accepted by the NBD community?
No. This is the first I've seen of such a proposal.
>
> I think this is a weird command because it's information that doesn't
> change over the lifetime of an NBD session. Your patch sends a command
> and waits for the reply every time has_zero_init() is queried.
>
> Is there a better place to put this information in the NBD protocols,
> like some export information that is retried during connection? (I
> haven't checked the protocol.) It seems weird to send a command and
> wait for the response.
Agreed - this patch is wrong. Even if you DO get the NBD community to
buy into this, it should be done as a new NBD_FLAG_* sent once up-front
during handshake phase in reply to NBD_OPT_EXPORT_NAME/NBD_OPT_GO, and
NOT a new command that can be arbitrarily invoked multiple times during
transmission phase.
Is the goal of the flag for the server to be able to advertise to the
client that upon initial connection, the server asserts that the volume
currently reads as all zeroes (and therefore the client can optimize by
not writing zeroes)?
Do you need me to help re-write this into a proposal to the NBD
community that might stand a chance of being accepted?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2016-12-05 16:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-04 23:44 [Qemu-devel] [PATCH] nbd: Implement NBD_CMD_HAS_ZERO_INIT Yi Fang
2016-12-05 11:09 ` Stefan Hajnoczi
2016-12-05 16:54 ` Eric Blake [this message]
2016-12-06 3:10 ` Fangyi (C)
2016-12-06 3:00 ` Fangyi (C)
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=7c2e5e96-69e4-098c-2dca-22a03b823b5f@redhat.com \
--to=eblake@redhat.com \
--cc=eric.fangyi@huawei.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=sochin.jiang@huawei.com \
--cc=stefanha@gmail.com \
--cc=subo7@huawei.com \
--cc=wu.wubin@huawei.com \
--cc=xieyingtai@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 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).