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

[ronnie sahlberg]

Right.

I don't see any problem with your patch.


On Sat, Jul 6, 2013 at 3:15 PM, Peter Lieven <address@hidden> wrote:
> ok, to sum up you see no potential problem with my patch to optimize write 
> zeroes by
> unmap iff lbprz==1 and lbpme == 1 ?

ACK


>
> 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 <address@hidden>:
>
>> 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 <address@hidden> wrote:
>>>
>>> Am 04.07.2013 um 14:37 schrieb Paolo Bonzini <address@hidden>:
>>>
>>>> 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
>>>
>