APFS краща, ніж macOS Journaled?

APFS — гарний вибір для твердотілих накопичувачів та флеш-накопичувачів. Mac OS Extended — це файлова система, яка використовується у macOS 10.12 або ранішій. MacOS Extended краще підходить для механічних дисків або дисків, які використовуються у старіших версіях macOS.

Чому macOS не записує дані на зовнішній накопичувач?

За промовчанням, macOS не може записувати файли на більшість флешок та зовнішніх жорстких дисків. Так відбувається тому, що вони відформатовані у файловій системі NTFS. Відформатуйте свою флешку або зовнішній накопичувач у ExFAT, файлову систему яка підтримує macOS та Windows.

Що викликає втрату даних у томі APFS?

Найчастішою причиною втрати даних може бути пошкодження диска. Диски з файловою системою APFS дуже рідко заражаються вірусами, але можуть пошкодити їх та призвести до втрати важливих даних. Більше того, якщо ви не можете правильно вимкнути свій Mac, і він раптово закривається до того, як дані були збережені, ви знову ж можете втратити дані.

Чи можна підключити накопичувач із файловою системою NTFS до macOS?

Mac OS вміє тільки читати інформацію з дисків у форматі NTFS, а запис недоступний. Існує декілька варіантів вирішення задачі: Включити підтримку стандартними засобами ОС; Встановити сторонній драйвер NTFS (Paragon NTFS for Mac, Tuxera NTFS for Mac тощо).

Чи можна підключити жорсткий диск з файловою системою APFS до Windows?

Як і у випадку з підключенням NTFS до macOS, потрібно скористатися стороннім драйвером для можливості повного керування накопичувачем.

Алгоритм відновлення даних APFS та структура файлової системи

Автор: Valery Martyshko
Редактор: Vladyslav Kupriyenko
Оновлено: 19.09.2024 11:30

«ApFS» пропонує можливість відновлення файлової системи, включаючи старі або видалені версії файлів. Суперблок контейнера містить посилання на структуру контрольної точки. Контрольна точка посилається на попередні суперблоки контейнера, який містить інформацію в більш старому стані файлової системи. Таким чином, можна відновити кілька минулих станів шляхом аналізу ланцюжка суперблоку контейнера.

Алгоритм відновлення даних APFS та структура файлової системи

Зміст

Перейти до перегляду

🍏 Топ програм для відновлення даних з APFS диска або як відновити Apple MacOs диск у Windows 🍏

Контейнери та Томи

Структура файлової системи APFS має вигляд b-дерева, де кореневий каталог з даними – це листя всього дерева. Усі гілки зберігають лише посилання на наступний вузол, поки не дійдуть до листя. Файлова система використовує контейнери в якості осередків зберігання. Ці контейнера можуть містити кілька томів. Також він є основним об’єктом для зберігання даних. Для одного тому розмір контейнера повинен бути понад 512 МБ, для двох томів – більше 1024Мб і т.д.

На малюнку нижче подана структура файлової системи «ApFS».

Кожен елемент цієї структури (крім файлу розподілу) починається з 32-байтового заголовка блоку, який містить деяку загальну інформацію про блок. Далі йде тіло файлової системи. Воно складається з наступних елементів:

0x01: Суперблок контейнера (Container Superblock);
0x02: Вузол (Node);
0x05: Менеджер простору (Space manager);
0x07: Файл розміщення (Allocation Info File);
0x0C: Контрольна точка (Checkpoint);
0x0D: Суперблок тома (Volume Superblock).

Контейнери зазвичай точно такі ж, як записи в таблиці розділів GUID (GPT). У них є власний захист від збоїв, і схема розподілу дискового простору. Кожен контейнер містить один або декілька томів, кожен з яких має власний простір імен, набір файлів та каталогів.

Файлова система «ApFS» не підтримує безпосередньо програмний «RAID», але його можна використовувати з томами Apple RAID для підтримки чергування (RAID 0), віддзеркалення (RAID 1) та склеювання (JBOD).

З 64-бітовим індексом томи «ApFS» підтримують до 9 квінтильйонів (1018) файлів.

Нова файлова система від Apple використовує наносекунди для встановлення міток часу. У HFS+ мітки часу були встановлені з точністю до секунди. Це зменшило кількість збоїв при передачі даних та інших файлових операціях.

«ApFS» має вбудовану систему шифрування та використовує системи AES-XTS або AES-CBC, в залежності від пристрою. Користувач може використовувати кілька ключів шифрування для безпеки даних навіть у разі фізичної поломки носія.

Це далеко не повний список нововведень, якими володіє «ApFS».

Розділи які відформатовані в «ApFS», не розпізнаються OS X10.11 Yosemite та більш ранніми версіями операційної системи.

Block Header (Заголовок блока)

Кожна структура файлової системи в «ApFS» починається з заголовка блоку. А сам заголовок починається з контрольної суми. Інша інформація в заголовку містить в собі версію блоку з копією при записі, ідентифікатор блоку та його тип.

Position	Size	Type	ID
0	8	uint64	Checksum
8	8	uint64	block ID
16	8	uint64	Version
24	2	uint16	Block type
26	2	uint16	Flags
28	4	uint32	Padding

З таблиці ми бачимо, що 1uint = 1 біт, 8 біт= 1 байту, з цього uint 64=8, uint32=4, і uint16 = 2 байтам.

Container Superblock

Суперблок контейнера (Container Superblock) – це вхідна точка в файлову систему. Через структуру файлової системи з контейнерами і гнучкими томами, розподіл необхідно обробляти на рівні контейнера. Суперблок контейнера містить інформацію про розмір блоку, їх кількість та покажчик в менеджері простору для цього завдання. Крім того, в суперблоці зберігаються ідентифікатори (ID) блоків всіх томів. Для зіставлення ідентифікаторів блоків блокам зміщення, зберігається покажчик на карту блоків B-дерева. Це дерево містить записи для кожного тому з його ідентифікатором та зміщенням. Суперблок контейнера – це найвищий рівень файлової системи.

Він має такий вигляд:

Offset (HEX)	Type	Id	Description
0	tApFS_COH	Header	Container Object Header
20	uint32	MagicNumber (NXSB)	The value to verify reading a Container Superblock.
24	uint32	BlockSize	Container block size (bytes)
28	uint64	BlocksCount	Number of container blocks
30	uint64	Features	Bitmap for container’s main features
38	uint64	ReadOnlyFeatures	Bitmap for container’s main features (read-only)
40	uint64	IncompatibleFeatures	Bitmap for container’s incompatible features
48	tApFS_Uuid	Uuid	Container’s UUID
58	tApFS_Ident	NextIdent	Next identifier for new logical or virtual object
60	tApFS_Transaction	NextTransaction	Next transaction number
68	uint32	DescriptorBlocks	Number of blocks used by descriptor
6C	uint32	DataBlocks	Number of blocks used by data
70	tApFS_Address	DescriptorBase	Descriptor base address or physical object identifier with address tree
78	int32	DataBase	Database address or physical object identifier with address tree
80	uint32	DescriptorNext	Next descriptor index
84	uint32	DataNext	Next data index
88	uint32	DescriptorIndex	Index of first valid element in descriptor segment
8C	uint32	DescriptorLength	Number of blocks in descriptor segment used by superblock
90	uint32	DataIndex	Index of first valid element in data segment
94	uint32	DataLength	Number of blocks in data segment used by superblock
98	tApFS_Ident	SpaceManagerIdent	Identifier for Space Manager logical object
A0	tApFS_Ident	ObjectsMapIdent	Identifier for container object map physical object
A8	tApFS_Ident	ReaperIdent	Logical object identifier
B0	uint32	ReservedForTesting
B4	uint32	MaximumVolumes	Maximum possible number o volumes in container
8	tApFS_Ident	VolumesIdents[100]	Volume array of virtual object identifiers
3D8	uint64	Counters[32]	Array of counters storing container information
4D8	tApFS_BlockRange	BlockedOutOfRange	Physical range of blocks that cannot be used
4E8	tApFS_Ident	MappingTreeIdent	Physical object identifier of the tree used to track objects moved from locked storage.
4F0	uint64	OtherFlags	Bitmap of other container’s functions
4F8	tApFS_Address	JumpstartEFI	Physical object ID with EFI driver data
500	tApFS_Uuid	FusionUuid	Fusion container UUID or zero for non-Fusion containers
510	tApFS_BlockRange	KeyLocker	Container key tag location
50	uint64	EphemeralInfo[4]	Field array used to manage ephemeral data
540	tApFS_Ident	ReservedForTesting
548	tApFS_Ident	FusionMidleTreeIdent	Fusion devices only
550	tApFS_Ident	FusionWriteBackIdent	Fusion devices only
558	tApFS_BlockRange	FusionWriteBackBlocks	Blocks used for cache area

З визначенням типів:

uint8 tApFS_Uuid; uint64 tApFS_Ident; uint64 tApFS_Transaction; int64 tApFS_Address; uint64 tApFS_BTreeKey;

struct tApFS_BlockRange { tApFS_Address First; // First block uint64 Count; // Number of blocks } struct tApFS_COH { uint64 CheckSum; // Block checksum tApFS_Ident Ident; // Identifier tApFS_Transaction Transaction; // Object change transaction number uint16 Type; // Object type uint16 Flags; // Object flags uint32 SubType; // Object subtype };

з переліком типів об'єктів:

enum eApFS_ObjectType { eApFS_ObjectType_01_SuperBlock = 0x0001, //Container superblockа eApFS_ObjectType_02_BTreeRoot = 0x0002, // B-Tree: root node eApFS_ObjectType_03_BTreeNode = 0x0003, // B-Tree: non-root node eApFS_ObjectType_05_SpaceManager = 0x0005, // Space manager eApFS_ObjectType_06_SpaceManagerCAB = 0x0006, // Space manager: segments’ addresses eApFS_ObjectType_07_SpaceManagerCIB = 0x0007, // Space manager: segments’ information eApFS_ObjectType_08_SpaceManagerBitmap = 0x0008, // Free сspace bitmap used by Space manager eApFS_ObjectType_09_SpaceManagerFreeQueue = 0x0009, // Free space used by Space manager_ (keys - _tApFS_09_SpaceManagerFreeQueue_Key_, values - _tApFS_09_SpaceManagerFreeQueue_Value_) eApFS_ObjectType_0A_ExtentListTree = 0x000A, // Extents’ list tree (keys – offset beginning extent_tApFS_Address_, value – physical data location _tApFS_BlockRange_) eApFS_ObjectType_0B_ObjectsMap = 0x000B, // Type – Objects map; subType – Object map record tree (keys - _tApFS_0B_ObjectsMap_Key_, values - _tApFS_0B_ObjectsMap_Value_) eApFS_ObjectType_0C_CheckPointMap = 0x000C, // Check point map eApFS_ObjectType_0D_FileSystem = 0x000D, // Volume file system eApFS_ObjectType_0E_FileSystemTree = 0x000E, // File system tree (keys start from с _tApFS_BTreeKey_, describes key type and value) eApFS_ObjectType_0F_BlockReferenceTree = 0x000F, // Block reference tree (keys - _tApFS_BTreeKey_, values - _tApFS_0F_BlockReferenceTree_Value_) eApFS_ObjectType_10_SnapshotMetaTree = 0x0010, // Snapshot meta tree (keys - _tApFS_BTreeKey_, values - _tApFS_10_SnapshotMetaTree_Value_) eApFS_ObjectType_11_Reaper = 0x0011, // Reaper eApFS_ObjectType_12_ReaperList = 0x0012, // Reaper List eApFS_ObjectType_13_ObjectsMapSnapshot = 0x0013, // Objects map snapshot tree (keys - _tApFS_Transaction_, values - _tApFS_13_ObjectsMapSnapshot_Value_) eApFS_ObjectType_14_JumpStartEFI = 0x0014, // EFI Loader eApFS_ObjectType_15_FusionMiddleTree = 0x0015, // Fusion devices tree to track SSD cached HDD, blocks (keys - _tApFS_Address_, values - _tApFS_15_FusionMiddleTree_Value_) eApFS_ObjectType_16_FusionWriteBack = 0x0016, // Fusion devices writeback cache status eApFS_ObjectType_17_FusionWriteBackList = 0x0017, // Fusion devices writeback cache list eApFS_ObjectType_18_EncryptionState = 0x0018, // Encryption eApFS_ObjectType_19_GeneralBitmap = 0x0019, // General Bitmap eApFS_ObjectType_1A_GeneralBitmapTree = 0x001A, // General Bitmap Tree (keys - uint64, keys - uint64) eApFS_ObjectType_1B_GeneralBitmapBlock = 0x001B, // General Bitmap Block eApFS_ObjectType_00_Invalid = 0x0000, // Non-valid as a type or absent subtype eApFS_ObjectType_FF_Test = 0x00FF // Reserved for testing (never stored on media) eApFS_ObjectType_FF_Test = 0x00FF // Reserved for testing (never stored on media) }; enum eApFS_ObjectFlag { eApFS_ObjectFlag_Virtual = 0x0000, // Virtual object eApFS_ObjectFlag_Ephemeral = 0x8000, // Ephemeral object eApFS_ObjectFlag_Physical = 0x4000, // Physical object eApFS_ObjectFlag_NoHeader = 0x2000, // Object with no header _tApFS_ContainerObjectHeader_ (for example, Space (bitmap) manager bitmap) eApFS_ObjectFlag_Encrypted = 0x1000, // Encrypted object eApFS_ObjectFlag_NonPersistent = 0x0800, // Object with this flag is never saved on media eApFS_ObjectFlag_StorageTypeMask = 0xC000, // Bitmask (bitmask) for для accessing к object category flags eApFS_ObjectFlag_ValidMask = 0xF800 // Valid flag bit mask }; struct tApFS_0B_ObjectsMap_Key { tApFS_Ident ObjectIdent; // Object identifier tApFS_Transaction Transaction; // Transaction number }; struct tApFS_0B_ObjectsMap_Value { uint32 Flags; // Flags uint32 Size; // Object size in bytes (multiple of containerру block size) tApFS_Address Address; // Object address }; struct tApFS_09_SpaceManagerFreeQueue_Key { tApFS_Transaction sfqk_xid; tApFS_Address sfqk_paddr; }; struct tApFS_09_SpaceManagerFreeQueue_Value { uint64 sfq_count; tApFS_Ident sfq_tree_oid; tApFS_Transaction sfq_oldest_xid; uint16 sfq_tree_node_limit; uint16 sfq_pad16; uint32 sfq_pad32; uint64 sfq_reserved; }; struct tApFS_10_SnapshotMetaTree_Value { tApFS_Ident ExtentRefIdent; // Identifier of B-Tree physical object, that stores the extent information tApFS_Ident SuperBlockIdent; // Superblock identifier uint64 CreatedTime; // Snapshot creation time (in nanoseconds from midnight 01/01/1970) uint64 LastModifiedTime; // Snapshot last modified time (in nanoseconds from midnight 01/01/1970) uint64 iNum; uint32 ExtentRefTreeType; // Type of B-tree, that stores extent information uint16 NameLength; // Snapshot name length (including end of line character) uint8 Name[]; // Snapshot name (ending with 0) }; struct tApFS_13_ObjectsMapSnapshot_Value { uint32 Flags; // Snapshot flags uint32 Padding; // Reserved (for adjustment) tApFS_Ident Reserved; // Reserved }; struct tApFS_15_FusionMiddleTree_Value { tApFS_Address fmv_lba; uint32 fmv_length; uint32 fmv_flags; };

Приклад структури файлової системи ApFS:

Volume Superblock (Суперблок тома)

Суперблок тома (Volume Superblock) - існує для кожного тому файлової системи. Він містить назву тому, ідентифікатор та позначку часу. Подібно суперблоку контейнера (Container Superblock), він містить покажчик на карту блоків, який відображає ідентифікатори блоків усунення. Крім того, в суперблоці тома зберігається покажчик на кореневий каталог, який зберігається як вузол.

Offset (HEX)	Type	Id	Description
0	tApFS_COH	Header	Container Object Header
20	uint32	MagicNumber (APSB)	A value that can be used to verify reading an instance of Volume Superblock
24	uint32	IndexInSuperBlock	Object identifier index of this volume in the container volume array
28	uint64	Features	Bitmap of the main features used by the volume
30	uint64	ReadOnlyFeatures	Bitmap of the main features (read only) used by the volume
38	uint64	IncompatibleFeatures	Bitmap of incompatible volume features
40	uint64	LastUnmountTime	Time of the last volume dismount (in nanoseconds from midnight of 01/01/1970)
48	uint64	ReservedBlocksCount	The number of blocks reserved to allocate the volume
50	uint64	QuotaBlocksCount	The maximum number of blocks this volume can allocate
58	uint64	AllocatedCount	The number of blocks currently allocated to the file system of this volume
60	uint8	MetaCryptoState[20]	Information about the key used to encrypt metadata for this volume (wrapped_meta_crypto_state_t instance)
74	uint32	RootTreeType	Type of the root folder tree (typically: type of (eApFS_ObjectFlag_Virtual << 16) \ eApFS_ObjectType_02_BTreeRoot, subtype of eApFS_ObjectType_0E_FileSystemTree)
78	uint32	ExtentRefTreeType	Type of extent binding tree (typically: type of (eApFS_ObjectFlag_Physical << 16) \ eApFS_ObjectType_02_BTreeRoot, subtype of OBJECT_TYPE_BLOCKREF)
7C	uint32	SnapshotMetaTreeType	Snapshot metadata tree type (typically: type of (eApFS_ObjectFlag_Physical << 16) \ eApFS_ObjectType_02_BTreeRoot, subtype of OBJECT_TYPE_BLOCKREF)
80	tApFS_Ident	ObjectsMapIdent	Identifier of the physical object of the volume object map
88	tApFS_Ident	RootTreeIdent	Identifier of the virtual object of the root folder tree
90	tApFS_Ident	ExtentRefTreeIdent	Identifier of the physical object of the extent link tree
98	tApFS_Ident	SnapshotMetaTreeIdent	Identifier of the snapshot metadata tree virtual object
A0	tApFS_Transaction	RevertToXid	Transaction number of the snapshot to which the volume will be returned
A8	tApFS_Ident	RevertToSuperBlock	Identifier of the physical object of the VS to which the volume will return
B0	uint64	NextObjectIdent	The next identifier to be assigned to the file system object in the volume.
8	uint64	NumberOfFiles	The number of regular files in the volume
C0	uint64	NumberOfDirectories	The number of folders in the volume
C8	uint64	NumberOfSymbolicLinks	Number of symbolic links in the volume
D0	uint64	NumberOfOtherObjects	Number of other objects in the volume (not including x0B8_NumberOfFiles, x0C0_NumberOfDirectories and x0C8_NumberOfSymbolicLinks)
D8	uint64	NumberOfSnapshots	Number of snapshots in this volume
E0	uint64	TotalBlocksAllocated	Total number of blocks allocated by this volume
E8	uint64	TotalBlocksFreed	Total number of blocks freed by this volume
F0	tApFS_Uuid	Uuid
100	uint64	LastModifiedTime	Time of the last change of this volume (in nanoseconds from midnight 01/01/1970)
108	uint64	Flags
110	tApFS_0D_FSM	FormattedBy	Information about the software that created this volume
140	tApFS_0D_FSM	ModifiedBy[8]	Information about the software that changed this volume
2C0	uint8	VolumeName[256]	UTF-8 String Zero Volume Name
3C0	uint32	NextDocumentIdent	Next identifier of the document to be assigned (stored in the extended field APFS_0E_TYPE_DOCUMENT_ID of the document)
3C4	uint16	Role	Volume Role Bitmap
3C6	uint16	Reserved
3C8	tApFS_Transaction	RootToXid	Snapshot transaction number for non-root or zero for root
3D0	tApFS_Ident	EncryptStateIdent	Current state of encryption or decryption, or zero if no encryption

Детальна ілюстрація «APFS»:

Checkpoint (Чекпоінт)

Чекпоінт - це тимчасовий стан контейнера. Кожна контрольна точка ініціалізується в суперблоці контейнера, і поточний стан зазвичай є останнім. Чекпоінт включає метадані як контейнера, так і тома. Точки відновлення та знімки схожі один на одного. Основна відмінність між чекпоінтами та моментальним знімком полягає в можливості користувача відновити файлову систему зі збережених моментальних знімків за допомогою API файлової системи.

Checkpoint Superblock Descriptor (Дескриптор чекпоінта суперблока)

Цей блок містить інформацію про структуру метаданих в «ApFS» і є попереднім блоком дескрипторів. Найбільш важливою інформацією в цьому блоці є розташування Bitmap Structure (BMS), колишнього файлу розподілу в HFS+.

Дескриптор суперблоку контрольної точки:

Bitmap Structures (Бітова карта або карта тома)

Записи про використані та невикористані блоки. Існує тільки одна карта тома, яка покриває весь контейнер і є спільною для всіх томів файлової системі. «ApFS» використовує набір блоків для зберігання Карти тома (Bitmap Structures).

В «ApFS» карта є загальною для всіх томів в контейнері. У кожному томі вказані котирування блоку в контейнері, але самі блоки не перебувають в виділених областях. Посилання на карту тома лежить в дескрипторі чекпоінта суперблоку (CSBD), в якому знаходитися інформація про самий верхній рівень структури, дескриптори бітової карти (BMD). На малюнку нижче показана базова структура цієї карти. Вона розбита по рівнях, де BMD знаходитися зверху та встановлює межі. Внизу лежать «Bitmap Blocks» (BMB), які відстежують блоки в контейнері. Один байт в BMB відстежує вісім блоків, кожен біт яких забезпечує статус розподілу. Кожен біт - це статус окремого блоку.

Таблиці (Tables)

Таблиці використовуються в каталозі та екстентах B-дерева, списку томів та карті ідентифікатора об'єкта.

Поле типу таблиці складається з 2 байтів, розташованих в блоці зі зміщенням 0x20 безпосередньо після заголовка вузла. Існує вісім таблиць від 0 до 7. Наступні 2 байта забезпечують рівень таблиці від 0 і вище. У таблиці другого рівня будуть записи, які стосуються базової таблиці першого рівня. А таблиці нульового рівня відносяться до блоків, які часто містять метадані файлів.

Типи таблиць розрізняються за структурою, але заголовок таблиці для всіх типів має 24-байтовий вид.

На малюнку представлений зразок структури заголовка таблиці:

Опис значень полів в структурі заголовка:

Offset (HEX)	Field	Data type	Description
20	tableType	uint16	Possible values 0-7. It’s a table type 1
22	tableLevel	uint16	Indicates a level of a B-Tree.
24	tableRecords	uint16	Number of records in the table
26	Unknown 1	uint16
28	Unknown 2	uint16
2A	tableIndexSize	uint16	Size of the table index area.
2C	tableKeyAreaSize	uint16	Size of the table key area.
2E	tableFreeSpaceSize	uint16	Size of the free area. The table data area ends at offset 0x38+tableIndexSize+tableKeyAreaSize+tableFreeSpaceSize. 0x38 + 0x80 + 0x170 + 0xd58.
30	Unknown 3	uint16
32	Unknown 4	uint16
34	Unknown 5	uint16
36	Unknown 6	uint16

Тут показаний загальний макет різних таблиць:

Не всі елементи на зображенні використовуються в усіх таблицях. На малюнку показаний повний блок з заголовком блоку верхнього вузла. Інша частина блоку складає таблицю.

Відразу після заголовка таблиці йде індекс запису. Їх є 2 типи. Один з двома значеннями: зміщенням в ключах та зміщенням в розділі даних, для кожного з Uint16. Другий використовує 4 значення Uint16 зі зміщенням і довжиною як для ключа, так і для розділів даних. Індекс запису таблиці містить інформацію про ключі та записи даних в таблиці. Ще одна відмінність між типами таблиць - це використання нижніх колонтитулів.

У таблицях 1, 3, 5 і 7, в кінці блоку використовується нижній колонтитул розміром 0x28 байтів. У цих таблицях все зміщення даних відносяться до зміщення 0xFD8, а нижній колонтитул містить різні значення, специфічні для типу таблиці. Інші типи таблиць не мають нижнього колонтитула, і всі посилання на вміст розділу даних відносяться до кінця блоку.

У B-деревах з кількома рівнями, таблиці 1, 3, 5 та 7 знаходяться на самому верхньому рівні, оскільки вони мають нижній колонтитул. Нижній колонтитул використовується для зберігання інформації про повне B-дерево. Одне зі значень в нижньому колонтитулі - це загальна кількість записів в структурі цього дерева.

Визначення таблиці починається зі зсуву 0x20 в блоці. Тут вказано тип таблиці, кількість рядків, розмір ключового розділу та проміжок між ключем і розділом даних. Після властивостей таблиці, визначення рядків і стовпців описуються зміщення 0x38. Таблиця містить заголовок, визначення записів, розділи ключів і даних. У деяких типів таблиць також є нижній колонтитул. Тема починається зі зсуву 0x20 і має довжину 0x18 байт. Тема цього типу таблиці починається з 16-бітового значення, яке представляє тип таблиці. За нею йдуть два байти, які представляють рівень в B-дереві, на якому використовується таблиця. Два наступних байта представляють кількість рядків в таблиці. Довжина запису визначення сканування знаходиться в 0x2A, за яким йде Uint16, який записує довжину ключового розділу. Далі, йде розрив між ключем та розділом даних. Нижній колонтитул таблиці завжди дорівнює 0x28 байтам і завжди займає кінець блоку. А індекси таблиці мають 4 або 8 байтів кожний. На 8-байтових індексах, два перших «Uint16» - це зміщення і довжина ключового запису. Наступні два «Uint16» - це зміщення і довжина запису даних в таблиці. Таблиці з 4-байтовими індексами мають два значення Uint16, які містять зміщення ключа та записів даних. Довжина даних у двох записах визначена. У таблицях з нижнього колонтитула зміщення запису даних щодо початку нижнього колонтитула - (0x28 байт). А для інших типів таблиць це зміщення відноситься до кінця блоку.

Більшість значень, що стосуються заголовка і нижнього колонтитула таблиці, зрозумілі для читання типу таблиці. Зсув 0x18 в нижньому колонтитулі (зміщення 0xFF в блоці 4 Кб) - це кількість записів в таблиці в усих базових таблицях (якщо це таблиця з рівнем вище 0, по зсуву 0x22). Зсув 0x20 в нижньому колонтитулі - це номер наступного запису в таблиці.

Таблиця 0

Таблиця 0 типу лежить в структурі каталогу B-дерева між вузлами листя і кореневим вузлом. Значення Невідомо (Unknown) з 3 по 6 представлені у вигляді зсуву і довжини ключа. Зміщення даних і довжини наступного доступного запису. Якщо вільних індексних записів немає, то зміщення встановлюються на «0xFFFF» та довжину «0x00».

Записи в таблиці представляють собою чотири значення «Uint16». Перші 2 - це зміщення та довжина значення в ключовому розділі, а наступні - це зміщення та значення вмісту в розділі даних.

Прикладом таблиці 0 типу може бути ідентифікатор вузла каталогу, іменний ключ в розділі ключів та ідентифікатором об'єкта в розділі даних. У цій таблиці немає нижнього колонтитула.

Таблиця 1

Перша таблиця має нижній колонтитул, а індекс таблиці містить чотири 16-бітних значень, де перші 2 значення представляють собою зсув запису в ключовому розділі, та довжину запису. Наступні 2 значення забезпечують зсув запису в розділі даних, та її довжину. Ця таблиця часто зустрічається як в структурі каталогу B-дерева, так і в дереві екстентів для вузла верхнього рівня. Прикладом є значення: «Parent ID» та ім'я ключа (ім'я файлу або папки в структурі каталогу, і початковий номер блоку в B-дереві екстентів), ідентифікатор об'єкта при використанні в якості кореневого вузла в структурі каталогу, або номер блоку, коли використовується в дереві екстентів.

Приклади цієї таблиці наведені нижче:

Таблиця 2

Друга таблиця. Спочатку ця таблиця ідентична з попередньою, але вона не має нижнього колонтитула. Цей тип таблиці дуже часто зустрічається в кінцевих вузлах структури каталогу B-дерева, де ключовий розділ представлений з «Parent ID» та ім'ям ключа.

Таблиця 3

Третя таблиця ідентична попередній. Індекс таблиці такий же, як у першій таблиці. Типові значення залежать від структури в якій вони використовуються. У структурі каталогу B-дерева та дереві екстентів, ця таблиця часто використовується як вузол верхнього рівня в невеликих обсягах, де кореневим вузлом одночасно є кореневий та листовий вузол. В такому прикладі використання, ключовий записом може бути «Parent ID». Іменний ключ та запис даних можуть бути файлом метаданих з великим варіюванням розміру.

Інші записи таблиці - це ідентифікатор об'єкта «Object ID» і його тип в ключового запису, з екстенти інформації про файли та записи даних. Третя таблиця має нижній колонтитул.

Приклад таблиці:

Таблиця 4

Четверта таблиця дещо відрізняється від попередніх. У таблиці немає нижнього колонтитула, а індекс таблиці має тільки 2 значення: зсув запису в ключовому розділі та значення для розділу даних. Довжина вмісту фіксована і складає 16 байтів в ключовому розділі, та 8 байт в розділі даних. Зміщення в розділі даних відносяться до кінця блоку.

Таблиця 5

П'ята таблиця схожа на четверту. Єдина відмінність полягає в тому, що у цього типу є нижній колонтитул, а всі зсуви даних починаються з «offset-0x28» (початок нижнього колонтитула). Записи в ключовому розділі становлять 16 байтів та 8 байт, в розділі даних. Цей тип таблиці найчастіше спостерігається на вузлах верхнього рівня, в структурі каталогу B-дерева та в великих контейнерах з багаторівневими деревами.

Таблиця 6

Шоста таблиця також схожа на четверту. Індекс таблиці має тільки зміщення до вмісту в розділі ключів та даних, але не її довжину. Довжина визначена заздалегідь. Кожен запис становить 16 байтів. Для цього типу таблиці немає нижнього колонтитула. Ця таблиця часто зустрічається в кінцевих вузлах структури каталогу B-дерева. Типовий вміст розділу ключа включає в себе ідентифікатор об'єкта та ID «Volume Checkpoint Superblock ID», в той час як в розділенні даних зазвичай записується їх розмір та номер блоку.

Таблиця 7

Таблиця 7 схожа на 6. Єдиною відмінністю є нижній колонтитул, який містить інформацію, аналогічну описаній Таблиці 1. Цей тип таблиці спостерігається в широкому діапазоні структур і часто зустрічається на самих верхніх рівнях багатошарової структури, або в одношарових структурах, таких як опис тома.

Наприклад,

Зведення таблиць

В даній таблиці показані основні властивості різних типів таблиць:

Type	Footer	Key section offset	Key section length	Data section offset	Data section length	Key length	Data length
0	NO	uint16	uint16	uint16	uint16	Varies	Possible
1	YES	uint16	uint16	uint16	uint16	Varies	Possible
2	NO	uint16	uint16	uint16	uint16	Varies	Possible
3	YES	uint16	uint16	uint16	uint16	Varies	Possible
4	NO	uint16		uint16		16 bytes	8 bytes
5	YES	uint16		uint16		16 bytes	8 bytes
6	NO	uint16		uint16		16 bytes	16 bytes
7	YES	uint16		uint16		16 bytes	16 bytes

Одним з найбільш важливих блоків в структурі каталогу B-дерева є кореневий вузол, який є найвищим рівнем в структурі папок. Цей вузол використовує ключі пошуку змінної довжини. Однією з поліпшених функцій «ApFS» є швидкий пошук в каталогах. Одне зі значень, яке тісно пов'язане з цією функцією, це кількість всіх записів в структурі дерева, розташованої в нижньому колонтитулі таблиці.

У кореневого вузла структури B-дерева є 2 варіанти вибору таблиці, оскільки в обох є кінцеві рядки. Таблиця 3, як кореневий вузол, спостерігається тільки в невеликих контейнерах з невеликою кількістю файлів, де кореневий вузол також є індексним та листовим вузлами.

У карті об'єктів для кореневого вузла використовується тільки Таблиця 5, за винятком дуже маленьких структур, де може зустрічатися Таблиця 7.

Інтерпретація таблиць показує, що таблиці 0 та 2 мають однакові значення. Те ж саме спостерігається між таблицями 1 та 3. Ці таблиці мають різне призначення залежно від того, в якій структурі вони знаходяться.

Знімки (Snapshots)

Снепшоти (Snapshots) - це знімки файлової системи тома, тільки для читання. Операційна система може використовувати ці знімки для більш ефективної процедури резервного копіювання. Завдяки ним Time Machine буде працювати швидше. І завдяки підтримці миттєвих образів «Time Machine», більше не потрібно зберігати декілька повних копій файлу на диск - вона може просто відстежувати певні зміни. Наприклад, якщо ви редагуєте файл, зміна з використанням HFS+, він зберігає дві копії файлу: в першому записані нові зміни, а другий, на випадок якщо ви захочете повернутися до попереднього стану. У «APFS» зберігається тільки вихідний файл та записуються відмінності між вихідним файлом та будь-якими оновленими версіями, займаючи менше місця на диску. Як і у випадку з поліпшеннями в Fusion Drive, інформація займає менше місця на диску.

Хоча «ApFS» і значно поступається за своїми можливостями 128-бітній ZFS, яка підтримується Linux, FreeBSD та іншими безкоштовними ОС, але з боку Apple це крок у правильному напрямку.

Як згадувалося вище, Apple довгий час намагалася перенести ZFS на OS X. Пізніше OpenZFS був реалізований для OS X та MacZFX.

Nodes (вузли)

Вузли - це гнучкі контейнери, які використовуються для зберігання різних видів записів. Вони можуть бути частиною B-дерева або існувати самі по собі. Вузли можуть містити записи гнучкого або фіксованого розміру. Вузол починається зі списку покажчиків на ключі входу та запису входу. Таким чином, для кожного запису вузол містить заголовок запису на початку вузла, ключ входу в середині вузла і запис входу в кінці вузла.

position	size	type	ID
0	4	uint32	alignment
4	4	uint32	ENTRY_COUNT
10	2	uint16	HEAD_SIZE
16	8	entry	meta_entry
24	...	entry	entries (repeat entry_count times)

Структура заголовка вузла (Node header):

Offset	field	Data type	Comments
0	Checksum	Uint64	Fletchers Checksum Algorithm
8	ID	Uint64	Object-ID or Block#
10	Checkpoint	Uint64
18	Unknown	Uint16	Possible level in B-Tree
1A	Unknown	Uint16	All observations show value 0x4000
1C	Unknown	Uint16	Flag?
1E	Unknown	Uint16	Often seen value 0x0b, 0x0e and 0x0f

Менеджер простору (Space Manager)

«Space Manager» (Менеджер простору) використовується для управління виділеними блоками в контейнері «ApFS». Зберігає кількість вільних блоків та покажчик на файли інформації про розміщення.

position	size	type	ID
0	4	uint32	block size
16	8	uint64	totalblocks
40	8	uint64	freeblocks
144	8	uint64	prev_allocationinfofile_block
352	8	uint64	allocationinfofile_block

Allocation info file (Інформаційний файл розподілу)

Файл розподілу працює як відсутній заголовок. Тут зберігаються довжина файлів розміщення, версія і його зміщення.

position	size	type	ID
4	4	uint32	alloc_file_length
8	4	uint32	alloc_file_version
24	4	uint32	TOTAL_BLOCKS
28	4	uint32	free_blocks
32	4	uint32	allocationfile_block

Файл та папка B-дерева

Записи всіх файлів і папок на томі. Вони виконують ту ж роль, що і файли каталогу в «HFS+».

Extents (Екстенти B-дерева)

Окреме B-дерево всіх екстентів тома. Екстенти - це посилання на вміст файлу з інформацією про те, де починається вміст даних, і про їх довжину в блоках. Файл з деяким вмістом матиме як мінімум один екстент. А фрагментований файл буде мати декілька екстентів. Дерево екстентів - це окрема структура.

У кожного запису файлу, екстенти визначаються для кожного з цих файлів в B-дереві. Ця окрема структура екстентів є частиною функції миттєвого знімка.

64-bit inodes (index descriptors) - індексні дескриптори

64-бітові inodes значно збільшують простір імен в порівнянні з 32-бітними ідентифікаторами в «HFS+». 64-розрядна файлова система «ApFS» підтримує понад 9 квінтильйонів файлів на кожному томі. Як сказав Білл Гейтс, цього має вистачити на всіх.

«ApFS» пропонує можливість відновлення певних станів файлової системи, включаючи старі або видалені версії файлів. Суперблок контейнера містить посилання на структуру контрольної точки. Контрольна точка посилається на попередній суперблок контейнера, який містить інформацію в більш старому стані файлової системи. Таким чином, можна відновити декілька старих станів шляхом аналізу ланцюжка суперблоку контейнера.