On Fri, Sep 21, 2018 at 12:44 AM Chaloulos, Klearchos (Nokia - GR/Athens) < klearchos.chalou...@nokia.com> wrote:
> Hello, > > We are using glusterfs version 3.7.14, and have deployed the glusterfs > servers in containers. We are trying to use the “gluster volume add-brick” > command to extend a volume, but it fails: > > gluster volume add-brick oam replica 3 172.01.01.01:/mnt/bricks/oam force > volume add-brick: failed: Commit failed on 172.01.01.01. Please check log > file for details. > > The logs show that it fails to mount /dev/fuse: > > [mount.c:341:gf_fuse_mount] 0-glusterfs-fuse: cannot open \/dev\/fuse (No > such file or directory) > [glusterd-utils.c:11294:glusterd_handle_replicate_brick_ops] 0-management: > mount command failed. > [MSGID: 106074] [glusterd-brick-ops.c:2372:glusterd_op_add_brick] > 0-glusterd: Unable to add bricks > [MSGID: 106123] [glusterd-mgmt.c:294:gd_mgmt_v3_commit_fn] 0-management: > Add-brick commit failed. > > Questions: > > 1. Why does it need /dev/fuse in order to add a brick? > > /dev/fuse or the fuse kernel module is needed on a server that contains a brick as several features in gluster rely on mounting a native(fuse) client locally on the server. > 1. Is there a way to bypass the need for /dev/fuse in order to add the > extra brick? > > I don't think there is an easy way at the moment. Making the fuse kernel module available to the glusterfs installation in the container would be the preferred route as of now. > 1. Is this related to this issue: > *https://bugzilla.redhat.com/show_bug.cgi?id=1420027* > <https://bugzilla.redhat.com/show_bug.cgi?id=1420027> ? > > Yes, this is related to the issue reported in the bug. There is a fair amount of work needed to avoid dependency of the glusterfs server stack on a fuse mount. Best Regards, Vijay
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel