Right. I don't see any problem with your patch.
On Sat, Jul 6, 2013 at 3:15 PM, Peter Lieven <p...@kamp.de> wrote: > ok, to sum up you see no potential problem with my patch to optimize write > zeroes by > unmap iff lbprz==1 and lbpme == 1 ? ACK > > 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 >>> >
