On 16/04/2015 14:43, Kevin Wolf wrote:
> > Of course cache=unsafe and cache.no-flush=on are not a good idea because
> > you want to flush the qcow2 caches for example.
>
> Actually, cache=unsafe doesn't disable qcow2 cache writeback. That's the
> difference between .bdrv_co_flush_to_os as used b
Am 15.04.2015 um 11:03 hat Paolo Bonzini geschrieben:
> > cachemode unsafe avoids the explicit flush which is no good idea as
> > we all would agree.
>
> Actually, in the case of battery-backed cache file.cache.no-flush=on
> (aka file.cache=unsafe) _is_ a good idea, because arrays with
> battery-b
Am 16.04.2015 um 13:34 schrieb Paolo Bonzini:
On 16/04/2015 12:23, Peter Lieven wrote:
But in this case we should be allowed to move the restriction of
using the allocation map only if cache.direct = no or shouldn't we?
Now that I understood the code better, probably we can remove the
restrict
On 16/04/2015 12:23, Peter Lieven wrote:
> But in this case we should be allowed to move the restriction of
> using the allocation map only if cache.direct = no or shouldn't we?
Now that I understood the code better, probably we can remove the
restriction, yes.
> In this case cache.direct = (dr
Am 16.04.2015 um 11:59 schrieb Paolo Bonzini:
On 16/04/2015 11:54, Peter Lieven wrote:
That allocation cache in the iSCSI driver is only a hint. It always
confirms blocks
are really unallocated before taking the fast path returning zeroes.
So I don't think it is necessary to add invalidate cach
On 16/04/2015 11:54, Peter Lieven wrote:
> That allocation cache in the iSCSI driver is only a hint. It always
> confirms blocks
> are really unallocated before taking the fast path returning zeroes.
> So I don't think it is necessary to add invalidate cache, or is it?
> Or would you vote for rem
Am 16.04.2015 um 11:37 schrieb Paolo Bonzini:
On 16/04/2015 09:16, Peter Lieven wrote:
Thanks for the clarification. At first glance its not that obvious.
There is one thing I want to mention none is not exactly writeback
and directsync not exactly writethrough. We do not enable the
iscsi->all
On 16/04/2015 09:16, Peter Lieven wrote:
> Thanks for the clarification. At first glance its not that obvious.
>
> There is one thing I want to mention none is not exactly writeback
> and directsync not exactly writethrough. We do not enable the
> iscsi->allocationmap if BRDV_O_NOCACHE is in the
Am 15.04.2015 um 11:03 schrieb Paolo Bonzini:
On 14/04/2015 21:55, Peter Lieven wrote:
Am 14.04.2015 um 18:15 schrieb Paolo Bonzini:
On 14/04/2015 08:49, Peter Lieven wrote:
Hi,
Ronnie came up with an idea to reduce latency if !bs->enable_write_cache
for an iSCSI device.
If !bs->enable_writ
On 14/04/2015 21:55, Peter Lieven wrote:
> Am 14.04.2015 um 18:15 schrieb Paolo Bonzini:
>>
>> On 14/04/2015 08:49, Peter Lieven wrote:
>>> Hi,
>>>
>>> Ronnie came up with an idea to reduce latency if !bs->enable_write_cache
>>> for an iSCSI device.
>>>
>>> If !bs->enable_write_cache Qemu sends a
Sounds good to me.
On Tue, Apr 14, 2015 at 12:59 PM, Peter Lieven wrote:
> Am 14.04.2015 um 21:55 schrieb Peter Lieven:
>> Am 14.04.2015 um 18:15 schrieb Paolo Bonzini:
>>> On 14/04/2015 08:49, Peter Lieven wrote:
Hi,
Ronnie came up with an idea to reduce latency if !bs->enable_wri
Am 14.04.2015 um 21:55 schrieb Peter Lieven:
> Am 14.04.2015 um 18:15 schrieb Paolo Bonzini:
>> On 14/04/2015 08:49, Peter Lieven wrote:
>>> Hi,
>>>
>>> Ronnie came up with an idea to reduce latency if !bs->enable_write_cache
>>> for an iSCSI device.
>>>
>>> If !bs->enable_write_cache Qemu sends a
Am 14.04.2015 um 18:15 schrieb Paolo Bonzini:
>
> On 14/04/2015 08:49, Peter Lieven wrote:
>> Hi,
>>
>> Ronnie came up with an idea to reduce latency if !bs->enable_write_cache
>> for an iSCSI device.
>>
>> If !bs->enable_write_cache Qemu sends a flush after every single write.
>> What could be don
On 14/04/2015 11:04, Stefan Hajnoczi wrote:
> Do other commands besides writes rely on iscsi_co_flush()?
>
> Paolo: I checked NBD and noticed there is an inconsistency there.
> nbd_co_writev_1() uses FUA when bs->enable_write_cache == true but it
> also sends flushes. Does that mean it's doing
On 14/04/2015 08:49, Peter Lieven wrote:
> Hi,
>
> Ronnie came up with an idea to reduce latency if !bs->enable_write_cache
> for an iSCSI device.
>
> If !bs->enable_write_cache Qemu sends a flush after every single write.
> What could be done is
> the following:
>
> if (!bs->enable_write_cach
Am 14.04.2015 um 11:04 schrieb Stefan Hajnoczi:
On Tue, Apr 14, 2015 at 7:49 AM, Peter Lieven wrote:
Ronnie came up with an idea to reduce latency if !bs->enable_write_cache for
an iSCSI device.
If !bs->enable_write_cache Qemu sends a flush after every single write. What
could be done is
the f
On Tue, Apr 14, 2015 at 7:49 AM, Peter Lieven wrote:
> Ronnie came up with an idea to reduce latency if !bs->enable_write_cache for
> an iSCSI device.
>
> If !bs->enable_write_cache Qemu sends a flush after every single write. What
> could be done is
> the following:
>
> if (!bs->enable_write_cach
Hi,
Ronnie came up with an idea to reduce latency if !bs->enable_write_cache for an
iSCSI device.
If !bs->enable_write_cache Qemu sends a flush after every single write. What
could be done is
the following:
if (!bs->enable_write_cache)
set FUA (force unit access) and DPO (disable page out) b
18 matches
Mail list logo
