{"id":1615,"date":"2016-06-19T19:35:33","date_gmt":"2016-06-19T19:35:33","guid":{"rendered":"http:\/\/dtrace.org\/blogs\/ahl\/?p=1615"},"modified":"2016-06-19T19:35:33","modified_gmt":"2016-06-19T19:35:33","slug":"apfs-part3","status":"publish","type":"post","link":"https:\/\/ahl.dtrace.org\/2016\/06\/19\/apfs-part3\/","title":{"rendered":"APFS in Detail: Space Efficiency and Clones"},"content":{"rendered":"

This series of posts covers APFS, Apple’s new filesystem announced at WWDC 2016. See the\u00a0first post<\/a>\u00a0for the table of contents.<\/em>
\n<\/a><\/p>\n

Space Efficiency<\/h2>\n

A modern trend in file systems has been to store data more efficiently to effectively increase the size of your device. Common approaches include compression (which, as noted above, is very very likely coming) and deduplication. Dedup finds common blocks and avoids storing them multiply. This is potentially highly beneficial for file servers where many users or many virtual machines might have copies of the same file; it\u2019s probably not useful for the single-user or few-user environments that Apple cares about. (Yes, they have server-ish offerings<\/a> but their heart clearly isn\u2019t into it.) It\u2019s also furiously hard to do well as I learned painfully while supporting ZFS.<\/p>\n

Apple\u2019s sort-of-unique contribution to space efficiency is constant time cloning of files and directories. As a quick aside, \u201cfiles\u201d in macOS are often really directories; it\u2019s a convenient lie they tell to allow logically related collections of files to be treated as an indivisible unit. Right click an application and select \u201cShow Package Contents\u201d to see what I mean. Accordingly, I\u2019m going to use the term \u201cfile\u201d rather than \u201cfile or directory\u201d in sympathy for the patient readers who have made it this far.<\/p>\n

With APFS, if you copy a file within the same file system (or possibly the same container; more on this later), no data is actually duplicated. Instead a constant amount of metadata is updated and the on-disk data is shared. Changes to either copy cause new space to be allocated (so-called \u201ccopy on write\u201d or COW).<\/p>\n

I haven\u2019t seen this offered in other file systems, and it clearly makes for a good demo, but it got me wondering about the use case (UPDATE<\/strong>: btrfs supports this and calls the feature “reflinks”<\/a>–link by reference). Copying files between devices (e.g. to a USB stick for sharing) still takes time proportional to the amount of data copied of course. Why would I want to copy a file locally? The common case I could think of is the layman\u2019s version control: \u201cthesis\u201d, \u201cthesis-backup\u201d, \u201cthesis-old\u201d, \u201cthesis-saving because I\u2019m making edits while drunk\u201d.<\/p>\n

There are basically three categories of files:<\/p>\n