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

[Peter Lieven]

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

Okay, that was how I am using for ages now ;-)

As we use that allocationmap case currenlty mainly for bigger block operations
I would personally leave it as a hint only. I don't think that making
the allocation info more than a hint will bring that big benefit. A guest
will likely not access to much unallocation pages. The whole thing could
only be useful for cheating in benchmarks. Which I would not consider
a valid use case for potentially taking risk of breaking things.

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?


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

In this case cache.direct = (driver != iscsi)

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

Good point. Will consider this as well. Wouldn't it be good to have
a cheat sheet somewhere with all that info?

Peter