[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