<p dir="ltr"><br>
On Nov 20, 2014 8:39 AM, "Dietmar Maurer" <<a href="mailto:dietmar@proxmox.com">dietmar@proxmox.com</a>> wrote:<br>
><br>
> > Again, migration code flush all changes to disk, so there are no "out of sync"<br>
> > blocks<br>
> > after migration. What do I miss?<br>
> ><br>
> > I'll try to explain within more details.<br>
> > When write cache is enabled then KVM process write, write and write. It doesn't<br>
> > care about what really happen to this data after it goes to buffer.<br>
><br>
> Sorry, but we use "cache=none", so cache is not enabled (what cache do you talk exactly?).</p>
<p dir="ltr">Cache=none means no host cache but backend cache is still in use. In case of DRBD this is a buffer in DRBD. So O_DIRECT return OK when data reaches this buffer and not RAID cache.<br></p>
<p dir="ltr">> > What DRBD does it is writing data from buffer to both nodes but DRBD can't do<br>
> > this simultaneously. So it writes data to local node first and then to another<br>
> > node. Between these 'writes' data in buffer can be changed and nobody know it<br>
> > was changed. So every time data is written DRBD can't be sure that data written<br>
> > locally and data written remotely are identical.<br>
> > Why barriers usually helps? Because OS inside VM doesn't write anything until<br>
> > 'data is committed' message received from DRBD. 'Data<br>
> >  is committed' comes from DRBD when real data committed to both nodes, local<br>
> > and remote.<br>
><br>
> Right. Both, the VM kernel, and the KVM migration code issue a flush when required.<br>
> So you never end up in inconsistent state.<br>
><br>
> Migration would never work if above theory is correct. But it works perfectly<br>
> with iSCSI, NFS, glusterfs, ceph, ...</p>
<p dir="ltr">The difference is that iSCSI and NFS have only one backend device and buffer is not local but remote, but DRBD has at least two backends connected by network. I don't know how ceph and glusterfs work in details, never used/learned.<br>
</p>