From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51959) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzkOw-0001yb-81 for qemu-devel@nongnu.org; Thu, 18 Jul 2013 05:21:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UzkOu-0003sB-UG for qemu-devel@nongnu.org; Thu, 18 Jul 2013 05:21:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:29708) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzkOu-0003s5-Mt for qemu-devel@nongnu.org; Thu, 18 Jul 2013 05:21:28 -0400 Date: Thu, 18 Jul 2013 11:21:19 +0200 From: Kevin Wolf Message-ID: <20130718092119.GF3582@dhcp-200-207.str.redhat.com> 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> <20130717102551.GF2458@dhcp-200-207.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable 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: ronnie sahlberg Cc: Paolo Bonzini , Peter Lieven , qemu-devel , Stefan Hajnoczi Am 17.07.2013 um 17:54 hat ronnie sahlberg geschrieben: > On Wed, Jul 17, 2013 at 3:25 AM, Kevin Wolf wrote: > > Am 17.07.2013 um 11:58 hat Paolo Bonzini geschrieben: > >> BTW, Peter and Ronnie: we were assuming that UNMAP with LBPRZ=3D1 al= ways > >> zeroes blocks, but is that true for unaligned operations? > > > > SBC-3 Rev. 35e, 5.16 READ CAPACITY (16) command: > > > > "A logical block provisioning read zeros (LBPRZ) bit set to one > > indicates that, for read commands specifying an unmapped LBA (see > > 4.7.4.5), the device server returns user data set to zero [...]" > > > > So it depends on the block provisioning state of the LBA, not on the > > operations that were performed on it. > > > > 5.28 UNMAP command: > > > > If the ANCHOR bit in the CDB is set to zero, and the logical unit= is > > thin provisioned (see 4.7.3.3), then the logical block provisioni= ng > > state for each specified LBA: > > > > a) should become deallocated; > > b) may become anchored; or > > c) may remain unchanged. > > > > So with UNMAP, I think you don't have any guarantees that the LBA > > becomes unmapped and therefore zeroed. It could just keep its current > > data. No matter whether your request was aligned or not. > > >=20 > If you check the LogicalBlockLimits VPD page it has : >=20 > --- > [...] > An unmap request with a starting LBA that is not optimal may result in > unmap operations on fewer LBAs than > requested. > --- >=20 > So if Peter checks OPTIMAL_UNMAP_GRANULARITY and > UNMAP_GRANULARITY_ALIGNMENT and make sure that > the starting LBA is (n * OUG) + UGA and that the number of blocks > is a multiple of OUG then you should be fine. Okay, playing language^Whardware spec lawyer... You've got the logic backwards. The spec says "if misaligned then unmap fewer LBAs". This is an implication, not an equivalence: It doesn't say "if unmap fewer LBAs then misaligned". The sentence from the VPD page just reinforces for a special case what I have quoted above (as take it as a hint like "this would be the typical result"). The point is that the spec just says it "should" become deallocated, not "must" or "shall", and there is no condition connected with it. "should" is defined in the usual way (3.5.15): 3.5.13 should a keyword indicating flexibility of choice with a strongly preferred alternative; =E2=80=9Cshould=E2=80=9D is equivalent to the phrase =E2= =80=9Cit is strongly recommended=E2=80=9D So, it would be nice if UNMAP unmapped, but it doesn't have to. > I think it is reasonable to assume that IF LBPRZ=3D=3D1 and IF it is an > "optimal unmap request" then the blocks will become unmapped and they > will > read back as 0. It might be reasonable to expect in practice, but as I see it, it's not demanded by the spec. WRITE SAME is different, there you actually get the guarantee that the desired data is read back. I strongly recommend using it over UNMAP therefore if you don't want to discard, but write zeroes. Kevin