On 21/07/2016 09:01, Peter Lieven wrote: > > maximum unmap lba count:30720 > maximum unmap block descriptor count:2 > optimal unmap granularity:30720 > ugavalid:1 > unmap granularity alignment:0 > maximum write same length:30720
Uhm, that's weird. The optimal unmap granularity should really be the minimum discard size. But since this is what the storage gives us, I still prefer to do the division and support non-power-of-two optimal unmap granularity (aka optimal discard alignment in QEMU parlance). Paolo > > > >> >> Also, while the device is advertising that the optimal discard alignment >> is 15M, that does not tell me the minimum granularity that it can >> actually discard. Can you determine that value? That is, if I try to >> discard only 1M, does that actually result in a 1M allocation hole, or >> is it ignored? It sounds like qemu should be tracking 2 separate >> values: the minimum discard granularity (I suspect this number is a >> power of 2, at least the block size, and perhaps precisely equal to the >> block size), and the maximum discard granularity that results in the >> fewest/fastest discard of the entire device (not necessarily a power of >> 2). Or, maybe that merely means that qemu's pdiscard_alignment should >> be the MINIMUM granularity, and NOT the non-power-of-2 >> iscsilun->bl.opt_unmap_gran. > > As far as I know there is no minimum discard granularity. Only optimum > and maximum. > > >> >> Or put another way, I get that I can't discard more than 15M at a time. >> But I highly suspect that I do not have to align my discard requests to >> 15M boundaries. That is, if the discard granularity is 1M, then in >> qemu-io, 'discard 1M 15M' should result in a 15M hole, and should be no >> different from the result of 'discard 1M 14M; discard 15M 1M'. But if >> qemu sticks to pdiscard_alignment == iscsilun->bl.opt_unmap_gran of 15M, >> then both operations mistakenly discard nothing (because it is not >> aligned to a 15M boundary). > > I do not know what the storage does internally. But I agree the block > provisioning info will not change. However, if you issue a discard 1M 15M > and later a discard 0 1M it still might to report the first block as > unallocated > later.
