<div dir="ltr"><div>Hi Martin,<br></div><div><br></div><div>Glad it worked! And yes, 3.7.6 is really old! :)<br></div><div><br></div><div>So the issue is occurring when the vm flushes outstanding data to disk. And this</div><div>is taking &gt; 120s because there&#39;s lot of buffered writes to flush, possibly followed</div><div>by an fsync too which needs to sync them to disk (volume profile would have</div><div>been helpful in confirming this). All these two options do is to truly honor O_DIRECT flag</div><div>(which is what we want anyway given the vms are opened with &#39;cache=none&#39; qemu option).</div><div>This will skip write-caching on gluster client side and also bypass the page-cache on the</div><div>gluster-bricks, and so data gets flushed faster, thereby eliminating these timeouts.<br></div><div><br></div><div>-Krutika</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 20, 2019 at 3:38 PM Martin &lt;<a href="mailto:snowmailer@gmail.com" target="_blank">snowmailer@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hi Krutika,<div><br></div><div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>Also, gluster version please?</div></div></div></blockquote></div><div><div dir="ltr"><div dir="ltr"><div>I am running old 3.7.6. (Yes I know I should upgrade asap)</div></div></div></div><div><br></div><div>I’ve applied firstly &quot;network.remote-dio off&quot;, behaviour did not changed, VMs got stuck after some time again.</div><div>Then I’ve set &quot;performance.strict-o-direct on&quot; and problem completly disappeared. No more stucks at all (7 days without any problems at all). This SOLVED the issue.</div><div><br></div><div>Can you explain what remote-dio and strict-o-direct variables changed in behaviour of my Gluster? It would be great for later archive/users to understand what and why this solved my issue.</div><div><br></div><div>Anyway, Thanks a LOT!!!</div><div><br></div><div>BR, </div><div>Martin<br><div><br><blockquote type="cite"><div>On 13 May 2019, at 10:20, Krutika Dhananjay &lt;<a href="mailto:kdhananj@redhat.com" target="_blank">kdhananj@redhat.com</a>&gt; wrote:</div><br class="gmail-m_454963965697663121gmail-m_2559841268257667179gmail-m_2299824393943036380gmail-m_3070072292168366260Apple-interchange-newline"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div dir="ltr"><div>OK. In that case, can you check if the following two changes help:</div><div><br></div><div># gluster volume set $VOL network.remote-dio off</div><div># gluster volume set $VOL performance.strict-o-direct on</div><div><br></div><div>preferably one option changed at a time, its impact tested and then the next change applied and tested.</div><div><br></div><div>Also, gluster version please?</div><div><br></div><div>-Krutika<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 13, 2019 at 1:02 PM Martin Toth &lt;<a href="mailto:snowmailer@gmail.com" target="_blank">snowmailer@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Cache in qemu is none. That should be correct. This is full command :<div><br></div><div>/usr/bin/qemu-system-x86_64 -name one-312 -S -machine pc-i440fx-xenial,accel=kvm,usb=off -m 4096 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid e95a774e-a594-4e98-b141-9f30a3f848c1 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-one-312/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot order=c,menu=on,splash-time=3000,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 </div><div><br></div><div>-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4</div><div>-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5</div><div>-drive file=/var/lib/one//datastores/116/312/<b>disk.0</b>,format=raw,if=none,id=drive-virtio-disk1,cache=none</div><div><span class="gmail-m_454963965697663121gmail-m_2559841268257667179gmail-m_2299824393943036380gmail-m_3070072292168366260gmail-m_-188449303254556054Apple-tab-span" style="white-space:pre-wrap">        </span>-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,id=virtio-disk1</div><div>-drive file=<a>gluster://localhost:24007/imagestore/</a><b>7b64d6757acc47a39503f68731f89b8e</b>,format=qcow2,if=none,id=drive-scsi0-0-0-0,cache=none</div><div><span class="gmail-m_454963965697663121gmail-m_2559841268257667179gmail-m_2299824393943036380gmail-m_3070072292168366260gmail-m_-188449303254556054Apple-tab-span" style="white-space:pre-wrap">        </span>-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0</div><div>-drive file=/var/lib/one//datastores/116/312/<b>disk.1</b>,format=raw,if=none,id=drive-ide0-0-0,readonly=on</div><div><span class="gmail-m_454963965697663121gmail-m_2559841268257667179gmail-m_2299824393943036380gmail-m_3070072292168366260gmail-m_-188449303254556054Apple-tab-span" style="white-space:pre-wrap">        </span>-device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0</div><div><br></div><div>-netdev tap,fd=26,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=02:00:5c:f0:e4:39,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-one-312/org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -vnc<span class="gmail-m_454963965697663121gmail-m_2559841268257667179gmail-m_2299824393943036380gmail-m_3070072292168366260Apple-converted-space"> </span><a href="http://0.0.0.0:312/" target="_blank">0.0.0.0:312</a>,password -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on</div><div><br></div><div>I’ve highlighted disks. First is VM context disk - Fuse used, second is SDA (OS is installed here) - libgfapi used, third is SWAP - Fuse used.<br><div><br></div><div>Krutika,</div><div>I will start profiling on Gluster Volumes and wait for next VM to fail. Than I will attach/send profiling info after some VM will be failed. I suppose this is correct profiling strategy.</div></div></div></blockquote><div><br></div><div>About this, how many vms do you need to recreate it? A single vm? Or multiple vms doing IO in parallel?<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><br></div><div>Thanks,</div><div>BR!</div><div>Martin</div><div><br><blockquote type="cite"><div>On 13 May 2019, at 09:21, Krutika Dhananjay &lt;<a href="mailto:kdhananj@redhat.com" target="_blank">kdhananj@redhat.com</a>&gt; wrote:</div><br class="gmail-m_454963965697663121gmail-m_2559841268257667179gmail-m_2299824393943036380gmail-m_3070072292168366260gmail-m_-188449303254556054Apple-interchange-newline"><div><div dir="ltr"><div>Also, what&#39;s the caching policy that qemu is using on the affected vms?</div><div>Is it cache=none? Or something else? You can get this information in the command line of qemu-kvm process corresponding to your vm in the ps output.</div><div><br></div><div>-Krutika<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 13, 2019 at 12:49 PM Krutika Dhananjay &lt;<a href="mailto:kdhananj@redhat.com" target="_blank">kdhananj@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>What version of gluster are you using?</div><div>Also, can you capture and share volume-profile output for a run where you manage to recreate this issue?</div><div><a href="https://docs.gluster.org/en/v3/Administrator%20Guide/Monitoring%20Workload/#running-glusterfs-volume-profile-command" target="_blank">https://docs.gluster.org/en/v3/Administrator%20Guide/Monitoring%20Workload/#running-glusterfs-volume-profile-command</a></div><div>Let me know if you have any questions.<br></div><div><br></div><div>-Krutika<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 13, 2019 at 12:34 PM Martin Toth &lt;<a href="mailto:snowmailer@gmail.com" target="_blank">snowmailer@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br><br>there is no healing operation, not peer disconnects, no readonly filesystem. Yes, storage is slow and unavailable for 120 seconds, but why, its SSD with 10G, performance is good.<br><br>&gt; you&#39;d have it&#39;s log on qemu&#39;s standard output,<br><br>If you mean /var/log/libvirt/qemu/vm.log there is nothing. I am looking for problem for more than month, tried everything. Can’t find anything. Any more clues or leads?<br><br>BR,<br>Martin<br><br>&gt; On 13 May 2019, at 08:55,<span class="gmail-m_454963965697663121gmail-m_2559841268257667179gmail-m_2299824393943036380gmail-m_3070072292168366260Apple-converted-space"> </span><a href="mailto:lemonnierk@ulrar.net" target="_blank">lemonnierk@ulrar.net</a><span class="gmail-m_454963965697663121gmail-m_2559841268257667179gmail-m_2299824393943036380gmail-m_3070072292168366260Apple-converted-space"> </span>wrote:<br>&gt;<span class="gmail-m_454963965697663121gmail-m_2559841268257667179gmail-m_2299824393943036380gmail-m_3070072292168366260Apple-converted-space"> </span><br>&gt; On Mon, May 13, 2019 at 08:47:45AM +0200, Martin Toth wrote:<br>&gt;&gt; Hi all,<br>&gt;<span class="gmail-m_454963965697663121gmail-m_2559841268257667179gmail-m_2299824393943036380gmail-m_3070072292168366260Apple-converted-space"> </span><br>&gt; Hi<br>&gt;<span class="gmail-m_454963965697663121gmail-m_2559841268257667179gmail-m_2299824393943036380gmail-m_3070072292168366260Apple-converted-space"> </span><br>&gt;&gt;<span class="gmail-m_454963965697663121gmail-m_2559841268257667179gmail-m_2299824393943036380gmail-m_3070072292168366260Apple-converted-space"> </span><br>&gt;&gt; I am running replica 3 on SSDs with 10G networking, everything works OK but VMs stored in Gluster volume occasionally freeze with “Task XY blocked for more than 120 seconds”.<br>&gt;&gt; Only solution is to poweroff (hard) VM and than boot it up again. I am unable to SSH and also login with console, its stuck probably on some disk operation. No error/warning logs or messages are store in VMs logs.<br>&gt;&gt;<span class="gmail-m_454963965697663121gmail-m_2559841268257667179gmail-m_2299824393943036380gmail-m_3070072292168366260Apple-converted-space"> </span><br>&gt;<span class="gmail-m_454963965697663121gmail-m_2559841268257667179gmail-m_2299824393943036380gmail-m_3070072292168366260Apple-converted-space"> </span><br>&gt; As far as I know this should be unrelated, I get this during heals<br>&gt; without any freezes, it just means the storage is slow I think.<br>&gt;<span class="gmail-m_454963965697663121gmail-m_2559841268257667179gmail-m_2299824393943036380gmail-m_3070072292168366260Apple-converted-space"> </span><br>&gt;&gt; KVM/Libvirt(qemu) using libgfapi and fuse mount to access VM disks on replica volume. Can someone advice  how to debug this problem or what can cause these issues?<span class="gmail-m_454963965697663121gmail-m_2559841268257667179gmail-m_2299824393943036380gmail-m_3070072292168366260Apple-converted-space"> </span><br>&gt;&gt; It’s really annoying, I’ve tried to google everything but nothing came up. I’ve tried changing virtio-scsi-pci to virtio-blk-pci disk drivers, but its not related.<br>&gt;&gt;<span class="gmail-m_454963965697663121gmail-m_2559841268257667179gmail-m_2299824393943036380gmail-m_3070072292168366260Apple-converted-space"> </span><br>&gt;<span class="gmail-m_454963965697663121gmail-m_2559841268257667179gmail-m_2299824393943036380gmail-m_3070072292168366260Apple-converted-space"> </span><br>&gt; Any chance your gluster goes readonly ? Have you checked your gluster<br>&gt; logs to see if maybe they lose each other some times ?<br>&gt; /var/log/glusterfs<br>&gt;<span class="gmail-m_454963965697663121gmail-m_2559841268257667179gmail-m_2299824393943036380gmail-m_3070072292168366260Apple-converted-space"> </span><br>&gt; For libgfapi accesses you&#39;d have it&#39;s log on qemu&#39;s standard output,<br>&gt; that might contain the actual error at the time of the freez.<br>&gt; _______________________________________________<br>&gt; Gluster-users mailing list<br>&gt;<span class="gmail-m_454963965697663121gmail-m_2559841268257667179gmail-m_2299824393943036380gmail-m_3070072292168366260Apple-converted-space"> </span><a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>&gt;<span class="gmail-m_454963965697663121gmail-m_2559841268257667179gmail-m_2299824393943036380gmail-m_3070072292168366260Apple-converted-space"> </span><a href="https://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-users</a><br><br>_______________________________________________<br>Gluster-users mailing list<br><a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br><a href="https://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-users</a></blockquote></div></blockquote></div></div></blockquote></div></div></div></blockquote></div></div></div></blockquote></div><br></div></div></blockquote></div>