[jdmnd]

  Timestamps are 64bit nanoseconds

As far as I can tell, this will overflow in just 11 years – 2028-06-15 09:33:27.3709551615 UTC

Why would this go into a new standard? Is there a practical use for such a high level of granularity?

edit: off by a factor of 10 in my calculation... It's actually

2554-07-21 23:34:33.709551615 UTC

[raldi]

By my math, we're fine for almost 600 years:

http://wolframalpha.com/input/?i=2%5E64+nanoseconds+from+now...

[cimnine]

But that should be 'from 1.1.1970', i.e. from the unix epoch. Still far out, though.

[twoodfin]

2^64 nanoseconds is > 580 years. Even cutting it in half for signed values is still likely 10X the expected lifetime of this particular iteration of APFS.

The granularity is probably useful for establishing an ordering (even somewhat arbitrarily) for highly concurrent file system operations, and thus potentially skipping a bunch of expensive synchronization.

[jsjohnst]

As mentioned in the article, they are unsigned 64bit integers though.

[cugu]

Don't take anything in the article as completely proven. There are some guesses in there.

[DuskStar]

2^64 nanoseconds is ~584 years, though.

[lowercaseman]

Found this: https://github.com/jbenet/nanotime. No idea if related in any way or used for APFS but it was interesting enough for a quick read. This one is MIT licensed. A little more searching I found a variant but it's done with big-endian so it's much different.

[achivetta]

64-bit nanosecond values are actually pretty common on Darwin already. See e.g. clock_gettime_nsec_np(3).