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

Re: [libvirt] PATCH: Disable QEMU drive caching

Daniel Veillard wrote:
On Wed, Oct 08, 2008 at 10:51:16AM -0500, Anthony Liguori wrote:
Daniel P. Berrange wrote:
 - It is unsafe on host OS crash - all unflushed guest I/O will be
   lost, and there's no ordering guarentees, so metadata updates could
   be flushe to disk, while the journal updates were not. Say goodbye
   to your filesystem.
This has nothing to do with cache=off. The IDE device defaults to write-back caching. As such, IDE makes no guarantee that when a data write completes, it's actually completed on disk. This only comes into play when write-back is disabled. I'm perfectly happy to accept a patch that adds explicit sync's when write-back is disabled.

For SCSI, an unordered queue is advertised. Again, everything depends on whether or not write-back caching is enabled or not. Again, perfectly happy to take patches here.

More importantly, the most common journaled filesystem, ext3, does not enable write barriers by default (even for journal updates). This is how it ship in Red Hat distros. So there is no greater risk of corrupting a journal in QEMU than there is on bare metal.

  Interesting discussion, I'm wondering about the non-local storage
effect though, if the Node is caching writes, how can we ensure a
coherent view on remote storage for example when migrating a domain ?

In the case of remote storage, cache coherency is part of the network storage protocol/architecture. In NFS for instance, the most common coherency model is close-to-open. Other network storage solutions provide stronger coherency models.

Maybe migration is easy to fix because qemu is aware and can issue a
sync, but as we start adding cloning APIs to libvirt, we could face the
issue if issuing an LVM snapshot operation on the guest storage while
the Node still cache some of the data. The more layers of caching the
harder it is to have a predictable behaviour, no ?

With respect to migration, QEMU does a flush(), but not an fdatasync. Even if we did an fdatasync, I'm not sure that's good enough with NFS because I don't know if fdatasync on the source *after* the target has opened a file and read data will guarantee consistency.


Anthony Liguori


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