On Thu, Jul 18, 2013 at 11:43 AM, Peter Lieven <p...@kamp.de> wrote: > > Am 18.07.2013 um 16:35 schrieb Paolo Bonzini <pbonz...@redhat.com>: > >> Il 18/07/2013 16:32, Peter Lieven ha scritto: >>>>> >>>> (Mis)alignment and granularity can be handled later. We can ignore them >>>> for now. Later, if we decide the best way to support them is a flag, >>>> we'll add it. Let's not put the cart before the horse. >>>> >>>> BTW, I expect alignment!=0 to be really, really rare. >>> To explain my concerns: >>> >>> I know that my target has internal page size of 15MB. I will check what >>> happens >>> if I deallocate this 15MB in chunks of lets say 1MB. If the page gets >>> unprovisioned >>> after the last chunk is unmapped it would be fine :-) >> >> You're talking of granularity here, not (mis)alignment. > > you are right. for the target i am talking about this is 30720 512-byte > blocks for the granularity (pagesize) and 0 for the alignment. > i will see what happens if I write same w/unmap the whole 30720 blocks in > smaller blocks ;-)
If you write in smaller than OUG chunks, whether or not the phusical block becomes unmapped is I think implementation defined. A target is allowed to make this unmapped but not required to. For example if you do two writesame16 for your 30720 chunk : 1, writesame16 lba:0 tl:30000 2, writesame16 lba:30000 tl:720 then SBC 4.7.3.4 === A WRITE SAME command shall not cause an LBA to become unmapped if unmapping that LBA creates a case in which a subsequent read of that unmapped LBA mayis able to return user data or protection informationlogical block data that differs from the Data-Out Buffer for that WRITE SAME command. The protection information returned by a read of an unmapped LBA is set to FFFF_FFFF_FFFF_FFFFh (see 4.7.4.5). === during processing of the second writesame of the physical block, since the physical block is now all zero once this writesame16 completes, a target may trigger the whole physical block to become unmapped, eventhough this specific writesame16 was only for a fraction of the block. It is allowed to unmap the block, but not required to. or it could do it at a later time. For example, a target is allowed to have say a background scan-and-unmap process that goes through the disk and unmaps all all-zero physical blocks : I dont know if your target would do this. Would be neat to add this to STGT. SBC 4.7.3.5 : === 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 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. === I.e. a target is allowed at any time to automatically unmap physical blocks as long as the block is all zero and lbprz is set. > otherwise i will have to add support for honoring this values in qemu-img > convert > as a follow up. > > Peter >
