Format: Choose APFS or Mac OS Extended (Journaled). Disk Utility shows a compatible format by default. If you see an Erase Volume Group button, the volume you selected is part of a volume group. In that case, you should erase the volume group. Otherwise, click Erase to erase just the selected volume. You might be asked to enter your Apple ID. Apple’s macOS 10.13 High Sierra brings a new file system named “Apple File System”, which largely replaces the older HFS+ file system. Apple File System, also known as APFS, has been used by default on iPhones and iPads since iOS 10.3, and is also used on the Apple Watch and Apple TV—but now it’s finally on the Mac, too. // Read the given physical block from disk // and return its contents as a pointer to an nxsuperblockt. ©. Apple With the release of macOS High Sierra and its upgrade for SSD-based startup volumes to Apple File System (APFS), Macworld readers had many questions about how this new filesystem—more.
Though the feature wasn’t mentioned in Apple’s WWDC 2016 keynote, I’m most excited about the introduction of the Apple File System, or APFS. The preliminary version of the developer documentation is online now, and it looks like the new file system introduces a whole boat-load of solid features—including a few out of the ZFS playbook.
APFS looks to be a major update over Apple’s old and creaky HFS+ file system, which has been around in one form or another for decades. It has been the subject of expansions and additions over the years, but HFS+ never approached the extensibility and flexibility of current next-generation file systems. Rather than continuing to bolt stuff onto the old code, we now (finally!) get a new file system that has some truly compelling features.
First, the caveats
But before we get into the good stuff, let’s real quick talk about the bad stuff—or, at least, the 'this is still in development so here’s what doesn’t quite work' stuff. Apple’s documentation notes that because APFS is still a developer preview, you cannot use an APFS volume as a startup disk. You also can’t use it as a Time Machine volume or part of a Fusion Drive configuration, nor can you use File Vault encryption on it.
Perhaps most importantly, the file system currently is case-sensitive, and this cannot be disabled. HFS+ breaks with most Unix-y file systems in that it can be configured to not use case sensitivity; in fact, running OS X—ahem, macOS, sorry—with case-sensitive HFS+ can lead to its own problems. But, for now, if you want to use APFS, you’re going to do so on a non-startup volume, and you’re going to have to deal with case sensitivity.
In light of the current limitations, Apple recommends you test APFS on an external volume that doesn’t contain anything important. You can get started with the
hdiutil
utility—presuming you've got access to Sierra.![Apfs Apfs](https://www.techspot.com/articles-info/1520/images/2017-11-08-image-4.jpg)
The first fun bits
The documentation lists a number of characteristics of the file system. To start, it shows that APFS is based around inodes, with 64-bit inode numbering support. It also massively increases the granularity of object time-stamping: APFS supports nanosecond time stamp granularity rather than the 1-second time stamp granularity in HFS+. Nanosecond timestamps are important in a modern file system because they help with atomicity—in a file system that keeps a record of writes, having nanosecond-level granularity is important in tracking the order of operations.
APFS also adds a copy-on-write metadata scheme that Apple calls 'Crash Protection,' which aims to ensure that file system commits and writes to the file system journal stay in sync even if something happens during the write—like if the system loses power.
There are a few other neat things in the first section of documentation, including support for sparse files, TRIM support (presumably for Apple and non-Apple SSDs alike by default), Extensible Block Allocation support for lazily initializing data structures as needed on a huge disk instead of having to set everything up at once, and, interestingly, mandatory use of SMB for sharing APFS volumes over a network. AFP is not supported for APFS sharing. And, lest we forget our roots, the documentation notes that APFS has built-in support for extended object attributes, which should help if you still have some need of resource forks.
The more exciting stuff
Apple Apfs Format
The new file system offers an improvement over Apple’s previous full-disk encryption File Vault application. For one, APFS supports encryption natively instead of through File Vault. There are three modes of operation: no encryption, single-key encryption, and multi-key encryption with per-file keys and another key for sensitive metadata. Both AES-XTS and AES-CBC cipher variants are supported, 'depending on hardware.' This lets you apply an adaptable amount of encryption depending on what your security needs might be—from 'I don’t care' to 'I don’t want anyone swiping the disk out of my computer' up to 'NO ONE ELSE MUST KNOW MY SECRETS.'
Write coalescing finally makes an appearance on Apple hardware. Long a staple of enterprise disk arrays, this feature gives the file system some latitude in committing data to disk, taking a bunch of short potentially unrelated writes and combining them together into one longer write that more efficiently uses the physical storage beneath it.
A feature called 'fast directory sizing' is purported to give macOS a fast way to query the size of a directory and all its child objects, rather than having to wait while a bunch of stat calls complete.
The most exciting stuff
Snapshots and clones both are going to be available in APFS. Snapshots let you throw off a read-only instance of a file system at any given point in time; as the file system’s state diverges away from the snapshot, the changed blocks are saved as part of the snapshot. This is similar in concept to Microsoft’s shadow copies, and it’s an incredibly handy feature. There are obviously huge implications here in how Time Machine works—a true file system set of snapshots could totally replace the kludgy and aging mechanism of hard links that Time Machine builds and maintains.
Snapshots and clones both are going to be available
Clones differ from snapshots in that clones are writable instead of read-only. According to the documentation, APFS can create file or directory clones—and like a proper next-generation file system, it does so instantly, rather than having to wait for data to be copied. A cloned file or directory stores the changes made between it and the original objects, giving you a writable, editable, point-in-time copy of a file or a directory. As the documentation points out, this is an easy way to create document revisions or do versioning of anything you might want to track.
Also interesting is the concept of 'space sharing,' where multiple volumes can be created out of the same chunk of underlying physical space. This sounds on first glance a lot like enterprise-style thin provisioning, where you can do things like create four 1TB volumes on a single 1TB disk, and each volume grows as space is added to it. You can add physical storage to keep up with the volume’s growth without having to resize the logical volume.
First chance to see
Devs at WWDC are getting their hands on APFS today, and the first formal session walking through the technology is tomorrow, so we’re expecting lots more news to bubble up over the next couple of days. We’re also keenly interested in getting our hands on the tech and putting it through its paces—that’ll have to wait until the developer preview of macOS Sierra becomes available to us, but we’ll start diving in as soon as we can.
Update March 30, 2020: Perhaps this is exacerbated by changes in macOS Catalina, but we have found that APFS performance on the slower 5400RPM HDDs to be unacceptably poor. Stall analysis indicates that APFS gets bogged down when renaming files, especially in folders with many other files. We do not recommend using APFS on the slower 2.5' 'slim' HDDs. Sketch software for windows 10.
My APFS-formatted rotational disks have always felt slower than when they were HFS+ formatted. The speed of copying files to them felt about the same, but slogging through folders in the Finder was taking a lot longer. At first I shrugged it off to the filesystem being new; 'It just needs some tuning, it will come along.' But that performance hasn't come along, and after running some tests and collecting a lot more data, I'm convinced that Apple made a fundamental design choice in APFS that makes its performance worse than HFS+ on rotational disks. Performance starts out at a significant deficit to HFS+ (OS X Extended) and declines linearly as you add files to the volume.
The rest of this article is fairly technical, here are the key takeaways:
- Enumerating an APFS filesystem on a traditional HDD (rotational disk) will take 3-20X longer than HFS+ on the same hardware.
- This performance difference is most noticeable on a macOS startup disk that is (or includes) a rotational disk.
- If Apple doesn't make some concessions in the APFS filesystem to accommodate the slower seek performance of HDD devices, then a rotational device will never be able to provide acceptable performance as a production macOS startup disk.
Test Setup
![Apple Apple](https://thechive.files.wordpress.com/2017/04/share-a-wholesome-meme-with-a-friend-to-make-their-day-215.jpg?quality=85&strip=info&w=600)
I wanted to see how an APFS formatted volume performs over time under 'normal' usage conditions and how that compares to an HFS+ formatted volume under the exact same conditions. To do this, I had to set up a simulation that would produce identical changes on two volumes to allow for a consistent, objective analysis of the filesystem performance. When I refer to 'filesystem performance,' I'm specifically referring to how long it takes the filesystem to do transactional tasks. Read and write performance depends almost entirely on the speed of the media, so I wanted to factor that out of my tests. Enumerating the contents of the filesystem is a good exercise of filesystem transactional performance, so I decided to test the enumeration of 1 million files on each an APFS and HFS+ filesystem over a period of simulated modifications to the filesystem.
The destination device in these tests is a 2TB Western Digital MyBook Duo split into two equal partitions. One partition is formatted HFS+, the other APFS. Spotlight was disabled on both volumes. Snapshot support and APFS defragmentation were varied in different tests to determine whether they had any effect on filesystem performance.
The number of files in the file set is constant – 1 million files, 111,000 directories (files nested three directories deep). To make the simulation closer to real-life, the file size distribution roughly follows 1/x2 – it’s weighted more heavily towards smaller files. Each individual file size is determined randomly, but in a pattern that follows that size distribution histogram. Average data set size is ~18GB. Max file size is 20GB. The payload data is randomly generated, non-zero data. At the end of each cycle, a random selection of 5% of the files are replaced with a randomly-selected file size (again, matching the histogram). Average size of the replacement data set is <1GB. Replacement data is randomly generated. Files are replaced atomically.
Apfs Formatting
Carbon Copy Cloner was used to facilitate the file copying, but a separate utility was created for data collection (that tool uses fts*() system calls to perform the filesystem enumeration). There are three backup tasks: Source > HFS+, Source > APFS. A third 'stub' task imposes a 10-second 'quiescence' delay, runs the tool to collect performance metrics, makes the randomized changes to the source, then starts the cycle over again. This cycle was repeated 20 times, simulating the kind of disk usage that might occur over several weeks or months. The duration of the copying tasks was not recorded – we're only interested in the transactional performance of the destination filesystems, so we're only measuring the enumeration performance of the destination volumes after making changes to those filesystems.
Results
Enumeration on HFS+ was very consistent in all five simulations; always between 20 and 27 seconds. APFS enumeration started at about 80 seconds, but increased in a linear manner to about 300 seconds in the first ten cycles, then leveled off around 300-380 seconds after 20 cycles.
Because the tests were repeated over a short time interval, a modified version of CCC was used that would retain all snapshots on the destination APFS volume, thus simulating the result from daily backups. I then repeated the simulation with snapshots disabled on the APFS destination. The results of this test were unexpected, so I repeated that same test again and got the same results. Enumeration performance was consistently worse when snapshots were not retained on the destination. In the fourth simulation only some of the snapshots were retained and I found more erratic results, albeit directly between that of the test with snapshots disabled and all snapshots retained. Finally, for the fifth simulation defragmentation was enabled on the APFS destination volume via diskutil. I found no significant difference in enumeration performance when defragmentation was enabled.
Discussion
After the very first simulation, APFS starts at a deficit — APFS takes three times as long to enumerate a million files on a rotational disk compared to HFS+ enumerating the exact same collection of files on the exact same hardware. This result on its own is staggering. As you add and remove files from the volume, however, the performance continues to decline. After just 20 cycles, APFS enumeration performance is 15-20 times worse than HFS+ performance.
Audibly you can hear a significant difference between enumeration on each filesystem. Enumeration on APFS is very chatty. With HFS+, there’s almost no noise at all. So, why is APFS enumeration performance so much worse than HFS+ on rotational media? The answer lies in how rotational disks retrieve data from the media, and how APFS and HFS+ arrange the file data and filesystem metadata on the media. Consider the graphic below:
HFS+ preallocates space on the disk for filesystem structures (that's the light blue section). As you add files to the volume, the file data (green) goes to the end of the disk, but the filesystem metadata (e.g. the file name and attributes, the folder hierarchy) stays clumped together. When you enumerate the files on that volume, the drive head has very little moving to do to read all of the filesystem structures.
APFS, on the other hand, does not clump filesystem metadata together, rather it's stored alongside the file data. When you enumerate files on an APFS volume, the drive head has to constantly dart back and forth across the platter to fetch each individual file and folder records. This activity generates the 'chatter' that you hear when an APFS-formatted HDD is doing filesystem enumeration, and it's this high-latency seek performance of the HDD that causes enumeration to go so slowly. This only gets worse over time, because you're adding file data and filesystem metadata to the end of the disk, thus always spreading filesystem metadata further out on the disk.
Solid State Drives don't have this seek penalty. SSDs can read the first and last block of the device without any seek penalty at all. Remember when Apple introduced APFS and said that it was 'optimized for Flash/SSD storage'? Rar software for pc free download. This randomized placement of data and filesystem metadata may have been what they were referring to, and another way of saying that would have been, 'APFS is not optimized for HDDs.'
Can't APFS defragmentation help with this?
Apple File System Apfs
Apple quietly added a defragmentation feature to APFS in macOS Mojave. APFS defragmentation is disabled by default, and only lightly documented in the diskutil man page. Apple gives no indication of what this defragmentation feature actually does, in particular whether it defragments filesystem structures. Based on the results of the tests above, however, I would conclude that APFS defragmentation does not cause filesystem metadata to be physically clumped together on the disk.
Apple Apfs Media
How does this performance affect me directly?
Typically when you're using a filesystem, you're not attempting to enumerate the whole thing. Enumeration occurs when you're looking for something (not via Spotlight, but browsing through folders), and it occurs with gusto when you open up the Get Info panel on a folder. So when you're trying to see how large a folder is or browsing through several folders, that's going to take a lot longer on an APFS volume atop rotational media than it is on an HFS+ volume on the same hardware.
The other time that the performance difference will be starkly noticeable is when you're booting macOS from a rotational HDD. macOS seeks and stats thousands of files during the startup process, and if that's taking 15 times longer on a rotational disk, then your 30-second startup process is going to turn into 8 minutes. When the system does finally boot, the system and apps will still feel sluggish as all of your applications load, and those applications each stat hundreds of files. Mac dvdripper pro 8 0 4. The system is still usable, especially as a rescue backup device, but it's not the kind of experience you'd want for a production startup disk nor for a high-stress restore scenario.
The bottom line is this — If Apple doesn't make some concessions in the APFS filesystem to accommodate the slower seek performance of HDD devices, then a rotational device will never be able to provide acceptable performance as a production macOS startup disk. If performance of your rescue backup is of paramount importance, then you should consider replacing your HDD backup disk with an SSD. We offer some suggestions here.
Apfs File System Mac
Does this mean I should avoid using APFS on my HDDs?
No, let's not throw out the baby with the bath water. APFS has loads of really nice features, like snapshots and volume space sharing. Managing volumes within an APFS container is a dream compared to the older method of preallocating space to specific partitions. It's important to understand why we might expect to see performance differences between the two filesystems and when that might impact your use of the filesystem, but this one performance aspect on its own isn't enough reason to avoid it.