similar to: Exact purpose of network.ping-timeout

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

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

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

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

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

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

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

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

Hi, I have a question regarding the "ping-timeout" option. I have been researching its purpose for a few days and it is not completely clear to me. Especially that it is apparently strongly encouraged by the Gluster community not to change or at least decrease this value! Assuming that I set ping-timeout to 10 seconds (instead of the default 42) this would mean that if I have a network

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,

Dear LLVMers, There is some scheduled network outages detailed below that affect the llvm.org servers and LLVM Mailing lists. The LLVM server is housed on the fourth floor. I am not sure which rooms house the mailing list servers. All times are Central Standard Time. If someone from Illinois can distill the relevant parts of this message for LLVM users, I would be most appreciative. I am out

Dan Langille via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> writes: > I have an idea for my shutdown process at home. My goal: maximize the network run-time. At present, the UPS has a run-time of about 57 minutes. > > This is my idea: > > * shutdown the servers after 15 minutes of downtime (for me, that's when battery.runtime hits 40) > * leave the network

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 == What happened == On Wednesday February 24th, at 6pm UTC time, the DC hosting some of the CentOS equipments used for various roles had suffered from multiple electricity power outages. The facility was completely dark for just under 2 hrs, and we were able to start recovering services by 8pm UTC. By midnight we had most services restored, by

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 == What happened == On Wednesday February 24th, at 6pm UTC time, the DC hosting some of the CentOS equipments used for various roles had suffered from multiple electricity power outages. The facility was completely dark for just under 2 hrs, and we were able to start recovering services by 8pm UTC. By midnight we had most services restored, by

Hi all, This question has come up many times before in a number of guises. But I do not believe that it has ever been answered satisfactorily. This may well reflect fundamental difficulties in the CIFS protocol However, recent incarnations of Windows Server seem to handle the problem better possibly due to tweaks in the underlying TCP/IP stack vis-a-vis Linux. At the end of the day, a

I have a CentOS-6.2 server in Italy. Every few months the server gets into a strange state and stops working after a power outage. I should say that this does not occur after every power outage; I suspect, but have no real evidence for this, that if the power comes back too quickly then the machine gets confused because it is in the middle of closing down. If I am in Italy the solution is simple;

Send CentOS-announce mailing list submissions to centos-announce at centos.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request at centos.org You can reach the person managing the list at centos-announce-owner at centos.org When

Hi Arjen, I've just read the FAQ and got to the question: "Q: How can I make upsmon shut down my system after some fixed interval?" Well it looked like the question was there for me. :-) You say: Ask yourself this: why buy a nice big UPS with the matching battery and corresponding runtime and then shutdown early? If anything, I'd rather have a few more minutes running on

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