similar to: CEBA-2016:0476 CentOS 6 glusterfs BugFix Update

Send CentOS-announce mailing list submissions to centos-announce at centos.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request at centos.org You can reach the person managing the list at centos-announce-owner at centos.org When

CentOS Errata and Bugfix Advisory 2018:2444 Upstream details at : https://access.redhat.com/errata/RHBA-2018:2444 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 59f5c080694bdf3606c516b206dd35cc1c3cb3fd7885aafe6bf31713fab2229e glusterfs-3.8.4-54.15.el7.centos.x86_64.rpm

Hi? If there was only one client, there were not any problems even the traffic was very heavy. But if I used several clients to write the same volume, then I could see the segmentation fault. I used gdb to debug, but the performance was much lower than the previous test results, and we couldn't see the errors. We thought that the problem only occurred when multiple clients wrote the same

CentOS Errata and BugFix Advisory 2016:C001 Upstream details at : https://bugs.centos.org/view.php?id=10538 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 96963d839797a7601ef6a4922c94e7ef82b42fcb70533f9a31c43adceee2fb19 glusterfs-3.7.1-16.0.1.el7.centos.x86_64.rpm

Dear gluster team, I have installed glusterfs on my servers for the storage. Machine: x86_64-redhat-linux I have created volumes with rdma protocol for infiniband. I have mount with acl option on server and client. When I run setfacl for glusterfs mount point it works fine but when i do it for nfs mount it says. setfacl <dir> : operation not supported. The logs created in server are as

CentOS Errata and Bugfix Advisory 2018:1399 Upstream details at : https://access.redhat.com/errata/RHBA-2018:1399 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 4cc7b7a1a6072a4fd731c173281154eab2aaad535193671ebd38944ec57922fe ibacm-15-7.el7_5.x86_64.rpm 990a8d1e6d66d121b0eaf5d368f835076ba9a5f762731b6da5bcb83b5b9acbdc

CentOS Errata and Bugfix Advisory 2020:1212 Upstream details at : https://access.redhat.com/errata/RHBA-2020:1212 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 48b31125348c316305a75dfd8882d953f7108fd4a634c736fc55c3eac43a62ee ibacm-22.4-4.el7_8.x86_64.rpm 225973fb73009f0848d7cebd95ee7f9c1e5a859acfba4e51a3982538de576df1

OK - finished some tests over tcp and ironed out a lot of problems. rdma is next; should be snap now.... [I must admit that this is my 1st foray into the land of IB, so some of the following may be obvious to a non-naive admin..] except that while I can create and start the volume with rdma as transport: ================================== root at pbs3:~ 622 $ gluster volume info glrdma

Hi ,all We found a strange problem. Some clients worked normally while some clients couldn't access sepcial files. For exmaple, Client A couldn't create the directory xxx, but Client B could. However, if Client B created the directory, Client A could acess it and even deleted it. But Client A still couldn't create the same directory later. If I changed the directory name, Client A

This looks like there could be some some problem requesting / leaking / whatever memory but without looking at the core its tought to tell for sure. Note: /usr/lib64/libglusterfs.so.0(_gf_msg_backtrace_nomem+0x78)[0x7f95bc54e618] Can you open up a bugzilla and get us the core file to review? -b ----- Original Message ----- > From: "???" <21291285 at qq.com> > To:

CentOS Errata and Bugfix Advisory 2017:0037 Upstream details at : https://rhn.redhat.com/errata/RHBA-2017-0037.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 556f67c49dfae7ce96d3a1ec080faff4caf5a8ef2db4d46a7ebf15a45b4245e4 rdma-6.8_4.1-2.el6_8.noarch.rpm x86_64:

CentOS Errata and Security Advisory 2018:2892 Moderate Upstream details at : https://access.redhat.com/errata/RHSA-2018:2892 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 131786837b080aba5234623fbd2277efe4873585ee2628b5e65bb26e99425c65 glusterfs-3.12.2-18.el6.i686.rpm

CentOS Errata and Bugfix Advisory 2017:1299 Upstream details at : https://rhn.redhat.com/errata/RHBA-2017-1299.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 936112b4af4d1003afa374407431717a43d278f0d07c5c61cdb7a7cd55aadffa rdma-7.3_4.7_rc2-6.el7_3.noarch.rpm Source:

You can still get them from https://buildlogs.centos.org/centos/7/storage/x86_64/gluster-3.13/ (I don't know how much longer they'll be there. I suggest you copy them if you think you're going to need them in the future.) n 05/15/2018 04:58 AM, Davide Obbi wrote: > hi, > > i noticed that this repo for glusterfs 3.13 does not exists anymore at: > >

Hi, All, I used Infiniband to connect all GlusterFS nodes and the clients. Previously I run IP over IB and everything was OK. Now I used rdma transport mode instead. And then I ran the traffic. After I while, the glusterfs process exited because of segmentation fault. Here were the messages when I saw segmentation fault: pending frames: frame : type(0) op(0) frame : type(0) op(0)

Thanks Kaleb, any chance i can make the node working after the downgrade? thanks On Tue, May 15, 2018 at 2:02 PM, Kaleb S. KEITHLEY <kkeithle at redhat.com> wrote: > > You can still get them from > https://buildlogs.centos.org/centos/7/storage/x86_64/gluster-3.13/ > > (I don't know how much longer they'll be there. I suggest you copy them > if you think

CentOS Errata and Security Advisory CESA-2009:0476 pango security update for CentOS 3 i386: https://rhn.redhat.com/errata/RHSA-2009-0476.html The following updated file has been uploaded and is currently syncing to the mirrors: i386: updates/i386/RPMS/pango-1.2.5-8.i386.rpm updates/i386/RPMS/pango-devel-1.2.5-8.i386.rpm source: updates/SRPMS/pango-1.2.5-8.src.rpm You may update your CentOS-3

CentOS Errata and Security Advisory CESA-2009:0476 pango security update for CentOS 3 x86_64: https://rhn.redhat.com/errata/RHSA-2009-0476.html The following updated file has been uploaded and is currently syncing to the mirrors: x86_64: updates/x86_64/RPMS/pango-1.2.5-8.i386.rpm updates/x86_64/RPMS/pango-1.2.5-8.x86_64.rpm updates/x86_64/RPMS/pango-devel-1.2.5-8.x86_64.rpm source:

CentOS Errata and Security Advisory 2009:0476 Important Upstream details at : https://rhn.redhat.com/errata/RHSA-2009-0476.html The following updated files have been uploaded and are currently syncing to the mirrors: ( md5sum Filename ) i386: f8f14e9ad1693bbe339ed08ec6d24908 pango-1.14.9-5.el5.centos.i386.rpm 1b544aedc92170db517059b27c69787f pango-devel-1.14.9-5.el5.centos.i386.rpm Source:

CentOS Errata and Security Advisory 2009:0476 Important Upstream details at : https://rhn.redhat.com/errata/RHSA-2009-0476.html The following updated files have been uploaded and are currently syncing to the mirrors: ( md5sum Filename ) x86_64: 8e536b373c64976d8c66a550c4784622 pango-1.14.9-5.el5.centos.i386.rpm c027eafbebcf6f59ab181fca42acd23c pango-1.14.9-5.el5.centos.x86_64.rpm