similar to: Exact purpose of network.ping-timeout

Sorry about the delayed response. Had to dig into the history to answer various "why"s. ----- Original Message ----- > From: "Omar Kohl" <omar.kohl at iternity.com> > To: gluster-users at gluster.org > Sent: Tuesday, December 26, 2017 6:41:48 PM > Subject: [Gluster-users] Exact purpose of network.ping-timeout > > Hi, > > I have a question

----- Original Message ----- > From: "Raghavendra Gowdappa" <rgowdapp at redhat.com> > To: "Omar Kohl" <omar.kohl at iternity.com> > Cc: gluster-users at gluster.org > Sent: Wednesday, January 10, 2018 10:56:21 AM > Subject: Re: [Gluster-users] Exact purpose of network.ping-timeout > > Sorry about the delayed response. Had to dig into the

Hi, > If you set it to 10 seconds, and a node goes down, you'll see a 10 seconds freez in all I/O for the volume. Exactly! ONLY 10 seconds instead of the default 42 seconds :-) As I said before the problem with the 42 seconds is that a Windows Samba Client will disconnect (and therefore interrupt any read/write operation) after waiting for about 25 seconds. So 42 seconds is too high. In

Sure, if you never restart / autoscale anything and if your use case isn't bothered with up to 42 seconds of downtime, for us - 42 seconds is a really long time for something like a patient management system to refuse file attachments from being uploaded etc... We apply a strict patching policy for security and kernel updates, we often also load balance between underlying physical hosts and

Restarts will go through a shutdown process. As long as the network isn't actively unconfigured before the final kill, the tcp connection will be shutdown and there will be no wait. On 12/28/17 20:19, Sam McLeod wrote: > Sure, if you never restart / autoscale anything and if your use case > isn't bothered with up to 42 seconds of downtime, for us - 42 seconds > is a really

The reason for the long (42 second) ping-timeout is because re-establishing fd's and locks can be a very expensive operation. With an average MTBF of 45000 hours for a server, even just a replica 2 would result in a 42 second MTTR every 2.6 years, or 6 nines of uptime. On December 27, 2017 3:17:01 AM PST, Omar Kohl <omar.kohl at iternity.com> wrote: >Hi, > >> If you set it

Hi, I know that "glusterbot" text about ping-timeout almost by heart by now ;-) I have searched the complete IRC logs and Mailing list from the last 4 or 5 years for anything related to ping-timeout. The problem with "can be a very expensive operation" is that this is extremely vague. It would be helpful to put some numbers behind it. Of course I also understand that any

Hi, It's just the delay for which a node can stop responding before being marked as down. Basically that's how long a node can go down before a heal becomes necessary to bring it back. If you set it to 10 seconds, and a node goes down, you'll see a 10 seconds freez in all I/O for the volume. That's why you don't want it too high (having a 2 minutes freez on I/O for example

10 seconds is a very long time for files to go away for applications used at any scale, it is however what I've set our failover time to after being shocked by the default of 42 seconds. -- Sam McLeod https://smcleod.net https://twitter.com/s_mcleod > On 27 Dec 2017, at 10:17 pm, Omar Kohl <omar.kohl at iternity.com> wrote: > > Hi, > >> If you set it to 10 seconds,

Hi, I have a question regarding bitrot detection. Following the RedHat manual (https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.3/html/administration_guide/bitrot-restore_corrupt_file) I am trying out bad-file-restoration after bitrot. "gluster volume bitrot VOLNAME status" gets me the GFIDs that are corrupt and on which Host this happens. As far as I can tell

On 04/17/2018 06:25 PM, Omar Kohl wrote: > Hi, > > I have a question regarding bitrot detection. > > Following the RedHat manual (https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.3/html/administration_guide/bitrot-restore_corrupt_file) I am trying out bad-file-restoration after bitrot. > > "gluster volume bitrot VOLNAME status" gets me the

2017-07-20 14:48 GMT+02:00 Ravishankar N <ravishankar at redhat.com>: > > But it does say something. All these gfids of completed heals in the log > below are the for the ones that you have given the getfattr output of. So > what is likely happening is there is an intermittent connection problem > between your mount and the brick process, leading to pending heals again >

On 07/20/2017 03:42 PM, yayo (j) wrote: > > 2017-07-20 11:34 GMT+02:00 Ravishankar N <ravishankar at redhat.com > <mailto:ravishankar at redhat.com>>: > > > Could you check if the self-heal daemon on all nodes is connected > to the 3 bricks? You will need to check the glustershd.log for that. > If it is not connected, try restarting the shd using

On 07/20/2017 02:20 PM, yayo (j) wrote: > Hi, > > Thank you for the answer and sorry for delay: > > 2017-07-19 16:55 GMT+02:00 Ravishankar N <ravishankar at redhat.com > <mailto:ravishankar at redhat.com>>: > > 1. What does the glustershd.log say on all 3 nodes when you run > the command? Does it complain anything about these files? > > >

Hi, Thank you for the answer and sorry for delay: 2017-07-19 16:55 GMT+02:00 Ravishankar N <ravishankar at redhat.com>: 1. What does the glustershd.log say on all 3 nodes when you run the > command? Does it complain anything about these files? > No, glustershd.log is clean, no extra log after command on all 3 nodes > 2. Are these 12 files also present in the 3rd data brick?

2017-07-20 11:34 GMT+02:00 Ravishankar N <ravishankar at redhat.com>: > > Could you check if the self-heal daemon on all nodes is connected to the 3 > bricks? You will need to check the glustershd.log for that. > If it is not connected, try restarting the shd using `gluster volume start > engine force`, then launch the heal command like you did earlier and see if > heals

Hi. I'm evaluating GlusterFS for our DFS implementation, and wondered how it compares to KFS/CloudStore? These features here look especially nice ( http://kosmosfs.sourceforge.net/features.html). Any idea what of them exist in GlusterFS as well? Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hey, Can you give us the volume info output for this volume? Why are you not able to get the xattrs from arbiter brick? It is the same way as you do it on data bricks. The changelog xattrs are named trusted.afr.virt_images-client-{1,2,3} in the getxattr outputs you have provided. Did you do a remove-brick and add-brick any time? Otherwise it will be trusted.afr.virt_images-client-{0,1,2} usually.

Hi... Started playing with gluster. And the heal functions is my "target" for testing. Short description of my test ---------------------------- * 4 replicas on single machine * glusterfs mounted locally * Create file on glusterfs-mounted directory: date >data.txt * Append to file on one of the bricks: hostname >>data.txt * Trigger a self-heal with: stat data.txt =>

Hi Henrik, Thanks for providing the required outputs. See my replies inline. On Thu, Dec 21, 2017 at 10:42 PM, Henrik Juul Pedersen <hjp at liab.dk> wrote: > Hi Karthik and Ben, > > I'll try and reply to you inline. > > On 21 December 2017 at 07:18, Karthik Subrahmanya <ksubrahm at redhat.com> > wrote: > > Hey, > > > > Can you give us the