Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

APFS filesystem format

blog.cugu.eu

Post reply on HN
Print view View original

11–20 of 148 posts

Re: APFS filesystem format

#11

Post by xoa »

Very, very cool exercise. For anyone who hasn't been following APFS much though, worth knowing that Apple has stated in their AFPS FAQ [1] that they do intend to directly "document and publish the APFS volume format specification" themselves later this year. Presumably (as they do with other stuff they develop) they want to be able to more easily make breaking changes during the shakedown period of initial public deployment (first on iOS right now, later on Macs, though maybe not a default option until 10.13 this Summer/Fall). That'd be the most helpful in getting read/write into FUSE and other platforms should anyone choose to do so.

---

1. https://developer.apple.com/library/content/documentation/Fi...

Re: APFS filesystem format

#12

Post by 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

Re: APFS filesystem format

#13

Post by twoodfin »

Does anyone know or can speculate on the purpose of the 4 "alignment" bytes in the node block header? Are they for alignment (in which case it's strange to have them at the beginning instead of the end)? Or are they describing alignment (in which case it's strange to need 32 bits)?

Re: APFS filesystem format

#14

Post by DuskStar »

jdmnd wrote: post #12

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

2^64 nanoseconds is ~584 years, though.

Re: APFS filesystem format

#15

Post by raldi »

jdmnd wrote: post #12

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

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

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

Re: APFS filesystem format

#17

Post by cimnine »

raldi wrote: post #15
jdmnd wrote: post #12

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

By my math, we're fine for almost 600 years: http://wolframalpha.com/input/?i=2%5E64+nanoseconds+from+now...

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

Re: APFS filesystem format

#18

Post by twoodfin »

jdmnd wrote: post #12

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

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.

Post reply on HN