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: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCHv2 02/11] iscsi: read unmap info from block limits vpd page
Date: Fri, 05 Jul 2013 08:28:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6

Il 04/07/2013 23:07, Peter Lieven ha scritto:
> 
> 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?

I would be very surprised, but if you are worried about that, it
definitely won't happen with WRITE_SAME.

Paolo




reply via email to

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