qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: ronnie sahlberg
Subject: Re: [Qemu-devel] [PATCHv2 02/11] iscsi: read unmap info from block limits vpd page
Date: Fri, 5 Jul 2013 00:11:28 -0700

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
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]