qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] RFC iscsi: set FUA and DPO if !bs->enable_write_cache


From: Paolo Bonzini
Subject: Re: [Qemu-block] RFC iscsi: set FUA and DPO if !bs->enable_write_cache
Date: Thu, 16 Apr 2015 11:59:26 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0


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 removing that additional check, implementing
> invalidate
> cache and making the allocationmap tri-state (unknown, allocated,
> unallocated)?

So that should be okay.  Looks like cache.direct=no is migration-safe
for the libiscsi driver.

>> If I were you:
>>
>> - I would switch to the cache.foo options, they're clearer and permit
>> finer-grained configuration.
>>
>> - I would never use cache.direct=no if you know you're doing migration,
>> until bdrv_invalidate_cache is implemented.  After that, you can always
>> use cache.direct=no with libiscsi except if multiple servers are sharing
>> the disk.
>>
>> - I would always use cache.writeback=yes if you know you're using
>> virtio-blk (which falls back to cache.writeback=no) or if the guest is
>> reasonably recent (2.6.32+ kernel; or any Windows as I'm not aware of
>> any change regarding flushes there).
>>
>> - I would use file.cache.no-flush=yes if you know you're on
>> battery-backed storage.
> 
> That sounds reasonable. Thanks for the clarification.

Thanks for confirming too. :)

BTW, using virtio-scsi also falls under "the guest is reasonably recent"
and can do flushes.  The driver was committed around 3.4 and AFAIK only
backported to RHEL6 and some other 3.x-ish Fedora kernels.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]