similar to: glusterfs 3.6.5 and selfheal

Hi Jose, On 28 February 2018 at 18:28, Jose V. Carri?n <jocarbur at gmail.com> wrote: > Hi Nithya, > > I applied the workarround for this bug and now df shows the right size: > > That is good to hear. > [root at stor1 ~]# df -h > Filesystem Size Used Avail Use% Mounted on > /dev/sdb1 26T 1,1T 25T 4% /mnt/glusterfs/vol0 > /dev/sdc1

Hi Jose, On 28 February 2018 at 22:31, Jose V. Carri?n <jocarbur at gmail.com> wrote: > Hi Nithya, > > My initial setup was composed of 2 similar nodes: stor1data and stor2data. > 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.

Hi Nithya, I applied the workarround for this bug and now df shows the right size: [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

This is in relation to bringing up a new oVirt environment. When I was bringing up oVirt (Hosted-Engine), I had the Glusterd service stopped, since the server (I have its name as GSAoV07) was initially only going to be used to host the oVirt engine as a hypervisor (it will have Gluster volumes in the near future). I have three other servers I am using for storage. One of those three is also going

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

Hi Nithya, My initial setup was composed of 2 similar nodes: stor1data and stor2data. 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

glusterd failed to resolve addresses of the bricks. This could happen either because of glusterd was trying to resolve the address of the brick before the N/W interface was up or a change in the IP? If it's the latter then a point to note is that it's recommended that cluster should be formed using hostname otherwise if the server goes through IP change we have to change the configuration

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

On Mon, 12 Jun 2017 at 17:40, Langley, Robert <Robert.Langley at ventura.org> wrote: > Thank you for your response. There has been no change of IP addresses. And > I have tried restarting the glusterd service multiple times. > I am using fully qualified names with a DNS server that has forward and > reverse setup. > Something I had noticed is that, with oVirt, communication

Thank you for your response. There has been no change of IP addresses. And I have tried restarting the glusterd service multiple times. I am using fully qualified names with a DNS server that has forward and reverse setup. Something I had noticed is that, with oVirt, communication is being attempted over the VM network, rather than storage network. Which is not how the bricks are defined. Not sure

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 Mon, Jun 12, 2017 at 6:41 PM, Atin Mukherjee <amukherj at redhat.com> wrote: > > On Mon, 12 Jun 2017 at 17:40, Langley, Robert <Robert.Langley at ventura.org> > wrote: > >> Thank you for your response. There has been no change of IP addresses. >> And I have tried restarting the glusterd service multiple times. >> I am using fully qualified names with a

Hello, I''m trying to build a replica volume, on two servers. The servers are: blade6 and blade7. (another blade1 in the peer, but with no volumes) The volume seems ok, but I cannot mount it from NFS. Here are some logs: [root@blade6 stor1]# df -h /dev/mapper/gluster_stor1 882G 200M 837G 1% /gluster/stor1 [root@blade7 stor1]# df -h /dev/mapper/gluster_fast

Hi, Some days ago all my glusterfs configuration was working fine. Today I realized that the total size 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:

On Mon, Jun 12, 2017 at 7:30 PM, Langley, Robert <Robert.Langley at ventura.org > wrote: > As far as the peer status (and I now remember seeing this earlier) the > issue appears to be that the host name for gsaov07 is attempting to resolve > over the wrong network for gluster "ent...." and not "stor.local". > So, it may be as simple as removing gsaov07 as a

As far as the peer status (and I now remember seeing this earlier) the issue appears to be that the host name for gsaov07 is attempting to resolve over the wrong network for gluster "ent...." and not "stor.local". So, it may be as simple as removing gsaov07 as a peer, then probing over the correct network. I'll follow up with the Engine log. Sent using OWA for iPhone

On Thu, Apr 5, 2018 at 10:48 AM, Artem Russakovskii <archon810 at gmail.com> wrote: > Hi, > > I noticed when I run gluster volume heal data info, the follow message > shows up in the log, along with other stuff: > > [dht-selfheal.c:2328:dht_selfheal_directory] 0-data-dht: Directory >> selfheal failed: Unable to form layout for directory / > > > I'm

Hi, I noticed when I run gluster volume heal data info, the follow message shows up in the log, along with other stuff: [dht-selfheal.c:2328:dht_selfheal_directory] 0-data-dht: Directory selfheal > failed: Unable to form layout for directory / I'm seeing it on Gluster 4.0.1 and 3.13.2. Here's the full log after running heal info:

Hi samba list, I am seeing a peculiar issue when sharing out a directory containing a soft symlink pointing to a directory outside of the share and a different filesystem/block device. i have 2 shares: [share1] read only = No follow symlinks = yes wide links = yes /media/stor0/user [share2] /media/stor1/user /media/stor0 is an xfs filesystem /media/stor1 is an xfs filesystem there is a folder

Hi All, (I've also posted this to the CentOS forum - so copy and pasted for simplicity) I'm having an unusual issue with Samba server package 3.6.9-164.el6 When sharing out a directory containing a soft symlink pointing to a directory outside of the share and a different filesystem/block device. When a client mounts the partition (Linux and Mac OSX Clients tested) and attempts to copy a