similar to: No subject

Hi, We noticed a dramatic slowness when writing to a gluster disk when compared to writing to an NFS disk. Specifically when using dd (data duplicator) to write a 4.3 GB file of zeros: * on NFS disk (/home): 9.5 Gb/s * on gluster disk (/gdata): 508 Mb/s The gluser disk is 2 bricks joined together, no replication or anything else. The hardware is (literally) the same: * one server with

for all three nodes:=0A= =0A= Brick1: gluster-0-0:/mseas-data-0-0=0A= Brick2: gluster-0-1:/mseas-data-0-1=0A= Brick3: gluster-data:/data=0A= =0A= =0A= Which node are you trying to mount to /data? If it is not the=0A= gluster-data node, then it will fail if there is not a /data directory.=0A= In this case, it is a good thing, since mounting to /data on gluster-0-0=0A= or gluster-0-1 would not

for all three nodes: Brick1: gluster-0-0:/mseas-data-0-0 Brick2: gluster-0-1:/mseas-data-0-1 Brick3: gluster-data:/data Which node are you trying to mount to /data? If it is not the gluster-data node, then it will fail if there is not a /data directory. In this case, it is a good thing, since mounting to /data on gluster-0-0 or gluster-0-1 would not accomplish what you need. To clarify, there

So far, those look the same client: [root at mseas FixOwn]# getfacl /gdata/bibliography/Work/GroupBib/trunk/ getfacl: Removing leading '/' from absolute path names # file: gdata/bibliography/Work/GroupBib/trunk/ # owner: phaley # group: mseasweb # flags: -s- user::rwx group::rwx other::r-x server: [root at mseas-data2 ~]# getfacl /gdata/bibliography/Work/GroupBib/trunk/ getfacl:

For example the directory /gdata/bibliography/Work/GroupBib/trunk/ can be written in by user phaley but not by other users who are member of the group mseasweb. The directory has permissions [root at mseas ~]# ls -lh /gdata/bibliography/Work/GroupBib total 12K drwxrwsr-x 4 phaley mseasweb 4.0K Aug 30 12:31 trunk The parent directory (/gdata/bibliography/Work/GroupBib) has permissions [root

Hi We have just migrated our data to a new file server (more space, old server was showing its age). We have a volume for collaborative use, based on group membership. In our new server, the group write permissions are not being respected (e.g. the owner of a directory can still write to that directory but any other member of the associated group cannot, even though the directory clearly

Soumya, its [root at mseas-data2 ~]# glusterfs --version glusterfs 3.7.11 built on Apr 27 2016 14:09:20 Repository revision: git://git.gluster.com/glusterfs.git Copyright (c) 2006-2013 Red Hat, Inc. <http://www.redhat.com/> GlusterFS comes with ABSOLUTELY NO WARRANTY. It is licensed to you under your choice of the GNU Lesser General Public License, version 3 or any later version (LGPLv3

Hi, We recently installed glusterfs 3.3.1. We have a 3 brick gluster system running that was being successfully mounted earlier. Yesterday we experienced a power outage and now after rebooting our systems, we are unable to mount this gluster file system. On the gluster client, a df -h command shows 41TB out of 55TB, while an ls command shows broken links for directories and missing files.

----- Original Message ----- > From: "Pat Haley" <phaley at mit.edu> > To: "Soumya Koduri" <skoduri at redhat.com>, gluster-users at gluster.org, "Pranith Kumar Karampuri" <pkarampu at redhat.com> > Cc: "Ben Turner" <bturner at redhat.com>, "Ravishankar N" <ravishankar at redhat.com>, "Raghavendra

There's currently no way to express trust for an SSH certificate CA other than by manually adding it to known_hosts. This patch modifies the automatic key write-out behaviour on user verification to associate the hostname with the CA rather than the host key, allowing environments making use of certificates to update (potentially compromised) host keys without needing to modify client

Hi, Just before the Thanksgiving break, we enabled quotas on the /home areas on the mseas-data server (running CentOS 5.8), using the following line in the updated /etc/fstab /dev/mapper/the_raid-lv_home /home ext3 defaults,usrquota,grpquota 1 0 Following the Thanksgiving reboot of mseas-data we have been experiencing problems with svn on mseas (our front-end machine, running

Hi Soumya, We just had the opportunity to try the option of disabling the kernel-NFS and restarting glusterd to start gNFS. However the gluster demon crashes immediately on startup. What additional information besides what we provide below would help debugging this? Thanks, Pat -------- Forwarded Message -------- Subject: gluster-nfs crashing on start Date: Mon, 7 Aug 2017 16:05:09

Hi, I have a server running under CentOS 5.8 and I appear to be in a situation in which the NFS file server is not recognizing the available space on a particular disk (actually a hardware RAID-6 of 13 2Tb disks). If I try to write to the disk I get the following error message [root at nas-0-1 mseas-data-0-1]# touch dum touch: cannot touch `dum': No space left on device However, if I check

Hi All, A follow-up question. I've been looking at various pages on nfs-ganesha & gluster. Is there a version of nfs-ganesha that is recommended for use with glusterfs 3.7.11 built on Apr 27 2016 14:09:22 CentOS release 6.8 (Final) Thanks Pat On 07/05/2017 11:36 AM, Pat Haley wrote: > > Hi Soumya, > > (1) In

On Thu, Sep 1, 2016 at 5:30 PM, <centos-request at centos.org> wrote: > Send CentOS mailing list submissions to > centos at centos.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.centos.org/mailman/listinfo/centos > or, via email, send a message with subject or body 'help' to > centos-request at

Hi Guys, I was wondering what our next steps should be to solve the slow write times. Recently I was debugging a large code and writing a lot of output at every time step. When I tried writing to our gluster disks, it was taking over a day to do a single time step whereas if I had the same program (same hardware, network) write to our nfs disk the time per time-step was about 45 minutes.

Hi, Today we experimented with some of the FUSE options that we found in the list. Changing these options had no effect: gluster volume set test-volume performance.cache-max-file-size 2MB gluster volume set test-volume performance.cache-refresh-timeout 4 gluster volume set test-volume performance.cache-size 256MB gluster volume set test-volume performance.write-behind-window-size 4MB gluster

On Fri, Jun 23, 2017 at 9:10 AM, Pranith Kumar Karampuri < pkarampu at redhat.com> wrote: > > > On Fri, Jun 23, 2017 at 2:23 AM, Pat Haley <phaley at mit.edu> wrote: > >> >> Hi, >> >> Today we experimented with some of the FUSE options that we found in the >> list. >> >> Changing these options had no effect: >> >>

On Mon, Jun 26, 2017 at 7:40 PM, Pat Haley <phaley at mit.edu> wrote: > > Hi All, > > Decided to try another tests of gluster mounted via FUSE vs gluster > mounted via NFS, this time using the software we run in production (i.e. > our ocean model writing a netCDF file). > > gluster mounted via NFS the run took 2.3 hr > > gluster mounted via FUSE: the run took

Hi All, Decided to try another tests of gluster mounted via FUSE vs gluster mounted via NFS, this time using the software we run in production (i.e. our ocean model writing a netCDF file). gluster mounted via NFS the run took 2.3 hr gluster mounted via FUSE: the run took 44.2 hr The only problem with using gluster mounted via NFS is that it does not respect the group write permissions which