4 ms·
"If you restrict the failures to this class of issues" is exactly where the assumption that clocks behave is hiding in this paragraph. It's a bit like saying "a
by alblue 11y ago
"If you restrict the failures to this class of issues" is exactly where the assumption that clocks behave is hiding in this paragraph. It's a bit like saying "as long as you ignore false, all booleans can be assumed to be true".
- antirez 11y agoIf you use the monotonic time API the issues are restricted to this subclass of hardware failures. All the others will be irrelevant, like ntpd setting a random time or alike.
- querulous 11y agohow does using the monotonic api protect against time discontinuity as seen when a vm is migrated from one hypervisor to another for example?
- jschwartzi 11y agoMonotonic clocks are guaranteed never to go backwards, for one. In POSIX it would be a major violation of the API, although implementations are free to substitute clock sources if the monotonic source is not provided.
- derefr 11y agoOr, to put it more bluntly: a hypervisor that allows its VMs to be paused SHOULD NOT expose a monotonic time source to said VMs. (In the RFC meaning of "SHOULD NOT".) Enabling monotonic time should disable the ability to pause/migrate/snapshot the VMs, and vice-versa.
- antirez 11y agoIn this case, even in a broken implementation, the time freezes during the migration and is restored immediately after. This is bad since it makes even softwares using the monotonic API not able to count time reliably, however the result is that the time is over-counted, and never under-counted. If the algorithm is designed so that we want to count "at least 5 seconds" it is safe even during VM migrations. This is true for Redlock for example, but in general if one wants to exploit this system model, and can setup the algorithm so that over counting is harmless (if not for liveness), is a good idea. Btw this problems could be mitigated by changing the majority. For instance in the case of a distributed lock, it's possible to acquire the lock in 50% + 2 instances in order to consider the lock valid, so that in one instance the clock can misbehave safely.
- dpark 11y agoHe's talking about literally restricting the failures to a specific class by preventing errors outside that class, not just restricting consideration of errors to that class.