REVIEW: http://review.gluster.org/6070 (libglusterfs: Add monotonic clocking counter for timer thread) posted (#1) for review on master by Harshavardhana (harsha)
REVIEW: http://review.gluster.org/6070 (libglusterfs: Add monotonic clocking counter for timer thread) posted (#2) for review on master by Harshavardhana (harsha)
REVIEW: http://review.gluster.org/6070 (libglusterfs: Add monotonic clocking counter for timer thread) posted (#3) for review on master by Harshavardhana (harsha)
REVIEW: http://review.gluster.org/6070 (libglusterfs: Add monotonic clocking counter for timer thread) posted (#4) for review on master by Harshavardhana (harsha)
REVIEW: http://review.gluster.org/6070 (libglusterfs: Add monotonic clocking counter for timer thread) posted (#5) for review on master by Harshavardhana (harsha)
REVIEW: http://review.gluster.org/6070 (libglusterfs: Add monotonic clocking counter for timer thread) posted (#6) for review on master by Harshavardhana (harsha)
COMMIT: http://review.gluster.org/6070 committed in master by Anand Avati (avati) ------ commit 6836118b214bb45ff94ae1bc176a6eefb1a17a6a Author: Harshavardhana <harsha> Date: Thu Oct 10 04:19:16 2013 -0700 libglusterfs: Add monotonic clocking counter for timer thread gettimeofday() returns the current wall clock time and timezone. Using these functions in order to measure the passage of time (how long an operation took) therefore seems like a no-brainer. This time suffer's from some limitations: a. They have a low resolution: “High-performance” timing by definition, requires clock resolutions into the microseconds or better. b. They can jump forwards and backwards in time: Computer clocks all tick at slightly different rates, which causes the time to drift. Most systems have NTP enabled which periodically adjusts the system clock to keep them in sync with “actual” time. The adjustment can cause the clock to suddenly jump forward (artificially inflating your timing numbers) or jump backwards (causing your timing calculations to go negative or hugely positive). In such cases timer thread could go into an infinite loop. From 'man gettimeofday': ---------- .. .. The time returned by gettimeofday() is affected by discontinuous jumps in the system time (e.g., if the system administrator manually changes the system time). If you need a monotonically increasing clock, see clock_gettime(2). .. .. ---------- Rationale: For calculating interval timing for Timer thread, all that’s needed should be clock as a simple counter that increments at a stable rate. This is necessary to avoid the jumps which are caused by using "wall time", this counter must be monotonic that can never “tick” backwards, ever. Change-Id: I701d31e71a85a73d21a6c5cd15583e7a5a645eeb BUG: 1017993 Signed-off-by: Harshavardhana <harsha> Reviewed-on: http://review.gluster.org/6070 Tested-by: Gluster Build System <jenkins.com> Reviewed-by: Anand Avati <avati>
REVIEW: http://review.gluster.org/7328 (libglusterfs: Fix timespec issues on MacOSX) posted (#1) for review on master by Harshavardhana (harsha)
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.5.0, please reopen this bug report. glusterfs-3.5.0 has been announced on the Gluster Developers mailinglist [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/6137 [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user