[Please keep replies on the mailing list so that others can benefit] On Tue, Oct 17, 2017 at 10:07:31PM +0300, Maxim Kozover wrote: > Hi Richard, > Unfortunately I achieved a negative result, maybe you could help, please? . > I'm using libguestfs-1.36.4 as a base since I changed for myself a bit some > detection stuff that you recently moved from C to OCaml and I can't rewrite > it immediately. > > WIth vanilla 1.36.4 just changing fuse_loop to fuse_loop_mt gives almost > immediate crash when the filesystem is accessed.
That's expected because plain 1.36 doesn't support multithreading, but ... > I've put the most recent gnulib, changed a bit bootstrap etc, put the > patches from https://www.redhat.com/archives/libguestfs/2017-June/ > msg00287.html and rebuilt. ... OK. > The system seems to work (with single-threaded fuse). > Changed fuse_loop to fuse_loop_mt, rebuilt and fuse is stuck on the first > call to appropriate fuse "system call" like mount_local_getattr in case of > ls. > It is stuck at guestfs_lstatns possibly at ACQUIRE_LOCK_FOR_CURRENT_SCOPE, > while being called from fuse. Can you get a stack trace from gdb. Use the command ‘t a a bt’ to show stacks from all threads at the same time. > What do you think could be a problem? Some lock already taken? > Also, maybe less concern for me as I use fuse read-only, is the directory > cache guarded? Possibly not, I've not really looked at the fuse code w.r.t multithreading at all. Patches welcome as usual. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
