From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40829) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5gwS-0004bz-VJ for qemu-devel@nongnu.org; Thu, 08 Mar 2012 12:16:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S5gwM-0004pl-3o for qemu-devel@nongnu.org; Thu, 08 Mar 2012 12:15:52 -0500 Received: from mail-yx0-f173.google.com ([209.85.213.173]:57292) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5gwL-0004pS-DM for qemu-devel@nongnu.org; Thu, 08 Mar 2012 12:15:45 -0500 Received: by yenr5 with SMTP id r5so437503yen.4 for ; Thu, 08 Mar 2012 09:15:43 -0800 (PST) Sender: Paolo Bonzini From: Paolo Bonzini Date: Thu, 8 Mar 2012 18:15:07 +0100 Message-Id: <1331226917-6658-8-git-send-email-pbonzini@redhat.com> In-Reply-To: <1331226917-6658-1-git-send-email-pbonzini@redhat.com> References: <1331226917-6658-1-git-send-email-pbonzini@redhat.com> Subject: [Qemu-devel] [RFC PATCH 07/17] block: make high level discard operation always zero List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org While the formats/protocols are free to implement a discard operation that does *not* zero the data, providing a common view to the guests is the only way to avoid configuration and migration nightmares. (We don't want the admin to manually set up discard_zeroes_data/discard_granularity!) This has a couple of drawbacks: 1) QEMU effectively will not try to use discard unless discard_zeroes_data is true. To do this we could add a flag such as BDRV_ALWAYS_DISCARD, which the device models could use if their discard_zeroes_data property is set to false. However, I haven't done this, estimating that no strictly positive integer could represent the number of people using it. 2) it may turn a thin-provisioning operation into a full preallocation, which is not nice. 3) it may cost memory for a bounce buffer that only needs to be filled with zeroes. While (3) can be worked around, the only way around the other two, unfortunately, is support in the formats and protocols. We will still provide device options to opt out of this, but with raw and qed covered (+ qcow2 without backing file, and qcow3 in the future) it should not be too bad. Signed-off-by: Paolo Bonzini --- block.c | 14 +++++++++++--- 1 files changed, 11 insertions(+), 3 deletions(-) diff --git a/block.c b/block.c index 34db914..30b137f 100644 --- a/block.c +++ b/block.c @@ -74,6 +74,8 @@ static int coroutine_fn bdrv_co_do_writev(BlockDriverState *bs, BdrvRequestFlags flags); static int coroutine_fn bdrv_co_do_write_zeroes(BlockDriverState *bs, int64_t sector_num, int nb_sectors, QEMUIOVector *qiov); +static int coroutine_fn bdrv_co_do_discard(BlockDriverState *bs, + int64_t sector_num, int nb_sectors); static BlockDriverAIOCB *bdrv_co_aio_rw_vector(BlockDriverState *bs, int64_t sector_num, QEMUIOVector *qiov, @@ -1797,7 +1799,7 @@ static int coroutine_fn bdrv_co_do_write_zeroes(BlockDriverState *bs, bdi.discard_granularity && (sector_num & (bdi.discard_granularity - 1)) == 0 && (nb_sectors & (bdi.discard_granularity - 1)) == 0) { - return bdrv_co_discard(bs, sector_num, nb_sectors); + return bdrv_co_do_discard(bs, sector_num, nb_sectors); } if (qiov) { @@ -3621,8 +3623,8 @@ static void coroutine_fn bdrv_discard_co_entry(void *opaque) rwco->ret = bdrv_co_discard(rwco->bs, rwco->sector_num, rwco->nb_sectors); } -int coroutine_fn bdrv_co_discard(BlockDriverState *bs, int64_t sector_num, - int nb_sectors) +static int coroutine_fn bdrv_co_do_discard(BlockDriverState *bs, + int64_t sector_num, int nb_sectors) { if (!bs->drv) { return -ENOMEDIUM; @@ -3651,6 +3653,12 @@ int coroutine_fn bdrv_co_discard(BlockDriverState *bs, int64_t sector_num, } } +int coroutine_fn bdrv_co_discard(BlockDriverState *bs, + int64_t sector_num, int nb_sectors) +{ + return bdrv_co_do_write_zeroes(bs, sector_num, nb_sectors, NULL); +} + int bdrv_discard(BlockDriverState *bs, int64_t sector_num, int nb_sectors) { Coroutine *co; -- 1.7.7.6