From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53227) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuzVN-0005wC-Lj for qemu-devel@nongnu.org; Fri, 05 Jul 2013 02:28:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UuzVM-0007jz-Lg for qemu-devel@nongnu.org; Fri, 05 Jul 2013 02:28:29 -0400 Received: from mail-ea0-x236.google.com ([2a00:1450:4013:c01::236]:51834) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuzVM-0007jr-F8 for qemu-devel@nongnu.org; Fri, 05 Jul 2013 02:28:28 -0400 Received: by mail-ea0-f182.google.com with SMTP id d10so1240878eaj.27 for ; Thu, 04 Jul 2013 23:28:27 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51D66781.4020407@redhat.com> Date: Fri, 05 Jul 2013 08:28:17 +0200 From: Paolo Bonzini MIME-Version: 1.0 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> In-Reply-To: <05F80B98-FC6D-4562-8B23-45495ADE6A01@kamp.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 , ronnie sahlberg , qemu-devel , Stefan Hajnoczi Il 04/07/2013 23:07, Peter Lieven ha scritto: > > 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 descriptors out, but >>> at least for my storage the maximum unmap counts not for each descriptors, but for all >>> together. So in this case we do not need the field at all. I forgot to remove it. >>> >>> discard and write_zeroes will both only send one request up to max_unmap in size. >>> >>> apropos write_zeroes: do you know if UNMAP is guaranteed to unmap data if lbprz == 1? >> >> Yes. On the other hand note that WRITE_SAME should be guaranteed _not_ >> to unmap if lbprz == 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 blocks 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 == 1 is it guaranteed that it reads > as zero afterwards? Regardless if the target decides to "upgrade" the block or do > not unmap the block? I would be very surprised, but if you are worried about that, it definitely won't happen with WRITE_SAME. Paolo