> I'm not even going to touch his argument that using system clocks in a distributed locking algorithm is safe...
Please do
Please do
If I have a 5 second lock that expires at 12:01:00 and my clock is off by 1 second I could write at 12:01:01 potentially after someone else has a lock, or worse, after someone else has written.
> The client computes how much time elapsed in order to acquire the lock, by subtracting from the current time the timestamp obtained in step 1. If and only if the client was able to acquire the lock in the majority of the instances (at least 3), and the total time elapsed to acquire the lock is less than lock validity time, the lock is considered to be acquired.
or daylight savings change?
or ntp updates which change the time?
Since the system clock can change relative to itself at any time, what effect does that have on the algorithm?
> VM live migration "pause"?
System clock will take a larger step than usual. It won't go backwards.
> daylight savings change?
None. System clock is UTC for a reason.
> ntp updates which change the time?
NTP only drifts the clock (under normal operation).
System clock will take a larger step than usual. It won't go backwards.
Assumes that checkpoint and restore to a previous time won't happen.
NTP only drifts the clock (under normal operation).
Unless it's a system like this. Note that this was pulled at about 1pm EST.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2016/02/09 22:36:50
Hw clock time : 2016/02/09 22:36:50 = 1455057410 seconds since 1969
Tue 09 Feb 2016 02:36:50 PM PST -1.038948 seconds
'Under normal operation' is not really a high bar for distributed systems. After all, the network is reliable 'under normal operation' too.
Or migration to a host whose clock is behind the original host's clock.
If someone forks a VM from a running snapshot, you're screwed whether they mess with the clock or not.
That shouldn't be an assumption. NTP may jump the clock if the difference is too high, I've had it once that a system was connected to two different NTP servers and they each had a different clock and the system would jump the clock every now and then based on what NTP server it though was more correct.
A client can never know with certainty that it has successfully acquired the lock because, for example, the process could freeze between reading the current time from hardware and the steady_time function returning.
You can not rely on time, for safety. Only for advice.