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

[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 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