[Gluster-users] add-brick fails with error about /dev/fuse

[Vijay Bellur]

On Fri, Sep 21, 2018 at 12:44 AM Chaloulos, Klearchos (Nokia - GR/Athens) <
klearchos.chaloulos at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20180921/024bf083/attachment.html>