similar to: Alternative storage vs. Self healing (losing flags?)

Hi, When self-healing is triggered? As you can see below it has been triggered however I checked the logs and there was not any disconnection from the FTP servers.So, I can?t understand why it has been triggered. Client-7 comes online, so may the image differ due some file corrupted? Or for some reason the ftp server was not able to write in one of the replicated storages (client-6 and

That make sense ^_^ Unfortunately I haven't kept the interresting data you need. Basically I had some write errors on my gluster clients when my monitoring tool tested mkdir & create files. The server's load was huge during the healing (cpu at 100%), and the disk latency increased a lot. That may be the source of my write errors, we'll know for sure next time... I'll keep

Hi, There is no way to isolate the healing peer. Healing happens from the good brick to the bad brick. I guess your replica bricks are on a different peers. If you try to isolate the healing peer, it will stop the healing process itself. What is the error you are getting while writing? It would be helpful to debug the issue, if you can provide us the output of the following commands: gluster

Most people (even Eniripsa players) see Eniripsa solely as support characters. They are support characters, but to limit an Eniripsa to purely support status, one never realises an Eniripsa's true power. Alot of guides will tell you that Eniripsa are "leech fairies" for most levels, that is not the case if built properly. The important thing to remember when building a solo Eniripsa

On Tue, Mar 20, 2018 at 5:26 AM, Victor T <hero_of_nothing_1 at hotmail.com> wrote: > That makes sense. In the case of "file damage," it would show up as files > that could not be healed in logfiles or gluster volume heal [volume] info? > If the damage affects more bricks than the volume redundancy, then probably yes. These files or directories will appear in

----- Original Message ----- > From: "mabi" <mabi at protonmail.ch> > To: "Gluster Users" <gluster-users at gluster.org> > Sent: Monday, August 21, 2017 9:28:24 AM > Subject: [Gluster-users] self-heal not working > > Hi, > > I have a replicat 2 with arbiter GlusterFS 3.8.11 cluster and there is > currently one file listed to be healed as

Hi Rolf, answers follow inline... On Thu, Nov 9, 2017 at 3:20 PM, Rolf Larsen <rolf at jotta.no> wrote: > Hi, > > We ran a test on GlusterFS 3.12.1 with erasurecoded volumes 8+2 with 10 > bricks (default config,tested with 100gb, 200gb, 400gb bricksizes,10gbit > nics) > > 1. > Tests show that healing takes about double the time on healing 200gb vs > 100, and

Can you also provide: gluster v heal <my vol> info split-brain If it is split brain just delete the incorrect file from the brick and run heal again. I haven't tried this with arbiter but I assume the process is the same. -b ----- Original Message ----- > From: "mabi" <mabi at protonmail.ch> > To: "Ben Turner" <bturner at redhat.com> > Cc:

Hi everyone, I've been using gluster for a few month now, on a simple 2 peers replicated infrastructure, 22Tb each. One of the peers has been offline last week during 10 hours (raid resync after a disk crash), and while my gluster server was healing bricks, I could see some write errors on my gluster clients. I couldn't find a way to isolate my healing peer, in the documentation or

Hello All, I have replicated-distributed volumes (created with the CLI) spread over several servers. One of the servers in the cluster has been down for two weeks due to hardware problems and I am now ready to put it back into service. The problem is that the files on it are now very different to the files on its GlusterFS replica; a lot of data has been added to the GlusterFS volumes in

Hey, Did the heal completed and you still have some entries pending heal? If yes then can you provide the following informations to debug the issue. 1. Which version of gluster you are running 2. gluster volume heal <volname> info summary or gluster volume heal <volname> info 3. getfattr -d -e hex -m . <filepath-on-brick> output of any one of the which is pending heal from all

I'm trying to manually garbage data on bricks (when the volume is stopped) and then check whether healing is possible. For example: Start: # glusterd --debug Bricks (on EXT4 mounted with 'rw,realtime'): # mkdir /root/data0 # mkdir /root/data1 # mkdir /root/data2 Volume: # gluster volume create gv0 replica 3 [local-ip]:/root/data0 [local-ip]:/root/data1 [local-ip]:/root/data2

Someone on the #gluster-users irc channel said the following : "Decreasing features.locks-revocation-max-blocked to an absurdly low number is letting our distributed-disperse set heal again." Is this something to concider? Does anyone else have experience with tweaking this to speed up healing? Sent from my iPhone > On 9 Nov 2017, at 18:00, Serkan ?oban <cobanserkan at

Hi! I have trivial problem with self healing. Maybe somebody will be able to tell mi what am I doing wrong, and why do the files not heal as I expect. Configuration: Servers: two nodes A, B --------- volume posix type storage/posix option directory /ext3/glusterfs13/brick end-volume volume brick type features/posix-locks option mandatory on subvolumes posix end-volume volume server

On Mon, Oct 09, 2017 at 03:29:41PM +0200, ML wrote: > The server's load was huge during the healing (cpu at 100%), and the > disk latency increased a lot. Depending on the file sizes, you might want to consider changing the heal algortithm. Might be better to just re-download the whole file / shard than to try and heal it, assuming you don't have big files. That would free up the

Explore the following: - Launch index heal and look at the glustershd logs of all bricks for possible errors - See if the glustershd in each node is connected to all bricks. - If not try to restart shd by `volume start force` - Launch index heal again and try. - Try debugging the shd log by setting client-log-level to DEBUG temporarily. On 08/22/2017 03:19 AM, mabi wrote: > Sure, it

Hi All. Hoping you can help me with a healing problem. I have one file which didn't self heal. it looks to be a problem with a directory in the path as one node says it's dirty. I have a replica volume with arbiter This is what the 3 nodes say. One brick on each Node1 getfattr -d -m . -e hex /path/to/dir | grep afr getfattr: Removing leading '/' from absolute path names

No. After bringing up one brick and before stopping the next one, you need to be sure that there are no damaged files. You shouldn't reboot a node if "gluster volume heal <volname> info" shows damaged files. What happens in this case then? I'm thinking about a situation where the servers are kept in an environment that we don't control - i.e. the cloud. If the VMs are

Hi Ben, So it is really a 0 kBytes file everywhere (all nodes including the arbiter and from the client). Here below you will find the output you requested. Hopefully that will help to find out why this specific file is not healing... Let me know if you need any more information. Btw node3 is my arbiter node. NODE1: STAT: File:

Hi, You can set disperse.shd-max-threads to 2 or 4 in order to make heal faster. This makes my heal times 2-3x faster. Also you can play with disperse.self-heal-window-size to read more bytes at one time, but i did not test it. On Thu, Nov 9, 2017 at 4:47 PM, Xavi Hernandez <jahernan at redhat.com> wrote: > Hi Rolf, > > answers follow inline... > > On Thu, Nov 9, 2017 at