Weird filesystem timestamps behavior on Linux/ARM64 workers

I’ve noticed really weird behavior of filesystem timestamps on some (but not all) ARM 64 workers.

It appears that on some workers, the filesystem is not preserving precise modification times when I do chtimes() (this is using Golang but should not matter much).

For example, logs:

filesystem_storage.go:254: [repo/filesystem] updating timestamp on /tmp/r-fs988822604/392/ee1/bc299db9f235e046a62625afb84902.f to 2020-09-23 14:03:22.925347001 +0000 UTC m=+6.534671441

but later the timestamp comes back as:

2020-09-23 14:03:22 +0000 UTC

Interestingly enough files are initially created with precise timestamps (including sub-second units), but it appears that chtimes() is causing precision loss.

As I mentioned, this is not consistent behavior, on most runs, the filesystem behaves correctly.

Recent example that did not have this problem:

Is there some variability in filesystem type in the underlying workers that causes this?