From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43763) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UvbpI-0001iK-5z for qemu-devel@nongnu.org; Sat, 06 Jul 2013 19:23:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UvbpE-0000uJ-4v for qemu-devel@nongnu.org; Sat, 06 Jul 2013 19:23:36 -0400 Received: from mail-pa0-x233.google.com ([2607:f8b0:400e:c03::233]:36759) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UvbpD-0000u9-UQ for qemu-devel@nongnu.org; Sat, 06 Jul 2013 19:23:32 -0400 Received: by mail-pa0-f51.google.com with SMTP id lf11so3192537pab.38 for ; Sat, 06 Jul 2013 16:23:30 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <818493B0-E13E-4879-BECD-3F0BE519B1C2@kamp.de> References: <1372338695-411-1-git-send-email-pl@kamp.de> <1372338695-411-3-git-send-email-pl@kamp.de> <3E2D40D0-A2C9-4F40-A512-FC917FA13A14@kamp.de> <51D56C6C.60203@redhat.com> <05F80B98-FC6D-4562-8B23-45495ADE6A01@kamp.de> <818493B0-E13E-4879-BECD-3F0BE519B1C2@kamp.de> Date: Sat, 6 Jul 2013 16:23:30 -0700 Message-ID: From: ronnie sahlberg Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCHv2 02/11] iscsi: read unmap info from block limits vpd page List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: Kevin Wolf , Paolo Bonzini , qemu-devel , Stefan Hajnoczi Right. I don't see any problem with your patch. On Sat, Jul 6, 2013 at 3:15 PM, Peter Lieven wrote: > ok, to sum up you see no potential problem with my patch to optimize writ= e zeroes by > unmap iff lbprz=3D=3D1 and lbpme =3D=3D 1 ? ACK > > the alternative would be to use writesame16 and sent a zero block. this w= ould allow > an optimization also if lbprz =3D=3D 0. in this case i would not set the = unmap bit. > > peter > > > Am 05.07.2013 um 09:11 schrieb ronnie sahlberg = : > >> The device MIGHT map or anchor the blocks after the unmap but it may >> only do so if the blocks that become mapped are all zero. >> >> So I think you can safely assume that if lbprz=3D=3D1 then it will alwa= ys >> read back as zero no matter what happens internally in the target. >> >> Either the block becomes unmapped/deallocated and then it will read >> back as zero, >> or the blocks is automatically re-mapped to anchored/mapped again >> but this can only happen if the mapped block is all zero so once again >> it will still read back as all zero. >> >> =3D=3D=3D >> >> 4.7.3.5 Autonomous LBA transitions >> A device server may perform the following actions at any time: >> a) transition any deallocated LBA to mapped; >> b) transition any anchored LBA to mapped; or >> c) transition any deallocated LBA to anchored. >> If the LBPRZ bit in the READ CAPACITY (16) parameter data (see 5.16.2) >> is set to one, and a mapped LBA >> references a logical block that contains: >> a) user data with all bits set to zero; and >> Working Draft SCSI Block Commands =96 3 (SBC-3) >> 27T10/BSR INCITS 514 Revision 35d >> 15 May 2013 >> b) protection information, if any, set to FFFF_FFFF_FFFF_FFFFh, >> then the device server may transition that mapped LBA to anchored or >> deallocated at any time. >> The logical block provisioning st >> >> On Thu, Jul 4, 2013 at 2:07 PM, Peter Lieven wrote: >>> >>> Am 04.07.2013 um 14:37 schrieb Paolo Bonzini : >>> >>>> Il 03/07/2013 23:23, Peter Lieven ha scritto: >>>>> BDC is not used. I had an implementation that sent multiple descripto= rs out, but >>>>> at least for my storage the maximum unmap counts not for each descrip= tors, but for all >>>>> together. So in this case we do not need the field at all. I forgot t= o remove it. >>>>> >>>>> discard and write_zeroes will both only send one request up to max_un= map in size. >>>>> >>>>> apropos write_zeroes: do you know if UNMAP is guaranteed to unmap dat= a if lbprz =3D=3D 1? >>>> >>>> Yes. On the other hand note that WRITE_SAME should be guaranteed _not= _ >>>> to unmap if lbprz =3D=3D 0 and you do WRITE_SAME with UNMAP and a zero >>>> payload, but I suspect there may be buggy targets here. >>>> >>>>> I have read in the specs something that the target might unmap the bl= ocks or not touch them at all. >>>>> Maybe you have more information. >>>> >>>> That's even true of UNMAP itself, actually. :) >>>> >>>> The storage can always "upgrade" a block from unmapped to anchored and >>>> from anchored to allocated, so UNMAP can be a no-op and still comply >>>> with the standard. >>> >>> My concern was, if I UNMAP a block and lbprz =3D=3D 1 is it guaranteed = that it reads >>> as zero afterwards? Regardless if the target decides to "upgrade" the b= lock or do >>> not unmap the block? >>> >>> Peter >>> >