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
