On 07/21/2016 03:08 AM, Paolo Bonzini wrote:
>
>
> On 21/07/2016 01:35, Eric Blake wrote:
>> 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,
On 21/07/2016 01:35, Eric Blake wrote:
> 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 resu
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
Hi Eric,
Am 21.07.2016 um 01:35 schrieb Eric Blake:
On 07/04/2016 07:49 AM, Peter Lieven wrote:
Hi,
the above commit:
commit d05aa8bb4a8b6aa9a915ec5074fb12ae632d2323
Author: Eric Blake
Date: Wed Jun 1 15:10:03 2016 -0600
block: Add .bdrv_co_pwrite_zeroes()
introduces a regression (a
Sorry, reply is wrong.
在 2016年07月21日 09:38, wangweiwei 写道:
在 2016年07月20日 19:35, Eric Blake 写道:
On 07/04/2016 07:49 AM, Peter Lieven wrote:
Hi,
the above commit:
commit d05aa8bb4a8b6aa9a915ec5074fb12ae632d2323
Author: Eric Blake
Date: Wed Jun 1 15:10:03 2016 -0600
block: Add .bdrv_co
在 2016年07月20日 19:35, Eric Blake 写道:
On 07/04/2016 07:49 AM, Peter Lieven wrote:
Hi,
the above commit:
commit d05aa8bb4a8b6aa9a915ec5074fb12ae632d2323
Author: Eric Blake
Date: Wed Jun 1 15:10:03 2016 -0600
block: Add .bdrv_co_pwrite_zeroes()
introduces a regression (at least for me).
On 07/04/2016 07:49 AM, Peter Lieven wrote:
> Hi,
>
> the above commit:
>
> commit d05aa8bb4a8b6aa9a915ec5074fb12ae632d2323
> Author: Eric Blake
> Date: Wed Jun 1 15:10:03 2016 -0600
>
> block: Add .bdrv_co_pwrite_zeroes()
>
> introduces a regression (at least for me).
>
> The Limits fr
Am 15.07.2016 um 17:40 schrieb Eric Blake:
On 07/15/2016 04:09 AM, Peter Lieven wrote:
Am 05.07.2016 um 17:09 schrieb Paolo Bonzini:
On 05/07/2016 16:59, Eric Blake wrote:
And yes, we could probably switch to (potentially slower) / % * instead
of bit operations in block/io.c to accommodate a n
On 07/15/2016 04:09 AM, Peter Lieven wrote:
> Am 05.07.2016 um 17:09 schrieb Paolo Bonzini:
>>
>> On 05/07/2016 16:59, Eric Blake wrote:
>>> And yes, we could probably switch to (potentially slower) / % * instead
>>> of bit operations in block/io.c to accommodate a non-power-of-2 optimal
>>> size,
Am 05.07.2016 um 17:09 schrieb Paolo Bonzini:
>
> On 05/07/2016 16:59, Eric Blake wrote:
>> And yes, we could probably switch to (potentially slower) / % * instead
>> of bit operations in block/io.c to accommodate a non-power-of-2 optimal
>> size, but it would require a careful audit to make sure w
On 05/07/2016 16:59, Eric Blake wrote:
> And yes, we could probably switch to (potentially slower) / % * instead
> of bit operations in block/io.c to accommodate a non-power-of-2 optimal
> size, but it would require a careful audit to make sure we don't have
> even more bit-wise operations lurkin
On 07/05/2016 07:37 AM, Paolo Bonzini wrote:
>
>
> On 05/07/2016 03:53, Eric Blake wrote:
I think we cannot assert that that these alignments are a power of 2.
>> Perhaps that means we should just fix our code to round things down to
>> the nearest power of 2 (8MB) for the opt_transfer_len a
Am 05.07.2016 um 15:37 schrieb Paolo Bonzini:
On 05/07/2016 03:53, Eric Blake wrote:
I think we cannot assert that that these alignments are a power of 2.
Perhaps that means we should just fix our code to round things down to
the nearest power of 2 (8MB) for the opt_transfer_len and
opt_discar
On 05/07/2016 15:03, Eric Blake wrote:
> bs->bl.pwrite_zeroes_alignment =
> -iscsilun->bl.opt_unmap_gran * iscsilun->block_size;
> +pow2floor(iscsilun->bl.opt_unmap_gran * iscsilun->block_size);
> } else {
> bs->bl.pwrite_zeroes_alignment = iscsilun-
On 05/07/2016 03:53, Eric Blake wrote:
>> > I think we cannot assert that that these alignments are a power of 2.
> Perhaps that means we should just fix our code to round things down to
> the nearest power of 2 (8MB) for the opt_transfer_len and
> opt_discard_alignment values. Can you post a st
On 07/05/2016 01:30 AM, Peter Lieven wrote:
> Am 05.07.2016 um 03:53 schrieb Eric Blake:
>> On 07/04/2016 07:49 AM, Peter Lieven wrote:
>>> Hi,
>>>
>>> the above commit:
>>>
>>> commit d05aa8bb4a8b6aa9a915ec5074fb12ae632d2323
>>> Author: Eric Blake
>>> Date: Wed Jun 1 15:10:03 2016 -0600
>>>
>>>
Am 05.07.2016 um 03:53 schrieb Eric Blake:
On 07/04/2016 07:49 AM, Peter Lieven wrote:
Hi,
the above commit:
commit d05aa8bb4a8b6aa9a915ec5074fb12ae632d2323
Author: Eric Blake
Date: Wed Jun 1 15:10:03 2016 -0600
block: Add .bdrv_co_pwrite_zeroes()
introduces a regression (at least fo
On 07/04/2016 07:49 AM, Peter Lieven wrote:
> Hi,
>
> the above commit:
>
> commit d05aa8bb4a8b6aa9a915ec5074fb12ae632d2323
> Author: Eric Blake
> Date: Wed Jun 1 15:10:03 2016 -0600
>
> block: Add .bdrv_co_pwrite_zeroes()
>
> introduces a regression (at least for me).
>
> The Limits fr
Hi,
the above commit:
commit d05aa8bb4a8b6aa9a915ec5074fb12ae632d2323
Author: Eric Blake
Date: Wed Jun 1 15:10:03 2016 -0600
block: Add .bdrv_co_pwrite_zeroes()
introduces a regression (at least for me).
The Limits from the iSCSI Block Limits VPD have no requirement of being a power
o
19 matches
Mail list logo