[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Regression: block: Add .bdrv_co_pwrite_zeroes()
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] Regression: block: Add .bdrv_co_pwrite_zeroes() |
Date: |
Thu, 21 Jul 2016 11:10:26 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 |
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.
- Re: [Qemu-devel] Regression: block: Add .bdrv_co_pwrite_zeroes(), (continued)
- Re: [Qemu-devel] Regression: block: Add .bdrv_co_pwrite_zeroes(), Peter Lieven, 2016/07/05
- Re: [Qemu-devel] Regression: block: Add .bdrv_co_pwrite_zeroes(), Eric Blake, 2016/07/05
- Re: [Qemu-devel] Regression: block: Add .bdrv_co_pwrite_zeroes(), Paolo Bonzini, 2016/07/05
- Re: [Qemu-devel] Regression: block: Add .bdrv_co_pwrite_zeroes(), Peter Lieven, 2016/07/15
- Re: [Qemu-devel] Regression: block: Add .bdrv_co_pwrite_zeroes(), Eric Blake, 2016/07/15
- Re: [Qemu-devel] Regression: block: Add .bdrv_co_pwrite_zeroes(), Peter Lieven, 2016/07/18
Re: [Qemu-devel] Regression: block: Add .bdrv_co_pwrite_zeroes(), Eric Blake, 2016/07/20