Do the systems differ in filesystem timestamp resolution? E.g. is the first one ext3, or ext4-that-was-once-ext3?

The first (failures) is nfs with /tmp on ext3

The second (all ok) is all ext3

This looks like an error in test logic, so not something for a point release.

It looks to me like func measureTick has the test backward:

func measureTick(path string) {
    st, err := os.Stat(path)
    if err != nil {
        // Default to one second, the most conservative value.
        mtimeTick = time.Second
        return
    }
    mtime := st.ModTime()
    t := time.Microsecond
    for mtime.Round(t).Equal(mtime) && t < time.Second {
        t *= 10
    }
    mtimeTick = t
}

I think that "for " should be "for !", negating the first half of the conjunction. If I'm reading it correctly, the current test will decide on microsecond precision for file systems with only second precision and vice versa.

I think the measureTick logic is correct. If rounding to t gives you the same time, you don't know anything--the time might have been a multiple of t anyhow. So you keep going. If rounding to t gives you a different time, then you can expect that a sleep of t will give you a different time.

@ianlancetaylor, yes, I was clearly misreading.

I wonder if maybe the os.Stat gets cached Linux data with microsecond resolution even though NFS only stores 1-second resolution, or something like that.

As another point, I am seeing the exact same failure as @pebbe

btracey@vader ~/gover/go/src $ for i in -s -r -v -m -p -i -o; do uname $i; done
Linux
3.14.14-gentoo
#1 SMP Thu Oct 2 04:23:17 MDT 2014
x86_64
AMD Opteron(tm) Processor 6172
AuthenticAMD
GNU/Linux

CL https://golang.org/cl/17953 mentions this issue.