<div dir="auto">Hi Richard,<div dir="auto">Can you tell, please, if the daemon at the appliance side is multithreaded as well and is able to execute several simultaneous reads, for example? If yes, how many threads it uses? Or every request starts its own thread?</div><div dir="auto"><br></div><div dir="auto">Thanks much,</div><div dir="auto"><br></div><div dir="auto">Maxim.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Oct 18, 2017 2:17 AM, "Maxim Kozover" <<a href="mailto:maximkoz@gmail.com" target="_blank">maximkoz@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Richard!</div><div>Finally it seems it works after removing <span class="m_5638235669319989193m_-2740846920214734894gmail-m_-7622581311322325474gmail-im">ACQUIRE_LOCK_FOR_CURRENT_SCOPE in guestfs_mount_local_run and throwing away all directory cache code.</span></div><div><span class="m_5638235669319989193m_-2740846920214734894gmail-m_-7622581311322325474gmail-im">Although
 I didn't try to mix fuse libguestfs client with other clients, I think 
guestfs_mount_local_run shouldn't take that specific lock as the 
function won't exit until umount and will sit in the loop. I think it 
does nothing libguestfs-related, only fuse loop activation.</span></div><div><span class="m_5638235669319989193m_-2740846920214734894gmail-m_-7622581311322325474gmail-im">What I don't understand is how that lock in guestfs_mount_local_run didn't make problems with single threaded fuse_loop.</span></div><div><span class="m_5638235669319989193m_-2740846920214734894gmail-m_-7622581311322325474gmail-im">I'll try to run it a bit more to see if any problems are seen.</span></div><div><span class="m_5638235669319989193m_-2740846920214734894gmail-m_-7622581311322325474gmail-im">If
 everything is OK (hope not a false success as directory lists are 
slower and race condition maybe less likely), then it should be worth to
 see why directory cache made problems, maybe guard it with the same 
lock or different one?</span></div><div><span class="m_5638235669319989193m_-2740846920214734894gmail-m_-7622581311322325474gmail-im">What do you think, Richard?</span></div><div><span class="m_5638235669319989193m_-2740846920214734894gmail-m_-7622581311322325474gmail-im"><br></span></div><div><span class="m_5638235669319989193m_-2740846920214734894gmail-m_-7622581311322325474gmail-im">Many thanks for your prompt help,</span></div><div><span class="m_5638235669319989193m_-2740846920214734894gmail-m_-7622581311322325474gmail-im"><br></span></div><span class="m_5638235669319989193m_-2740846920214734894gmail-m_-7622581311322325474gmail-im">Maxim.</span></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 18, 2017 at 1:39 AM, Richard W.M. Jones <span dir="ltr"><<a href="mailto:rjones@redhat.com" target="_blank">rjones@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Wed, Oct 18, 2017 at 01:33:49AM +0300, Maxim Kozover wrote:<br>
> Hi Richard!<br>
> Maybe the function guestfs_mount_local_run shouldn't<br>
> ACQUIRE_LOCK_FOR_CURRENT_SCOPE as it doesn't talk with the daemon and sits<br>
> in the loop? What do you think?<br>
<br>
</span>The lock is needed for any access to the guestfs_h structure, so I'm<br>
pretty sure that is not safe.<br>
<span><br>
> If I remove it from guestfs_mount_local_run (in lib/action-1.c, don't know<br>
> how to properly remove it from ml generator), fuse_loop_mt works, but I<br>
> still don't understand how it worked with fuse_loop (single threaded) when<br>
> guestfs_mount_local_run did ACQUIRE_LOCK_FOR_CURRENT_SCOPE<wbr>.<br>
> Unfortunately multiple ls -lR to the same directory tree lead to crash<br>
> while it seems multiple ls -lR to different directory trees (if not<br>
> repeated for a while) don't lead to crash, so I suspect directory cache in<br>
> fuse without guard.<br>
> Is there a quick way to disable the directory cache in fuse so I can see if<br>
> it is directory cache that leads to crash or we have to look at other parts?<br>
<br>
</span>You could try removing the directory cache altogether from the FUSE<br>
code (it may run much more slowly).<br>
<span class="m_5638235669319989193m_-2740846920214734894im m_5638235669319989193m_-2740846920214734894HOEnZb"><br>
Rich.<br>
<br>
--<br>
Richard Jones, Virtualization Group, Red Hat <a href="http://people.redhat.com/~rjones" rel="noreferrer" target="_blank">http://people.redhat.com/~rjon<wbr>es</a><br>
Read my programming and virtualization blog: <a href="http://rwmj.wordpress.com" rel="noreferrer" target="_blank">http://rwmj.wordpress.com</a><br>
</span><div class="m_5638235669319989193m_-2740846920214734894HOEnZb"><div class="m_5638235669319989193m_-2740846920214734894h5">virt-builder quickly builds VMs from scratch<br>
<a href="http://libguestfs.org/virt-builder.1.html" rel="noreferrer" target="_blank">http://libguestfs.org/virt-bui<wbr>lder.1.html</a><br>
</div></div></blockquote></div><br></div>
</blockquote></div></div>