Re: [Qemu-devel] [PATCHv2 02/11] iscsi: read unmap info from block limits vpd page

[Peter Lieven <pl@kamp.de>]

ok, to sum up you see no potential problem with my patch to optimize write zeroes by
unmap iff lbprz==1 and lbpme == 1 ?

the alternative would be to use writesame16 and sent a zero block. this would allow
an optimization also if lbprz == 0. in this case i would not set the unmap bit.

peter


Am 05.07.2013 um 09:11 schrieb ronnie sahlberg <ronniesahlberg@gmail.com>:

> 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==1 then it will always
> 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.
> 
> ===
> 
> 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 – 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 <pl@kamp.de> wrote:
>> 
>> Am 04.07.2013 um 14:37 schrieb Paolo Bonzini <pbonzini@redhat.com>:
>> 
>>> 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?
>> 
>> Peter
>>