search for: volumedisk1

...[root at stor1 ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/sdb1 26T 1,1T 25T 4% /mnt/glusterfs/vol0 /dev/sdc1 50T 16T 34T 33% /mnt/glusterfs/vol1 stor1data:/volumedisk0 101T 3,3T 97T 4% /volumedisk0 stor1data:/volumedisk1 197T 61T 136T 31% /volumedisk1 [root at stor2 ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/sdb1 26T 1,1T 25T 4% /mnt/glusterfs/vol0 /dev/sdc1 50T 16T 34T 33% /mnt/glusterfs/vol1 stor2data:/volumedisk0...

...Filesystem Size Used Avail Use% Mounted on > /dev/sdb1 26T 1,1T 25T 4% /mnt/glusterfs/vol0 > /dev/sdc1 50T 16T 34T 33% /mnt/glusterfs/vol1 > stor1data:/volumedisk0 > 101T 3,3T 97T 4% /volumedisk0 > stor1data:/volumedisk1 > 197T 61T 136T 31% /volumedisk1 > > > [root at stor2 ~]# df -h > Filesystem Size Used Avail Use% Mounted on > /dev/sdb1 26T 1,1T 25T 4% /mnt/glusterfs/vol0 > /dev/sdc1 50T 16T 34T 33% /mnt/glusterfs/vol1...

...A month ago I expanded both volumes with a new node: stor3data (2 bricks per volume). Of course, then to add the new peer with the bricks I did the 'balance force' operation. This task finished successfully (you can see info below) and number of files on the 3 nodes were very similar . For volumedisk1 I only have files of 500MB and they are continuosly written in sequential mode. The filename pattern of written files is: run.node1.0000.rd run.node2.0000.rd run.node1.0001.rd run.node2.0001.rd run.node1.0002.rd run.node2.0002.rd ........... ........... run.node1.X.rd run.node2.X.rd ( X ranging...

...ize reported by df command was changed and is smaller than the aggregated capacity of all the bricks in the volume. I checked that all the volumes status are fine, all the glusterd daemons are running, there is no error in logs, however df shows a bad total size. My configuration for one volume: volumedisk1 [root at stor1 ~]# gluster volume status volumedisk1 detail Status of volume: volumedisk1 ------------------------------------------------------------------------------ Brick : Brick stor1data:/mnt/glusterfs/vol1/brick1 TCP Port : 49153 RDMA Port : 0 Online...

Hi Jose, There is a known issue with gluster 3.12.x builds (see [1]) so you may be running into this. The "shared-brick-count" values seem fine on stor1. Please send us "grep -n "share" /var/lib/glusterd/vols/volumedisk1/*" results for the other nodes so we can check if they are the cause. Regards, Nithya [1] https://bugzilla.redhat.com/show_bug.cgi?id=1517260 On 28 February 2018 at 03:03, Jose V. Carri?n <jocarbur at gmail.com> wrote: > Hi, > > Some days ago all my glusterfs configuratio...

Hi Nithya, Below the output of both volumes: [root at stor1t ~]# gluster volume rebalance volumedisk1 status Node Rebalanced-files size scanned failures skipped status run time in h:m:s --------- ----------- ----------- ----------- ----------- ----------- ------------ ---------...

...olumes with a new node: stor3data (2 bricks > per volume). > Of course, then to add the new peer with the bricks I did the 'balance > force' operation. This task finished successfully (you can see info below) > and number of files on the 3 nodes were very similar . > > For volumedisk1 I only have files of 500MB and they are continuosly > written in sequential mode. The filename pattern of written files is: > > run.node1.0000.rd > run.node2.0000.rd > run.node1.0001.rd > run.node2.0001.rd > run.node1.0002.rd > run.node2.0002.rd > ........... > ..........

I'm sorry for my last incomplete message. Below the output of both volumes: [root at stor1t ~]# gluster volume rebalance volumedisk1 status Node Rebalanced-files size scanned failures skipped status run time in h:m:s --------- ----------- ----------- ----------- ----------- ----------- ------------ ---------...