<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 19, 2014 at 9:34 PM, Dietmar Maurer <span dir="ltr"><<a href="mailto:dietmar@proxmox.com" target="_blank">dietmar@proxmox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><br>
</span>Again, migration code flush all changes to disk, so there are no "out of sync" blocks<br>
after migration. What do I miss?<br>
<br>
</blockquote></div><br></div><div class="gmail_extra">I'll try to explain within more details.<br><br></div><div class="gmail_extra">When write cache is enabled then KVM process write, write and write. It doesn't care about what really happen to this data after it goes to buffer.<br><br></div><div class="gmail_extra">What DRBD does it is  writing data from buffer to both nodes but DRBD can't do this simultaneously. So it writes data to local node first and then to another node. Between these 'writes' data in buffer can be changed and nobody know it was changed. So every time data is written DRBD can't be sure that data written locally and data written remotely are identical.<br><br></div><div class="gmail_extra">Why barriers usually helps? Because OS inside VM doesn't write anything until  'data is committed' message received from DRBD. 'Data<br></div><div class="gmail_extra"> is committed' comes from DRBD when real data committed to both nodes, local and remote.<br><br></div><div class="gmail_extra">When O_DSYNC is in use (directsync and writethrough modes)  then KVM itself waits for 'data is written' message from DRBD and doesn't update buffer before this message received. So we don't need to care what is happening inside a VM.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Stanislav<br></div></div>