On 2010-08-24 at 14:34 -0400 Jeff Layton sent off: > > > Any pointers to background on gettimeofday vs > > > clock_gettime(CLOCK_MONOTONIC) and why the latter is better? > > > > IIUC, the reason for this is that gettimeofday is affected by wallclock > > changes (think NTP): > > > > CLOCK_MONOTONIC > > Clock that cannot be set and represents monotonic time since > > some unspecified starting point. > > > > ...so by preferring CLOCK_MONOTONIC, the mtab locking code isn't > > affected by clock jumps or skew. Bjorn, is this correct? yes, correct. In the worst case you start a timeout period while the clock is set to 2020, during the timeout period the clock is corrected by ntpdate. In that case the timeout using the RTC clock is a bit longer than expected :-) > Correction...CLOCK_MONOTONIC is affected by adjtimex(). Over a 30s > period though, that shouldn't mean much of a delta. The big danger is > large clock jumps and this should take care of that. > > Out of curiousity though...did you or someone you know hit this problem > in practice, Bjorn? Or did you just notice it via inspection? you see all kinds of strange timing effects if you have a VM that has an unstable clock which you need to regulary adjust had via ntpdate for example. Programs hang or for a hile or forever in the worst case. I didn't see a problem in this particular case with mount.cifs but as this is something which is called at boot time where ntpdate often runs at the sme time to initally hard reset the clock this is something I thought should to be adjusted to use the monotonic clock. Cheers Björn -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
