From: "Denis V. Lunev" <den@openvz.org>
To: Eric Blake <eblake@redhat.com>, nbd-general@lists.sourceforge.net
Cc: qemu-devel@nongnu.org, alex@alex.org.uk, pborzenkov@virtuozzo.com
Subject: Re: [Qemu-devel] [PATCH] doc: Allow NBD_CMD_FLAG_NO_HOLE during NBD_CMD_WRITE
Date: Mon, 4 Apr 2016 17:47:41 +0300 [thread overview]
Message-ID: <57027E8D.7060902@openvz.org> (raw)
In-Reply-To: <1459779314-12266-1-git-send-email-eblake@redhat.com>
On 04/04/2016 05:15 PM, Eric Blake wrote:
> qemu already has an existing server implementation option that will
> explicitly search the payload of NBD_CMD_WRITE for large blocks of
> zeroes, and punch holes in the underlying file. For old clients
> that don't know how to use the new NBD_CMD_WRITE_ZEROES, this is a
> workaround to keep the server's destination file approximately as
> sparse as the client's source. However, for new clients that know
> how to explicitly request holes, it is unnecessary overhead; and
> can lead to the server punching a hole and risking fragmentation or
> future ENOSPC even when the client explicitly wanted to write
> zeroes rather than a hole. So it makes sense to let the new
> NBD_CMD_FLAG_NO_HOLE work for WRITE as well as WRITE_ZEROES.
>
> Signed-off-by: Eric Blake <eblake@redhat.com>
what behaviour do you expect for QCOW2 file?
We should fully provision that image as far as I could understand,
i.e. allocate data blocks with zero content.
I think that this would work.
next prev parent reply other threads:[~2016-04-04 15:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-04 14:15 [Qemu-devel] [PATCH] doc: Allow NBD_CMD_FLAG_NO_HOLE during NBD_CMD_WRITE Eric Blake
2016-04-04 14:47 ` Denis V. Lunev [this message]
2016-04-04 15:00 ` Eric Blake
2016-04-04 15:16 ` Alex Bligh
2016-04-04 22:15 ` [Qemu-devel] [PATCH v2] " Eric Blake
2016-04-05 9:38 ` [Qemu-devel] [Nbd] " Markus Pargmann
2016-04-05 16:43 ` Eric Blake
2016-04-05 20:45 ` Wouter Verhelst
2016-04-05 22:51 ` [Qemu-devel] [PATCH] " Paolo Bonzini
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=57027E8D.7060902@openvz.org \
--to=den@openvz.org \
--cc=alex@alex.org.uk \
--cc=eblake@redhat.com \
--cc=nbd-general@lists.sourceforge.net \
--cc=pborzenkov@virtuozzo.com \
--cc=qemu-devel@nongnu.org \
/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.