Re: [Qemu-devel] Regression: block: Add .bdrv_co_pwrite_zeroes()

[Paolo Bonzini <pbonzini@redhat.com>]

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.