[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: |
Peter Lieven |
Subject: |
Re: [Qemu-devel] [PATCHv2 02/11] iscsi: read unmap info from block limits vpd page |
Date: |
Sun, 7 Jul 2013 00:15:54 +0200 |
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 <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
>>