From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43931) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzPFv-0000d4-D4 for qemu-devel@nongnu.org; Wed, 17 Jul 2013 06:46:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UzPFs-0005Vs-Ox for qemu-devel@nongnu.org; Wed, 17 Jul 2013 06:46:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27551) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzPFs-0005Vl-C7 for qemu-devel@nongnu.org; Wed, 17 Jul 2013 06:46:44 -0400 Message-ID: <51E675E6.7050101@redhat.com> Date: Wed, 17 Jul 2013 12:45:58 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1373885375-13601-1-git-send-email-pl@kamp.de> <1373885375-13601-5-git-send-email-pl@kamp.de> <20130717084648.GD2458@dhcp-200-207.str.redhat.com> <51E66ACD.70706@redhat.com> <74B76DD7-FBF6-42CD-8B9D-62661B98A860@kamp.de> In-Reply-To: <74B76DD7-FBF6-42CD-8B9D-62661B98A860@kamp.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/4] qemu-img: conditionally discard target on convert List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: Kevin Wolf , ronniesahlberg@gmail.com, qemu-devel@nongnu.org, stefanha@redhat.com Il 17/07/2013 12:21, Peter Lieven ha scritto: >> > BTW, Peter and Ronnie: we were assuming that UNMAP with LBPRZ=1 always >> > zeroes blocks, but is that true for unaligned operations? > Good question, I will pass it to ronnie. My guess is that the command will fail with > a check condition if it failed to unmap the data. From what Ronnie sent earlier > it should be guaranteed that the blocks are at least zero after the unmap command. I'm not so sure about that, SBC says explicitly that a misaligned unmap request "may result in unmap operations on fewer LBAs than requested". Perhaps it's better to do this: - if LBPWS=1, use WRITE SAME(16). For WRITE SAME it is explicit that "if the device server does not deallocate or anchor the LBA, then the device server shall perform the specified write operation". Expose the value of LBPRZ in the "discard zeroes" field of BlockDriverInfo. - if LBPWS=0, you can still support discard iff LBPU=1 and use UNMAP. But if LBPRZ=1 and LBPWS=0, you should not expose the "discard zeroes" field of BlockDriverInfo. > As for the qemu-img patch this shouldn't matter. It uses always blocks of bdi->max_unmap > which should be a multiple of the alignment. Also, the remainder itself (which SBC calls "UNMAP GRANULARITY ALIGNMENT") may not be 0. I think the above trick (only exposing LBPRZ if you'll use WRITE SAME) will sidestep the problem. It may also remove the need to fall back to has_zero_init=1. Paolo