Am Mittwoch, 19. Dezember 2012 13:28:40 schrieb Lars Marowsky-Bree:
> On 2012-12-19T13:22:54, Nikita Michalko wrote:
> > > They should all read Lamport ;-)
> >
> > Interesting - what/who is Lamport though?
>
> LMGTFY:
> http://en.wikipedia.org/wiki/Lamport_timestamps#Lamport.27s_logical_clock_i
On 2012-12-19T13:22:54, Nikita Michalko wrote:
> > They should all read Lamport ;-)
> Interesting - what/who is Lamport though?
LMGTFY:
http://en.wikipedia.org/wiki/Lamport_timestamps#Lamport.27s_logical_clock_in_distributed_systems
--
Architect Storage/HA
SUSE LINUX Products GmbH, GF: Jeff
Hi Lars!
|
v
Am Mittwoch, 19. Dezember 2012 13:06:25 schrieb Lars Marowsky-Bree:
> On 2012-12-19T10:06:25, James Harper wrote:
> > What is the behaviour of a cluster when the nodes are up to 10 minutes
> > out of sync with each other, because they've just been booted up after
> > a crash and th
On 2012-12-19T10:06:25, James Harper wrote:
> What is the behaviour of a cluster when the nodes are up to 10 minutes
> out of sync with each other, because they've just been booted up after
> a crash and the hwclocks are out of date and there is no ntp time
> source reachable? Could it cause lots
On 12/19/12 5:06 AM, James Harper wrote:
What is the best way on bootup in the above situation to ensure time
synchronisation? Is it as simple as having a cron job to reset the hardware
clock every so often so that on reboot things are reasonable?
At least RHEL and SuSE can do an explicit ntp
>
> What is the behaviour of a cluster when the nodes are up to 10 minutes out
> of sync with each other, because they've just been booted up after a crash
> and the hwclocks are out of date and there is no ntp time source reachable?
> Could it cause lots of sig11's and constant re-elections becau
