search for: mgmt_rpc_notifi

Hi Team, While mounting the gluster volume using 'mount -t glusterfs' command it is getting failed. When we checked the log file getting the below logs [1970-01-02 10:54:04.420065] E [MSGID: 101187] [event-epoll.c:391:event_register_epoll] 0-epoll: failed to add fd(=7) to epoll fd(=0) [Invalid argument] [1970-01-02 10:54:04.420140] W [socket.c:3095:socket_connect] 0-: failed to register

Hi all, Gluster and Ganesha are amazing. Thank you for this great work! I?m struggling with one issue and I think that you might be able to help me. I spent some time by playing with Gluster and Ganesha and after I gain some experience I decided that I should go into production but I?m still struggling with one issue. I have 3x node CentOS 7.3 with the most current Gluster and Ganesha from

On 07/21/2017 11:41 PM, yayo (j) wrote: > Hi, > > Sorry for follow up again, but, checking the ovirt interface I've > found that ovirt report the "engine" volume as an "arbiter" > configuration and the "data" volume as full replicated volume. Check > these screenshots: This is probably some refresh bug in the UI, Sahina might be able to tell

Hi Jan, comments inline. On Fri, Jun 30, 2017 at 1:31 AM, Jan <jan.h.zak at gmail.com> wrote: > Hi all, > > Gluster and Ganesha are amazing. Thank you for this great work! > > I?m struggling with one issue and I think that you might be able to help me. > > I spent some time by playing with Gluster and Ganesha and after I gain some > experience I decided that I

Hi Hari, thank you for your support! Did I try to check offline bricks multiple times? Yes ? I gave it enough time (at least 20 minutes) to recover but it stayed offline. Version? All nodes are 100% equal ? I tried fresh installation several times during my testing, Every time it is CentOS Minimal install with all updates and without any additional software: uname -r 3.10.0-514.21.2.el7.x86_64

Hi to all, The system is running Debian 12 with Gluster 10. All systems are using the same versions. I try to encrypt the communication between the peers and the clients via TLS. The encryption between the peers works, but when I try to mount the volume on the client I always get an error. What have I done? 1. all hosts and clients can resolve the name of all systems involved. 2. the

Hi! I am having same issue but I am running Ubuntu v16.04. It does not mount during boot, but works if I mount it manually. I am running the Gluster-server on the same machines (3 machines) Here is the /tc/fstab file /dev/sdb1 /data/gluster ext4 defaults 0 0 web1.dasilva.network:/www /mnt/glusterfs/www glusterfs defaults,_netdev,log-level=debug,log-file=/var/log/gluster.log 0 0

On Mon, Aug 21, 2017 at 2:49 AM, Cesar da Silva <thunderlight1 at gmail.com> wrote: > Hi! > I am having same issue but I am running Ubuntu v16.04. > It does not mount during boot, but works if I mount it manually. I am > running the Gluster-server on the same machines (3 machines) > Here is the /tc/fstab file > > /dev/sdb1 /data/gluster ext4 defaults 0 0 > >

Hi Stefan, Does the combined?glusterfs.ca includes client nodes pem? Also this file need to be placed in Client node as well. -- Aravinda Kadalu Technologies ---- On Fri, 26 Jan 2024 15:14:39 +0530 Stefan Kania <stefan at kania-online.de> wrote --- Hi to all, The system is running Debian 12 with Gluster 10. All systems are using the same versions. I try to encrypt the

Hi Jan, It is not recommended that you automate the script for 'volume start force'. Bricks do not go offline just like that. There will be some genuine issue which triggers this. Could you please attach the entire glusterd.logs and the brick logs around the time so that someone would be able to look? Just to make sure, please check if you have any network outage(using iperf or some

> Note that "stripe" is not tested much and practically unmaintained. Ah, this was what I suspected. Understood. I'll be happy with "shard". Having said that, "stripe" works fine with transport=tcp. The failure reproduces with just 2 RDMA servers (with InfiniBand), one of those acts also as a client. I looked into logs. I paste lengthy logs below with

On Tue, Aug 15, 2017 at 01:04:11PM +0000, Hatazaki, Takao wrote: > Ji-Hyeon, > > You're saying that "stripe=2 transport=rdma" should work. Ok, that > was firstly I wanted to know. I'll put together logs later this week. Note that "stripe" is not tested much and practically unmaintained. We do not advise you to use it. If you have large files that you

Hi! Please see bellow. Note that web1.dasilva.network is the address of the local machine where one of the bricks is installed and that ties to mount. [2017-08-20 20:30:40.359236] I [MSGID: 100030] [glusterfsd.c:2476:main] 0-/usr/sbin/glusterd: Started running /usr/sbin/glusterd version 3.11.2 (args: /usr/sbin/glusterd -p /var/run/glusterd.pid) [2017-08-20 20:30:40.973249] I [MSGID: 106478]

Hi ,? I recenlty configured the 2 node replica glusterfs , and I am having couple of issues? 1. As soon ?as a I reboot the node2 , the glusterfs on node1 is not available but when I reboot/shutdown node1 the glusterfs is available on node 0 , so please let me know if you guys have encountered the same issue 2. I am not able to mount the glusterfs mount at the time of reboot I had to do manually

On Wed, Aug 16, 2017 at 4:44 PM, Hatazaki, Takao <takao.hatazaki at hpe.com> wrote: >> Note that "stripe" is not tested much and practically unmaintained. > > Ah, this was what I suspected. Understood. I'll be happy with "shard". > > Having said that, "stripe" works fine with transport=tcp. The failure reproduces with just 2 RDMA servers

Hi, Jan, by multiple times I meant whether you were able to do the whole setup multiple times and face the same issue. So that we have a consistent reproducer to work on. As grepping shows that the process doesn't exist the bug I mentioned doesn't hold good. Seems like another issue irrelevant to the bug i mentioned (have mentioned it now). When you say too often, this means there is a

Hi Hari, Sorry for not providing you more details from the start. Here below you will find all the relevant log entries and info. Regarding the quota.conf file I have found one for my volume but it is a binary file. Is it supposed to be binary or text? Regards, M. *** gluster volume info myvolume *** Volume Name: myvolume Type: Replicate Volume ID: e7a40a1b-45c9-4d3c-bb19-0c59b4eceec5 Status:

Hi, A part of the log won't be enough to debug the issue. Need the whole log messages till date. You can send it as attachments. Yes the quota.conf is a binary file. And I need the volume status output too. On Tue, Feb 13, 2018 at 1:56 PM, mabi <mabi at protonmail.ch> wrote: > Hi Hari, > Sorry for not providing you more details from the start. Here below you will > find all

Thank you for your answer. This problem seem to have started since last week, so should I also send you the same log files but for last week? I think logrotate rotates them on a weekly basis. The only two quota commands we use are the following: gluster volume quota myvolume limit-usage /directory 10GB gluster volume quota myvolume list basically to set a new quota or to list the current

Were you able to set new limits after seeing this error? On Tue, Feb 13, 2018 at 4:19 PM, Hari Gowtham <hgowtham at redhat.com> wrote: > Yes, I need the log files in that duration, the log rotated file after > hitting the > issue aren't necessary, but the ones before hitting the issues are needed > (not just when you hit it, the ones even before you hit it). > > Yes,