ApFS поддерживает временные метки (Time-stamps) с точностью до наносекунды. Такие метки очень важны в современных файловых системах, так как помогают реализовать атомарность и атомарные транзакции - одно из основных требований ACID для системы транзакций (например, СУБД). Атомарность гарантирует, что ни одна транзакция не будет частично зафиксирована в системе. Либо все подоперации выполняемой транзакции будут выполнены, либо ни одна не будет завершена.

Под безопасным атомарным сохранением (Atomic Safe-Save или ASS) подразумевается выполнение всех операций, связанных с сохранением, переименованием, копированием или перемещением файлов и каталогов без изменения каких-либо исходных данных файла, прежде чем они будут сочтены завершенными и файл будет сохранён, переименован, скопирован или перемещён.

Таким образом, при сохранении измененного файла ~dbg/MakeMoneyFast.key, приложение создает временную папку /private/var/folders/.../T/TemporaryItems/, в которой создается временный файл с таким же названием и атрибутами (но с новым индексным дескриптором и датой модификации). Именно в этот файл будет произведено сохранение. Далее новая версия из временной папке «перемещается» в местоположение исходного файла (правкой путей, жестких ссылок), а информация об временном файле и папке удаляются.
Также не стоит забывать про систему Версий macOS, которой также необходимо хранить копию измененного файла, в скрытой системной папке .DocumentRevisions-V100.
Теперь как обстоит дело при работе с папками. Возьмём документ ClutchConcertReview.rtfd это пакет («Bundle»), в нем содержится как минимум один файл RTF с каким-то количеством изображений и другого содержимого. Обычно есть папка с именем Contents, в которой может находиться файл с именем PkgInfo, содержащий четырехсимвольный тип документа (RTFD) и подпись приложения. Когда мы вносим изменения в пакет («Bundle»), программа проделывает похожий путь, как и в предыдущем примере. Создавая временную папку в директории /var/tmp/.../T/TemporaryItems/. Только в этот раз внутри этой папки копируются только фактически измененные файлы вместе с папкой, которая их содержит.

Ещё одно наиважнейшее нововведение придуманное не Apple, но используемое во благо всего и вся! Использование копирование при записи («Copy-on-write» или «COW») при работе с метаданными файловой системы и не только!
При использовании копирования при записи («COW») вносимые изменения не затрагивают исходные блоки (с информацией которая подлежит изменению), а дублирует их. Тем самым оберегая файловую систему от лишнего стресса при аппаратных ошибках (внезапного отключение электропитания и т.д.) возникающих в момент изменения информации.
Такой подход дал начало множеству других «фишек» которыми APFS может похвастаться.
И в первую очередь это защита от сбоев («Crash Protection») самих метаданных APFS. С помощью совмещения механизмов ведения контрольных точек («Checkpoint Descriptor & Data») и копирования при записи («COW») для изменения объектов файловой системы. Каждый раз когда информация записывается в контейнер APFS, создается новая контрольная точка суперблока, которая и будет считаться актуальной или главным суперблоком контейнера. Таким образом состояние системы всегда фиксируется и в случае сбоя откатывается на предыдущее состояние. Такой подход в работе файлов системы, привел к ненадобность ведения журнала, как это было в HFS+ и могло привести к снижению быстродействия.

Помимо прочего APFS использует 64-битные индексные дескрипторы («inodes»), что значительно расширяет пространство имён (более 9 квинтиллионов файлов на каждом томе, когда как HFS+ имела предел в 2,1 миллиарда).
Индексный дескриптор («inode») - это уникальный идентификатор, который идентифицирует объект файловой системы - файл или папку. Он содержит информацию об атрибутах и физическом расположении файла (метаданные). Связь логического имени файла с индексным дескриптором производится с помощью жёстких ссылок. Жёстких ссылок (как и логических имён) у одного файла может быть несколько.

Для того, чтобы проверить сколько у нас занятых и свободных inodes на дисках, через терминал вводим команду df -ih:

apple_big@Apple-bigs-Mac ~ % df -ih     
Filesystem       Size   Used  Avail Capacity iused     ifree %iused  Mounted on
/dev/disk2s5s1   91Gi   14Gi   37Gi    28%  567557 952208763    0%   /
devfs           193Ki  193Ki    0Bi   100%     670         0  100%   /dev
/dev/disk2s4     91Gi  1.0Mi   37Gi     1%       1 952776319    0%   /System/Volumes/VM
/dev/disk2s2     91Gi  272Mi   37Gi     1%     683 952775637    0%   /System/Volumes/Preboot
/dev/disk2s6     91Gi  244Ki   37Gi     1%      14 952776306    0%   /System/Volumes/Update
/dev/disk2s1     91Gi   39Gi   37Gi    52%  581435 952194885    0%   /System/Volumes/Data
/dev/disk1s1    9.9Gi  820Ki  9.9Gi     1%      94 104236946    0%   /Volumes/TEST_FLAG
map auto_home     0Bi    0Bi    0Bi   100%       0         0  100%   /System/Volumes/Data/home
/dev/disk4s1    1.9Gi  152Ki  1.9Gi     1%       9  19531071    0%   /Volumes/Untitled     

По колонке «Mounted on» - понимаем что это за том диска (например, том внешнего диска «TEST_FLAG»), по «%iused» - количество используемых inodes в процентном соотношении (у тома «TEST_FLAG» 0%). По колонке «ifree» cколько осталось свободных inodes (у тома «TEST_FLAG» 104236946).

Чтобы узнать индексный дескриптор файла, нужно через терминал перейти в папку с нашим файлов (в примере это рабочий стол) командой cd:

apple_big@Apple-bigs-Mac ~ % cd \desktop

И затем ввести команду stat:

apple_big@Apple-bigs-Mac desktop % stat testos.jpg     
16777223 12885868722 -rw-r--r-- 1 apple_big staff 0 99293 "Feb 11 08:42:09 2021" "Feb 10 12:38:32 2021" "Feb 11 08:42:08 2021" "Feb 10 12:38:32 2021" 4096 200 0 testos.jpg

Из данной строки мы получаем информацию об:

• st_dev - Идентификатор устройства: 16777223
• st_ino - Индексный дескрипторе (inode) файла: 12885868722
• st_mode - Правах на файл: -rw-r--r--
• st_nlink - Жёстких ссылок на файлу (если нет, то 1): 1
• st_uid, st_gid - Идентификатор пользователя и группы: apple_big, staff
• st_rdev - Идентификатор устройства: 0
• st_size - Его размер: 99Кб
• Временные метки:
  st_atime - дата последнего обращения к файлу
  st_mtime - дата модификации
  st_ctime - время последнего изменения прав на файл
  st_birthtime - дата создания
  
• st_blksize - Размер блока: 4096
• st_blocks - Число выделенных блоков под файл: 232
• st_flags - демон ревизии Apple (отслеживает редакции документа, 0х40 - измененный): 0X40
• st_gen - Номер поколения файла: 0

Также стоит заметить, что при каждой модификации исходного файла, его индексный дескриптор также будет меняться! Связано это в первую очередь со спецификой работы APFS «Atomic Safe-Save» и «Copy-on-write». При сохранении модифицированного файла, занятые им блоки не изменяются, а становятся частью нового файла с уже принятыми изменения. Поскольку новый файл является новый элементом файловой системы, ему присваивается новый индексный дескриптор. Естественно, та часть блоков, в которых находится не актуальная информация, встают в очередь на удаление.

Совместное использование пространства («Space Sharing») позволяет нескольким томам (максимум на контейнер, находящимся в одном контейнере, динамически увеличиваться и уменьшаться по мере необходимости и без надобности повторного разделения. Доступное пространство контейнера распределяется следующим образом: общий размер контейнера за вычетом пространства, используемого во всех томах контейнера. Или выражаясь другим языком, на блочном уровне нет границ, и отдельный взятый блок не принадлежит исключительно какому-то тому до его распределения. Если файл стирается на томе A, блоки освобождаются и доступны для новые данные. Эти блоки, вероятно, могут быть использованы позже в томе B или C родительского контейнера.
Помимо всего прочего у APFS появились дополнительные возможности и атрибуты для томов: Роли томов («Volume Roles») и логические группы томов («Volume Group»).

Основные виды ролей томов («Volume Roles»):

B = «Preboot» - том с загрузчиком необходимым для запуска macOS с зашифрованных томов (например, пользовательский интерфейс FileVault);
U = «User» - том содержит домашние каталоги пользователей;
S = «System» - том для хранения macOS;
R = «Recovery» - том с recoveryOS для сервисного обслуживания/восстановления macOS;
V = «VM или Virtual Memory» - том для хранения файлов подкачки виртуальной памяти («Swap Volume»);
I = «Installer» - том для временного хранилища данных, необходимых во время установки macOS;
D = «Data» - том содержащий все изменяемые данные (как системные так и пользовательские);
N = «Baseband» - том для хранения прошивок от радио модулей мобильных устройств iOS или iPadOS;
E = «Update» - том для обработки обновлений macOS;
X = «XART» - том для передачи данных в аппаратный диспетчер ключей («Secure Enclave») и из него (с приходом Apple Silicon Mac наличие этого тома на диске перестало иметь смысл);
H = «Hardware» - том для хранения прошивок от модулей используемых в устройстве iOS;
T = «Backups» - том для хранения резервных копий Time Machine в APFS;
Y = «Enterprise» - том для хранения данных устройства, если компьютер зарегистрирован в системе удаленного управления организации;
?! = «Prelogin» - том позволяющий системе загружаться до экрана входа в систему. Необходимый FileVault для управления входами пользователей в систему до запуска фактической (зашифрованной) macOS;
?! = «Reserved» - том зарезервированный, под что-то важное и неописуемое;
G = «EFI iDiagnostics» - временный том для хранения диагностических утилит iDiagnostics («AHT или Apple Hardware Test»);
C = «Time Machine Sidecar» - есть предположение что это том для хранения временных файлов при использовании функции «Sidecar» (iPad используется как дисплей вашего Mac'а);
0 = «No specific role» - том не имеющий специфической роли;

Основные виды логических групп томов («Volume Group»):

Начиная с версии macOS Catalina, ваш текущий системный том разделяется на два: в «Macintosh HD - Data», его роль устанавливается на «Data» и «Macintosh HD» с ролью «System» и группируется с предыдущим томом «Macintosh HD - Data». Два тома в этой группе имеют особые связи (Фирменные ссылки («Synthetic Firmlinks») чем-то похожи на Символические ссылки («Symbolic links») но работают в оба направления) и получают особую обработку со стороны Finder и файловой системы каждого тома. С точки зрения пользователя, эти два тома рассматриваются как один унифицированный том. Однако, если вы посмотрите через Дисковую утилиту, их окажется два!

Моментальные снимки («Snapshots») позволяют фиксировать состояние файловой системы выбранного тома (созданием копии метаданных файловой системы тома вместе со всеми данными, на которые он ссылается) в нужное вам время (если стоит галка автоматическое резервирование, то сохраняет одну моментальную копию загрузочного диска примерно каждый час и хранит ее в течение 24 часов. До возникновения потребности в пространстве Time Machine хранит дополнительную моментальную копию последней удачной резервной копии). При этом старые файлы, которые были зафиксированы, остаются доступны (только для чтения), даже если в последствии они были удалены или подвергались изменению.
Снимок создается практически моментально, так как сохраняются лишь пути к занятым блокам фиксируемых файлов и метаданным.
Но со временем, при условии создания новых снимков и использования этих файлов, неизбежно приводит к возрастанию числа их версий и размеров, равного размеру всех файлов. Для снижения «растущих аппетитов» сохраняются только те части файлов, которые меняются («дельты» или разницу между снимками). Так же для решения задачи экономии пространства, APFS использует механизм контроля - «Reaper». В обязанности которого, входит своевременное освобождение блоков ранее используемых под хранение моментальных снимков.
Для создания и управления моментальными снимками можно использовать штатную утилиту Time Machine или программы сторонних производителей: Сarbon Copy Cloner, SuperDuper!
Данный инструмент достаточно полезен, так как Вы можете в любой момент вернуться в исходное состояние. Но это не инструмент для резервного копирования (данные остаются на исходном диске и в случае выхода из строя накопителя или удалении тома, доступ к данным будет невозможен).
В нашем пример два файла: ~dbg/BikeRacing.key и ~dbg/CoffeeOrigins.key, которые уже зафиксированы снимком. И как вы помните, после фиксации (создания снимка), задействованные блоки под хранение этих фалов, становятся доступными только для чтения. То есть, после изменения файла ~dbg/BikeRacing.key та часть (второй желтый блок), что была изменена, уже не может быть перезаписана в старый блок, она пишется уже в новый блок (оранжевый блок). Таким образом продолжая делать снимки, у вас всегда будет возможно вернуться к исходной версии файла (при условии что том или контейнер не будут отформатированы или повреждены).

Поддерживает несколько различных вариантов шифрования файловой системы:

• Без шифрования.
• Один ключ шифрования для метаданных и пользовательских данных.
• Мульти-ключ шифрования, который шифрует каждый файл и даже части файла («экстенты»), с отдельным ключом и метаданные, зашифрованные другим ключом (Реализуемо только на Apple Silicon Mac).

MacOS Big Sur Apple расширила защиту системного тома, введя Подписанный системный том («Signed System Volume or SSV») или запечатанный системный том («Sealed System Volume or SSV»). Для доступа к которому, теперь нужно иметь доверенную криптографическую подпись Apple. Также начиная с macOS Catalina системный том больше не монтируется при запуске, вместо этого монтируется моментальный снимок системного тома, который используется в качестве загрузочного диска. Снимок доступен только для чтения и полностью неизменяем.

Более детальное описание работы «Signed System Volume или SSV» можно найти тут

Поддержка Разреженных файлов («Sparse Files») добралась и до APFS. Суть этой технологии заключается в том, чтобы более эффективно использовать дисковое пространство, сократив размеры занимаемого пространства файлом до размера его не нулевых (значимых) байт. APFS подсчитывает все нулевые (не значимые) байты разреженного файла и место их расположения (последовательность) и сохраняет эту информацию в своих метаданных. Тем самым высвобождая незанятые пространство под нужды пользователя и программ.

По факту, подобный тип файлов, большая редкость для рядового пользователя. В основном данную технологию применяют при создании:
Разреженного или растущего образа («Sparse-image») диска. Такие файлы имеют расширение .sparseimage.
Разреженного или рассеянного пакетного образа («Sparse-Bundle») диска. Такие файлы имеют расширение .sparsebundle.

Такие типы файлов можно создать через Дисковую утилиту, DropDMG или ССС.
Частое использование разреженных файлов приводит к значительной фрагментации томов, что в случае использования обычного жесткого диска, приводит к снижению производительности. А также в случаях нехватки дискового пространства (в некоторых версия macOS) может привести к потере записываемой информации в образ!

Приведем пример, у нас есть два одинаковых пакета («Bundle») с презентацией Keynote ~eric/TOP_SECRET_APFS.key, но один из них является разреженным пакетом («Sparse-Bundle»). Пакет который не имеет атрибута разреженного («Sparse»), будет занимать больше дискового пространства, так как его нулевые байты будут занимать фактическое пространство на диске. Когда как пакет имеющий атрибут разреженного, обходится лишь небольшой записью в метаданных файловой системы.

Выравнивание износа («Wear-leveling») обычно выполняется встроенным контроллером SSD и не контролируется файловой системой или операционной системой. Однако способ, которым файловая система обрабатывает собственные метаданные и осуществляет запись файлов, может значительно повлиять на работу, требуемую SSD для поддержания низкого уровня износа его блоков.
И в APFS есть такая функция: копирование при записи «Copy-on-write»). Запись измененных данных производится в другой блок и затем старый блок помечается как неиспользуемый. Это не меняет общего количества циклов стирания, но позволяет более равномерно распределять их по твердотельному накопителю, даже когда активны всего лишь несколько файлов.
«Space manager» или «Spaceman» - это механизм отвечающий за распределение и освобождение блоков для хранения объектов файловой системы и данных файлов.
«В контейнере APFS есть только один Spaceman», который управляет пространством выделенным под данный контейнер и его тома (совместно использующие пространство этого контейнера).
«Reaper» - это механизм, с помощью которого APFS удаляет большие объекты, для которых требуется несколько транзакций в файловой системе. И для каждого контейнера есть только один «Reaper». Также этот механизм отвечает за очистку удаленных моментальных снимков.

По задумке APFS должна была позволить делать копирование файлов и папок (в рамках одного тома), практически мгновенно и без использования дополнительного места. Вместо того, чтобы дублировать содержимое блоков занятых копируемым файлом ~eric/Archive/TOP_SECRET_APFS.key из одного места в другое, клоны («Clones»), создают раздельные ссылки на исходные блоки. Внося изменения в новый файл ~eric/TOP_SECRET_APFS.key с помощью этой ссылки, данные разделяются для двух ссылок (искомые блоки остаются без изменений, до тех пор пока оба файла не будут изменены), так что они фактически будут видеть совершенно разный контент. Это подход не только должен был сделать копирование и сохранение файлов исключительно быстрым, но также позволило бы сэкономить место на томе.
Но и тут не без ложки с дёгтем! Предположим у нас есть несколько крупных образов имеющие общие блоки данных. В случае частичного повреждения этих блоков все три файла ссылающихся на эти блоки, будут повреждены!