<div dir="ltr"><div><div>Alexandre,<br><br>> do you see the problem with qemu cache=directsync ? (O_DIRECT + O_DSYNC).<br></div>Yes, it happens in less number of cases (may be 10 times less) but still happens. I have a reproducible case with Windows 7 and directsync.<br><br></div>Stanislav<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 28, 2015 at 11:18 AM, Alexandre DERUMIER <span dir="ltr"><<a href="mailto:aderumier@odiso.com" target="_blank">aderumier@odiso.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>>Resume: when working in O_DIRECT mode QEMU has to wait until "write" system call is finished before changing this buffer OR QEMU has to create new buffer every time OR ... other ideas?<br>
<br>
</span>AFAIK, only O_DSYNC can guarantee that data are really written to the last layer(disk platters)<br>
<br>
That's why we need to use barrier or FUA in last kernel in guest, when using O_DIRECT, to be sure that guest filesystem is ok and datas are flushed at regular interval.<br>
(To avoid incoherent filesystem with datas).<br>
<br>
<br>
do you see the problem with qemu cache=directsync ? (O_DIRECT + O_DSYNC).<br>
<span class=""><br>
<br>
<br>
<br>
<br>
----- Mail original -----<br>
De: "Stanislav German-Evtushenko" <<a href="mailto:ginermail@gmail.com">ginermail@gmail.com</a>><br>
À: "dietmar" <<a href="mailto:dietmar@proxmox.com">dietmar@proxmox.com</a>><br>
Cc: "aderumier" <<a href="mailto:aderumier@odiso.com">aderumier@odiso.com</a>>, "pve-devel" <<a href="mailto:pve-devel@pve.proxmox.com">pve-devel@pve.proxmox.com</a>><br>
</span>Envoyé: Jeudi 28 Mai 2015 09:54:32<br>
<span class="im HOEnZb">Objet: Re: [pve-devel] Default cache mode for VM hard drives<br>
<br>
</span><div class="HOEnZb"><div class="h5">Dietmar,<br>
<br>
fsync esures that data reaches underlying hardware but it does not help being sure that buffer is not changed until it is fully written.<br>
<br>
I will describe my understanding here why we get this problem with O_DIRECT and don't have without.<br>
<br>
** Without O_DIRECT **<br>
1. Application tries to write data from buffer<br>
2. Data from buffer goes to host cache<br>
3. RAID writers get data from host cache and put to /dev/loop1 and /dev/loop2<br>
Even if buffer changes data in host cache will not be changed so RAID is consistent.<br>
<br>
** With O_DIRECT **<br>
1. Application tries to write data from buffer<br>
2. RAID writers get data from application (!!!) bufferand put to /dev/loop1 and /dev/loop2<br>
if meanwhile data in buffer is changed (this change can be done in different posix thread) then we have different data reachs /dev/loop1 and /dev/loop2<br>
<br>
Resume: when working in O_DIRECT mode QEMU has to wait until "write" system call is finished before changing this buffer OR QEMU has to create new buffer every time OR ... other ideas?<br>
<br>
Stanislav<br>
<br>
On Thu, May 28, 2015 at 10:31 AM, Dietmar Maurer < <a href="mailto:dietmar@proxmox.com">dietmar@proxmox.com</a> > wrote:<br>
<br>
<br>
> I have just done the same test with mdadm and not DRBD. And what I found<br>
> that this problem was reproducible on the software raid too, just as it was<br>
> claimed by Lars Ellenberg. It means that problem is not only related to<br>
> DRBD but to O_DIRECT mode generally when we don't use host cache and a<br>
> block device reads data directly from userspace.<br>
<br>
We simply think the behavior is correct. If you want to be sure data is<br>
on disk you have to call fsync.<br>
<br>
<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><a href="http://www.helplinux.ru" target="_blank">www.helplinux.ru</a> - Найди себе Гуру</div>
</div>