similar to: Issue mounting /home area from NAS server

Are you sure using conv=sync is what you want? I normally use conv=fdatasync, I'll look up the difference between the two and see if it affects your test. -b ----- Original Message ----- > From: "Pat Haley" <phaley at mit.edu> > To: "Pranith Kumar Karampuri" <pkarampu at redhat.com> > Cc: "Ravishankar N" <ravishankar at redhat.com>,

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 Ben, Sorry this took so long, but we had a real-time forecasting exercise last week and I could only get to this now. Backend Hardware/OS: * Much of the information on our back end system is included at the top of http://lists.gluster.org/pipermail/gluster-users/2017-April/030529.html * The specific model of the hard disks is SeaGate ENTERPRISE CAPACITY V.4 6TB

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: > > gluster volume set test-volume performance.cache-max-file-size 2MB > gluster volume set test-volume performance.cache-refresh-timeout 4 > gluster

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

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

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:

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 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

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

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.

Hi Soumya, When I originally did the tests I ran tcpdump on the client. I have rerun the tests, doing tcpdump on the server tcpdump -i any -nnSs 0 host 172.16.1.121 -w /root/capture_nfsfail.pcap The results are in the same place http://mseas.mit.edu/download/phaley/GlusterUsers/TestNFSmount/ capture_nfsfail.pcap has the results from the failed touch experiment capture_nfssucceed.pcap has

Hi Soumya, (1) In http://mseas.mit.edu/download/phaley/GlusterUsers/TestNFSmount/ I've placed the following 2 log files etc-glusterfs-glusterd.vol.log gdata.log The first has repeated messages about nfs disconnects. The second had the <fuse_mnt_direcotry>.log name (but not much information). (2) About the gluster-NFS native server: do you know where we can find documentation on

Hi Soumya, One example, we have a common working directory dri_fleat in the gluster volume drwxrwsr-x 22 root dri_fleat 4.0K May 1 15:14 dri_fleat my user (phaley) does not own that directory but is a member of the group dri_fleat and should have write permissions. When I go to the nfs-mounted version and try to use the touch command I get the following ibfdr-compute-0-4(dri_fleat)%

Hi, I was wondering if there were any additional test we could perform to help debug the group write-permissions issue? Thanks Pat On 06/27/2017 12:29 PM, Pat Haley wrote: > > Hi Soumya, > > One example, we have a common working directory dri_fleat in the > gluster volume > > drwxrwsr-x 22 root dri_fleat 4.0K May 1 15:14 dri_fleat > > my user (phaley) does

Hi, We have recently upgraded our gluster to 3.2.5 and have encountered the following error. Gluster seems somehow confused about one of the files it should be serving up, specifically /projects/philex/PE/2010/Oct18/arch07/BalbacFull_250_200_03Mar_3.png If I go to that directory and simply do an ls *.png I get ls: BalbacFull_250_200_03Mar_3.png: Structure needs cleaning (along with a listing

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

On 07/03/2017 09:01 PM, Pat Haley wrote: > > Hi Soumya, > > When I originally did the tests I ran tcpdump on the client. > > I have rerun the tests, doing tcpdump on the server > > tcpdump -i any -nnSs 0 host 172.16.1.121 -w /root/capture_nfsfail.pcap > > The results are in the same place > > http://mseas.mit.edu/download/phaley/GlusterUsers/TestNFSmount/ >