From: Peter Lieven <pl@kamp.de>
To: Stefan Hajnoczi <stefanha@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
Anthony Liguori <anthony@codemonkey.ws>,
Stefan Hajnoczi <stefanha@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
ronnie sahlberg <ronniesahlberg@gmail.com>
Subject: Re: [Qemu-devel] [PATCHv3 00/20] block: logical block provisioning enhancements
Date: Tue, 08 Oct 2013 10:01:07 +0200 [thread overview]
Message-ID: <5253BBC3.3050203@kamp.de> (raw)
In-Reply-To: <CAJSP0QVg1kS5UpHQu7EsNJtpYs_Y3Z_sY=7FXyNMdm0xarRHmg@mail.gmail.com>
On 08.10.2013 09:02, Stefan Hajnoczi wrote:
> On Mon, Oct 7, 2013 at 11:42 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Il 07/10/2013 10:42, Stefan Hajnoczi ha scritto:
>>> Could you make bdrv_co_write_zeroes() always use UNMAP, if possible, and
>>> avoid adding the new BDRV_REQ_MAY_UNMAP flag? While reading the first
>>> few patches in this series I wondered why there is a need to expose
>>> flags at all...
>>>
>>> Sometimes it is useful to distinguish between zeroing at the image
>>> format level from discarding at the device level, but I don't think we
>>> make use of that yet. I'd prefer to keep the interface simple for now
>>> and add flags later, if necessary.
>>>
>>> Or maybe I just missed something ;)
>> The flag is needed to implement the right semantics for the SCSI WRITE
>> SAME command, which are:
>>
>> - if the UNMAP bit is off, always write the sectors (that's
>> bdrv_aio_write_zeroes without BDRV_REQ_MAY_UNMAP if the payload is zero,
>> otherwise it's emulated with bdrv_aio_writev)
>>
>> - if the target can "discard and write the specified payload", you can
>> discard, else you must write the sectors with the correct payload
>> (that's bdrv_aio_write_zeroes with BDRV_REQ_MAY_UNMAP).
>>
>> Contrast this with the UNMAP command, which does not make any guarantee
>> on the content of the sectors after the command is completed (a few
>> months ago we agreed that, even if you have discard_zeroes=true in the
>> target, it is fine for UNMAP to do nothing).
> Okay, then let's keep the patches to expose the flag.
Okay, then I can keep those.
Can you give a short hint if my approach with brdv_make_empty is what
you want? I would like to not change the parameters, so use BDRV_REQ_MAY_UNMAP
unconditionally.
int bdrv_make_empty(BlockDriverState *bs)
{
int64_t target_size = bdrv_getlength(bs) / BDRV_SECTOR_SIZE;
int64_t ret, nb_sectors, sector_num = 0;
int n;
if (bs->drv->bdrv_make_empty) {
return bs->drv->bdrv_make_empty(bs);
}
for (;;) {
nb_sectors = target_size - sector_num;
if (nb_sectors <= 0) {
return 0;
}
if (nb_sectors > INT_MAX) {
nb_sectors = INT_MAX;
}
ret = bdrv_get_block_status(bs, sector_num, nb_sectors, &n);
if (ret & BDRV_BLOCK_ZERO) {
sector_num += n;
continue;
}
ret = bdrv_write_zeroes(bs, sector_num, n, BDRV_REQ_MAY_UNMAP);
if (ret < 0) {
error_report("error writing zeroes at sector %" PRId64 ": %s",
sector_num, strerror(-ret));
return ret;
}
sector_num += n;
}
}
next prev parent reply other threads:[~2013-10-08 8:01 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-24 13:34 [Qemu-devel] [PATCHv3 00/20] block: logical block provisioning enhancements Peter Lieven
2013-09-24 13:34 ` [Qemu-devel] [PATCHv3 01/20] block: make BdrvRequestFlags public Peter Lieven
2013-09-24 13:34 ` [Qemu-devel] [PATCHv3 02/20] block: add flags to bdrv_*_write_zeroes Peter Lieven
2013-10-02 15:32 ` Eric Blake
2013-09-24 13:34 ` [Qemu-devel] [PATCHv3 03/20] block: introduce BDRV_REQ_MAY_UNMAP request flag Peter Lieven
2013-09-24 13:34 ` [Qemu-devel] [PATCHv3 04/20] block: introduce bdrv_has_discard_zeroes and bdrv_has_discard_write_zeroes Peter Lieven
2013-10-02 15:41 ` Eric Blake
2013-09-24 13:34 ` [Qemu-devel] [PATCHv3 05/20] block/raw: add " Peter Lieven
2013-10-02 15:43 ` Eric Blake
2013-09-24 13:35 ` [Qemu-devel] [PATCHv3 06/20] block: add BlockLimits structure to BlockDriverState Peter Lieven
2013-10-02 15:53 ` Eric Blake
2013-10-07 8:10 ` Stefan Hajnoczi
2013-09-24 13:35 ` [Qemu-devel] [PATCHv3 07/20] block: honour BlockLimits in bdrv_co_do_write_zeroes Peter Lieven
2013-10-02 16:37 ` Eric Blake
2013-09-24 13:35 ` [Qemu-devel] [PATCHv3 08/20] block: honour BlockLimits in bdrv_co_discard Peter Lieven
2013-10-02 16:41 ` Eric Blake
2013-10-07 8:29 ` Stefan Hajnoczi
2013-10-07 8:36 ` Peter Lieven
2013-09-24 13:35 ` [Qemu-devel] [PATCHv3 09/20] iscsi: simplify iscsi_co_discard Peter Lieven
2013-09-24 13:35 ` [Qemu-devel] [PATCHv3 10/20] iscsi: set limits in BlockDriverState Peter Lieven
2013-10-02 16:43 ` Eric Blake
2013-09-24 13:35 ` [Qemu-devel] [PATCHv3 11/20] iscsi: add bdrv_has_discard_zeroes and bdrv_has_discard_write_zeroes Peter Lieven
2013-10-02 16:45 ` Eric Blake
2013-09-24 13:35 ` [Qemu-devel] [PATCHv3 12/20] iscsi: add bdrv_co_write_zeroes Peter Lieven
2013-09-24 13:35 ` [Qemu-devel] [PATCHv3 13/20] block: introduce bdrv_zeroize Peter Lieven
2013-10-02 16:51 ` Eric Blake
2013-10-07 8:34 ` Stefan Hajnoczi
2013-10-07 8:39 ` Peter Lieven
2013-09-24 13:35 ` [Qemu-devel] [PATCHv3 14/20] block/get_block_status: set *pnum = 0 on error Peter Lieven
2013-09-24 13:35 ` [Qemu-devel] [PATCHv3 15/20] block/get_block_status: avoid segfault if there is no backing_hd Peter Lieven
2013-09-24 13:35 ` [Qemu-devel] [PATCHv3 16/20] block/get_block_status: avoid redundant callouts on raw devices Peter Lieven
2013-09-24 13:35 ` [Qemu-devel] [PATCHv3 17/20] block/get_block_status: fix BDRV_BLOCK_ZERO for unallocated blocks Peter Lieven
2013-09-24 13:35 ` [Qemu-devel] [PATCHv3 18/20] qemu-img: add support for fully allocated images Peter Lieven
2013-10-02 17:01 ` Eric Blake
2013-09-24 13:35 ` [Qemu-devel] [PATCHv3 19/20] qemu-img: conditionally zero out target on convert Peter Lieven
2013-09-24 13:35 ` [Qemu-devel] [PATCHv3 20/20] block/raw: copy BlockLimits on raw_open Peter Lieven
2013-10-02 17:11 ` Eric Blake
2013-10-07 8:38 ` Stefan Hajnoczi
2013-10-07 8:40 ` Peter Lieven
2013-10-07 8:42 ` [Qemu-devel] [PATCHv3 00/20] block: logical block provisioning enhancements Stefan Hajnoczi
2013-10-07 8:47 ` Peter Lieven
2013-10-07 9:42 ` Paolo Bonzini
2013-10-08 7:02 ` Stefan Hajnoczi
2013-10-08 8:01 ` Peter Lieven [this message]
2013-10-08 8:59 ` Stefan Hajnoczi
2013-10-08 9:12 ` Peter Lieven
2013-10-08 9:26 ` 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=5253BBC3.3050203@kamp.de \
--to=pl@kamp.de \
--cc=anthony@codemonkey.ws \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=ronniesahlberg@gmail.com \
--cc=stefanha@gmail.com \
--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).