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 <ronniesahlb...@gmail.com>: > 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 <p...@kamp.de> wrote: >> >> Am 04.07.2013 um 14:37 schrieb Paolo Bonzini <pbonz...@redhat.com>: >> >>> 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 >>
