On 11/08/2016 05:03 AM, Peter Lieven wrote:
> Am 25.10.2016 um 18:12 schrieb Eric Blake:
>> On 10/25/2016 09:36 AM, Paolo Bonzini wrote:
>>>
>>> On 25/10/2016 16:35, Eric Blake wrote:
So your argument is that we should always pass down every unaligned
less-than-optimum discard request
On 11/08/2016 05:03 AM, Peter Lieven wrote:
> Am 25.10.2016 um 18:12 schrieb Eric Blake:
>> On 10/25/2016 09:36 AM, Paolo Bonzini wrote:
>>>
>>> On 25/10/2016 16:35, Eric Blake wrote:
So your argument is that we should always pass down every unaligned
less-than-optimum discard request
Am 25.10.2016 um 18:12 schrieb Eric Blake:
On 10/25/2016 09:36 AM, Paolo Bonzini wrote:
On 25/10/2016 16:35, Eric Blake wrote:
So your argument is that we should always pass down every unaligned
less-than-optimum discard request all the way to the hardware, rather
than dropping it higher in
On 25/10/2016 16:35, Eric Blake wrote:
> So your argument is that we should always pass down every unaligned
> less-than-optimum discard request all the way to the hardware, rather
> than dropping it higher in the stack, even though discard requests are
> already advisory, in order to leave the
On 10/25/2016 09:20 AM, Peter Lieven wrote:
>> The firmware is probably technically buggy for advertising too large of
>> a minimum granularity, if it can piece together smaller requests into a
>> larger discard. If discards need to happen at a smaller granularity,
>> the firmware (or kernel
Am 25.10.2016 um 15:59 schrieb Eric Blake:
On 10/25/2016 07:42 AM, Peter Lieven wrote:
But hey, that firmware is seriously weird. :)
Yes, so you would not change the new implementation?
Even if the discard is e.g. 1MB it could theretically be that internally
the device has a finer
On 10/25/2016 07:42 AM, Peter Lieven wrote:
>>
>> But hey, that firmware is seriously weird. :)
>
> Yes, so you would not change the new implementation?
>
> Even if the discard is e.g. 1MB it could theretically be that internally
> the device has a finer granularity. Its an optimal discard
Am 25.10.2016 um 14:19 schrieb Paolo Bonzini:
On 25/10/2016 14:12, Peter Lieven wrote:
Am 25.10.2016 um 14:09 schrieb Paolo Bonzini:
On 25/10/2016 14:03, Peter Lieven wrote:
Am 01.08.2016 um 11:22 schrieb Paolo Bonzini:
On 28/07/2016 04:39, Eric Blake wrote:
On 07/27/2016 01:25 AM, Fam
On 25/10/2016 14:12, Peter Lieven wrote:
> Am 25.10.2016 um 14:09 schrieb Paolo Bonzini:
>>
>> On 25/10/2016 14:03, Peter Lieven wrote:
>>> Am 01.08.2016 um 11:22 schrieb Paolo Bonzini:
On 28/07/2016 04:39, Eric Blake wrote:
> On 07/27/2016 01:25 AM, Fam Zheng wrote:
>> On Thu,
Am 25.10.2016 um 14:09 schrieb Paolo Bonzini:
On 25/10/2016 14:03, Peter Lieven wrote:
Am 01.08.2016 um 11:22 schrieb Paolo Bonzini:
On 28/07/2016 04:39, Eric Blake wrote:
On 07/27/2016 01:25 AM, Fam Zheng wrote:
On Thu, 07/21 13:34, Eric Blake wrote:
+max_write_zeroes =
On 25/10/2016 14:03, Peter Lieven wrote:
> Am 01.08.2016 um 11:22 schrieb Paolo Bonzini:
>>
>> On 28/07/2016 04:39, Eric Blake wrote:
>>> On 07/27/2016 01:25 AM, Fam Zheng wrote:
On Thu, 07/21 13:34, Eric Blake wrote:
> +max_write_zeroes = max_write_zeroes / alignment * alignment;
Am 01.08.2016 um 11:22 schrieb Paolo Bonzini:
On 28/07/2016 04:39, Eric Blake wrote:
On 07/27/2016 01:25 AM, Fam Zheng wrote:
On Thu, 07/21 13:34, Eric Blake wrote:
+max_write_zeroes = max_write_zeroes / alignment * alignment;
Not using QEMU_ALIGN_DOWN despite patch 3?
Looks like I
On 28/07/2016 04:39, Eric Blake wrote:
> On 07/27/2016 01:25 AM, Fam Zheng wrote:
>> On Thu, 07/21 13:34, Eric Blake wrote:
>>> +max_write_zeroes = max_write_zeroes / alignment * alignment;
>>
>> Not using QEMU_ALIGN_DOWN despite patch 3?
>
> Looks like I missed that on the rebase. Can fix
On 07/27/2016 01:25 AM, Fam Zheng wrote:
> On Thu, 07/21 13:34, Eric Blake wrote:
>> +max_write_zeroes = max_write_zeroes / alignment * alignment;
>
> Not using QEMU_ALIGN_DOWN despite patch 3?
Looks like I missed that on the rebase. Can fix if there is a reason for
a respin.
--
Eric Blake
On Thu, 07/21 13:34, Eric Blake wrote:
> +max_write_zeroes = max_write_zeroes / alignment * alignment;
Not using QEMU_ALIGN_DOWN despite patch 3?
On Thu, Jul 21, 2016 at 01:34:48PM -0600, Eric Blake wrote:
> Dell Equallogic iSCSI SANs have a very unusual advertised geometry:
>
> $ iscsi-inq -e 1 -c $((0xb0)) iscsi://XXX/0
> wsnz:0
> maximum compare and write length:1
> optimal transfer length granularity:0
> maximum transfer length:0
>
Dell Equallogic iSCSI SANs have a very unusual advertised geometry:
$ iscsi-inq -e 1 -c $((0xb0)) iscsi://XXX/0
wsnz:0
maximum compare and write length:1
optimal transfer length granularity:0
maximum transfer length:0
optimal transfer length:0
maximum prefetch xdread xdwrite transfer length:0
17 matches
Mail list logo
