Emmanuel,
Replies inline.
I am still working on glusterfs/NetBSD, and it is getting close to something
> actually usable. I still have a few issues, one of which is unmounting.
>
> Thats a good news.
> When I use umount(8), I send a FUSE_DESTROY to glusterfs. That has no
> effect at all. Looking at the source, I can see that fuse_destroy()
> just returns succes and do nothing.
>
> Is it on purpose? What about adding a kill(getpid(), SIGTERM) here?
> What is the prefered way of unmounting right now?
>
> IMO its not on purpose. below patch should be better option than calling a
kill().
-----
diff --git a/xlators/mount/fuse/src/fuse-bridge.c
b/xlators/mount/fuse/src/fuse-bridge.c
index dafc0a9..902c68a 100644
--- a/xlators/mount/fuse/src/fuse-bridge.c
+++ b/xlators/mount/fuse/src/fuse-bridge.c
@@ -2922,6 +2922,9 @@ fuse_destroy (xlator_t *this, fuse_in_header_t *finh,
void *msg)
send_fuse_err (this, finh, 0);
GF_FREE (finh);
+
+ if (this)
+ this->fini (this);
}
-----
> Another problem: invoking glusterfs with -s and without --volfile-id
> leads to a SIGSEGV because volfile_id is NULL. This can be fixed by
> adding an error message if --volfile-id is supplied without -s. Another
> approach would be to let the administrator supply the volfile_id in the
> -s string, for instance with glusterfs -s [email protected] /mnt
> (I suggest this syntax rather than gfs.example.net:gfs1 just in case one
> want to add support for specifying an alternate port some day).
>
> Filed a bug here: http://bugs.gluster.com/show_bug.cgi?id=2934
Patch sent to fix it: http://patches.gluster.com/patch/7232/
With these things should be smooth for you.
Regards,
Amar
_______________________________________________
Gluster-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/gluster-devel
