HFSPlus, also known as Mac OS Extended, replaced the Hierarchical File System (HFS) as the primary file system of Apple computers with Mac OS 8.1 in 1998. However, HFS+ itself was also replaced with the Apple File System (APFS), released with macOS High Sierra in 2017.
HFS Plus is a specification of how a volume (files that contain user data, along with the structure to retrieve that data) exists on a disk (the medium on which user data is stored). HFS Plus allocates space in units known as allocation blocks, which is simply a group of consecutive bytes. The size (in bytes) of an allocation block is a power of two, greater than or equal to 512, which is set when the volume is initialized.
Files on an HFS volume have two components or forks: a data fork and a resource fork, either of which may be empty (zero length). Files and directories also contain a small amount of additional information (known as catalog information or metadata) such as the modification date or Finder info.
Every HFS Plus volume has a volume header, which contains information about the volume, such as the date and time of the volume’s creation and the number of files on the volume, as well as the location of the other key structures on the volume.
The volume header is always located at 1024 bytes from the start of the volume. A copy of the volume header, known as the alternate volume header, is also stored starting at 1024 bytes before the end of the volume. The first 1024 bytes of volume (before the volume header), and the last 512 bytes of the volume (after the alternate volume header) are reserved. All of the allocation blocks containing the volume header, alternate volume header and the reserved areas are marked as used in the allocation file.
HFS Plus uses a number of interrelated structures to manage the organization of data on the volume. An HFS Plus volume contains five special files, which store the file system structures required to access the file system payload such as the folders, user files, and attributes.
Special files only have a single fork (the data fork) and the extents of that fork are described in the volume header. The special files are:
- Catalog file: It is a special file that describes the folder and file hierarchy on a volume and contains vital information about all the files and folders on the volume, as well as the catalog information, for the files and folders that are stored in the catalog file.
- Extents overflow file: An extent is a contiguous range of allocation blocks allocated to some fork and is represented by a pair of numbers: the first allocation block number and the number of allocation blocks. For a user file, the first eight extents of each fork are stored in the volume’s catalog file. Any additional extents are stored in the extents overflow file. The extents overflow file also stores additional extents for the special files except for the extents overflow file itself.
- Attributes file: The attributes file is another special file which contains additional data for a file or folder.
- Allocation file (bitmap): The allocation file is a special file which specifies whether an allocation block is used or free. This performs the same role as the HFS volume bitmap, although making it a file adds flexibility to the volume format.
- Startup file: The startup file facilitates booting of non-Mac OS computers from HFS Plus volumes.
There is also another file known as the bad block file, which prevents the volume from using certain allocation blocks because the portion of the media that stores those blocks is defective. The bad block file is neither a special file nor a user file; this is merely convention used in the extents overflow file.
Figure: Organisation of an HFS Plus Volume
Apple File System (APFS) replaced HFS Plus as the default file system for macOS High Sierra and later. It offers improved file system fundamentals as well as several new features.
APFS is not an extension of HFS+. From HFS+ we are familiar with special files such as the catalog file, attributes file, allocation file and extents overflow file. However, APFS uses a different strategy to secure changes in the file system and neither these files nor does the journal exist anymore.
APFS is structured in a single container that can contain multiple APFS volumes. Moreover, in APFS, a container is the primary object for storing data which needs to be more than 512 Mb to contain more than one volume, > 1024Mb to contain more than 2 volumes and so on.
Each container contains one or more volumes or file systems, each of which has its own set of files and directories.They also have their own crash protection and disk space allocation scheme.
Each filesystem structure in APFS starts with a block header. This header starts with a checksum for the whole block and contains information on the copy-on-write version of the block, the block id and the block type.
The CS (Container Superblock) is the entry point to the filesystem. It contains information on the block size, the number of blocks and pointers to the space manager and the block IDs of all volumes are stored in the superblock.
A checkpoint is a historical state of the container. Each checkpoint is initialized with CS and the current state is usually the last CS in the CS collection.
A checkpoint involves both the container and volume metadata.The main difference between a checkpoint and a snapshot is the user ability to restore the file system from stored snapshots.
The VS (Volume Superblock) exists for each volume in the file system. It contains the name of the volume, ID and a timestamp.
It contains records of used and unused blocks. There is only one bitmap system that covers the whole container and is common to all volumes in the file system. From HFS+ we are familiar with the allocation file, however APFS uses a collection of blocks to store the Bitmap Structures (BMS).
The Space Manager (sometimes called spaceman) is used to manage allocated blocks in the ApFS container. Stores the number of free blocks and acts as a pointer to the allocation info files.
Allocation Info File
The allocation info file works as a missing header for the allocation file. The allocation files length, version and the offset of the allocation file are stored here.
File and folder B-Tree
Records all files and folders in the volume. It performs the same role as the catalog file in HFS+.
A clone is a copy of a file or directory that occupies no additional space on disk. The standard way to make a clone is to make a complete new copy of the file and save it elsewhere, where it will take up an equal amount of space as the original file.
However, with APFS, if the clone is to be on the same drive, the clone takes up no extra space but refers to the same data blocks. When a change is made to the cloned copy, only the changes are written. The changed clone uses some of the data blocks as the original plus new blocks that contain the changes only.
- Free Space Is Shared Between Volumes
Many files systems, including HFS Plus, support only a single volume per partition. Because free space can’t be shared across partitions, each volume’s size is set when partitioning the storage device, and each volume can only grow into its available free space.
In contrast, Apple File System supports multiple volumes within a single partition, which allows all of those volumes to share their free space. All of the volumes in an Apple File System partition can grow and shrink independently; space that’s freed when one volume shrinks can be used when another volume grows.
Security and privacy are fundamental in the design of Apple File System, which implements strong full-disk encryption, encrypting files and all sensitive metadata. Apple File System supports the following encryption models for each volume in a container:
- No encryption
- Single-key encryption
- Multi-key encryption with per-file keys for file data and a separate key for sensitive metadata
- Snapshots and backup
APFS brings a much-desired file system feature: snapshots. A snapshot lets you freeze the state of a file system at a particular moment and continue to use and modify that file system while preserving the old data. It does so in a space-efficient fashion where, effectively, changes are tracked and only new data takes up additional space.