Открываешь "Об этом Mac -> Хранилище", видишь 200 ГБ свободно. Запускаешь установку обновления на 14 ГБ - и получаешь "недостаточно места". Или копируешь 8-гиговый видеофайл, а место на диске не уменьшается ни на байт. Или удаляешь 50 ГБ хлама, а Finder упрямо показывает "очищаемое" место и реально его не отдаёт. Если ты до сих пор думаешь о диске Mac как о наборе фиксированных разделов с папками - ты будешь биться головой об стену.
Всё это - не баги. Это нормальное поведение APFS, файловой системы mac, которая работает по другим правилам, чем привычный HFS+ или ext4. APFS (Apple File System) появилась в High Sierra (2017) и с тех пор - стандарт для всех Mac, включая Apple Silicon на macOS 26 Tahoe. Чтобы перестать гадать "куда делось место" и начать осознанно управлять томами, снапшотами и шифрованием, нужно понять механику. Разберём её до винтика: контейнеры и тома (space sharing), снапшоты (copy-on-write), клоны файлов, нативное шифрование FileVault и инструмент diskutil apfs.
Контейнеры и тома: место общее, а не нарезанное
Главный сдвиг в голове. В старом мире у тебя был раздел (partition) фиксированного размера: отрезал 100 ГБ под систему - значит 100 ГБ, ни байтом больше. В APFS появился промежуточный слой - контейнер (APFS Container). Физический диск делится на один или несколько контейнеров (в терминах GPT это по-прежнему разделы, тип Apple_APFS). А вот внутри контейнера живут тома (Volumes), и вот они-то размер не фиксируют - они делят общий пул свободного места контейнера. Это и называется space sharing.
Посмотрим вживую. Команда diskutil apfs list показывает иерархию контейнеров и томов:
Код: Выделить всё
$ diskutil apfs list
+-- Container disk3 ABCDEF01-2345-6789-ABCD-EF0123456789
| ====================================================
| APFS Container Reference: disk3
| Size (Capacity Ceiling): 494384795648 B (494.4 GB)
| Capacity In Use By Volumes: 213045821440 B (213.0 GB) (43.1% used)
| Capacity Not Allocated: 281338974208 B (281.3 GB) (56.9% free)
|
+-> Volume disk3s1 11111111-... (Macintosh HD, System, Sealed)
+-> Volume disk3s2 22222222-... (Preboot)
+-> Volume disk3s3 33333333-... (Recovery)
+-> Volume disk3s5 44444444-... (Macintosh HD - Data, Data)
+-> Volume disk3s6 55555555-... (VM)
Обрати внимание на пять системных томов - это группа томов (Volume Group), которую macOS создаёт для загрузочного диска начиная с Catalina. Каждый том несёт роль (role), хранящуюся прямо в суперблоке тома:
- System - системный том, read-only, с macOS 11 он ещё и Sealed (запечатан): загрузка идёт не с самого тома, а с его подписанного снапшота (SSV, Signed System Volume). Подменить системный файл незаметно нельзя - криптографическое дерево хэшей не сойдётся.
- Data - всё изменяемое: домашние папки, программы, документы. Связан с System в одну группу через firmlinks, поэтому ты видишь единый "Macintosh HD".
- Preboot - незашифрованный, данные для старта каждого системного тома (в том числе для разблокировки FileVault).
- Recovery - незашифрованный recoveryOS, доступен без разблокировки системы.
- VM - незашифрованный, под файлы подкачки (swap).
Снапшоты: машина времени внутри файловой системы
Теперь к самому интересному. APFS - файловая система с copy-on-write (CoW): при изменении блока данных она не перезаписывает его на месте, а пишет новую копию и переставляет указатель. Старый блок остаётся, пока на него кто-то ссылается. Из этого свойства бесплатно вырастает снапшот (apfs снапшот) - моментальный, read-only слепок состояния тома на конкретный момент.
Ключевое: снапшот создаётся мгновенно и поначалу не занимает места вообще. Он просто фиксирует набор указателей на блоки "как было". Дальше живая система меняется, старые блоки она уже не освобождает (на них держит ссылку снапшот) - и вот эта разница между "как было" и "как стало" и есть то место, что отъедает снапшот. Чем больше ты изменил с момента снапшота, тем он "тяжелее".
На снапшотах построены две критичные вещи: обновления macOS (перед апдейтом система делает снапшот, чтобы можно было откатиться) и Time Machine. Локальные снапшоты Time Machine лежат прямо на твоём диске - это они часто и есть тот самый "загадочный поглотитель места".
Смотрим снапшоты на смонтированном томе:
Код: Выделить всё
$ diskutil apfs listSnapshots /System/Volumes/Data
Snapshot for disk3s5 (1 found)
+-- AA11BB22-CC33-DD44-EE55-FF6677889900
Name: com.apple.TimeMachine.2026-06-15-091230.local
XID: 0x4F2A1
Purgeable: Yes
Код: Выделить всё
$ tmutil listlocalsnapshotdates /
Snapshot dates for volume group containing disk /:
2026-06-15-091230
2026-06-15-141502
Вот разгадка истории из вступления. Когда ты удаляешь 50 ГБ, но эти файлы попали в локальный снапшот - физически блоки не освобождаются, потому что снапшот на них ссылается. Finder честно помечает это как "очищаемое" (purgeable) место: оно занято, но будет отдано под давлением. Поэтому "свободного" по факту меньше, чем кажется по человеческому подсчёту "файлов на N гигабайт".
Управлять этим можно руками. Утончить (thin) локальные снапшоты, освободив примерно нужный объём в байтах, с приоритетом срочности 4:
Код: Выделить всё
$ sudo tmutil thinlocalsnapshots / 21474836480 4
Thinned local snapshots:
2026-06-15-091230
Код: Выделить всё
$ sudo tmutil deletelocalsnapshots 2026-06-15-091230
Deleted local snapshot '2026-06-15-091230'
Код: Выделить всё
$ diskutil apfs deleteSnapshot /System/Volumes/Data -xid 0x4F2A1
Снапшот как инструмент отката - отдельная сила. Перед рискованной операцией (правка системных конфигов, эксперимент) можно снять снапшот командой tmutil snapshot, а если всё пошло не так - вернуться. Полноценный откат на снапшот тома выполняется через diskutil:
Код: Выделить всё
$ tmutil snapshot
Created local snapshot with date: 2026-06-15-153000
# ... что-то сломали ...
$ diskutil apfs revert /dev/disk3s5 -snapshotName com.apple.TimeMachine.2026-06-15-153000.local
Клоны файлов: копия за ноль байт
Второй подарок copy-on-write - клоны. Когда ты копируешь файл в пределах одного тома APFS через Finder или команду cp -c, система не дублирует данные. Она создаёт новую запись каталога, которая ссылается на те же блоки. Место занимает только метаданные - сами данные общие, пока ты не начнёшь править копию. Тогда правится только изменённый блок (опять CoW), остальное остаётся общим.
Код: Выделить всё
$ mkfile 1g big.dat
$ df -h .
Filesystem Size Used Avail ...
/dev/disk3s5 466Gi 213Gi 253Gi ...
$ cp -c big.dat big_clone.dat # -c просит APFS-клон
$ df -h .
Filesystem Size Used Avail ...
/dev/disk3s5 466Gi 213Gi 253Gi ... # Used почти не вырос
Нативное шифрование: FileVault поверх APFS
В HFS+ шифрование было надстройкой (CoreStorage). В APFS шифрование - встроенное свойство тома, нескольких уровней (без шифрования, одноключевое, многоключевое - где у файлов и метаданных свои ключи). На Apple Silicon оно опирается на Secure Enclave и аппаратный AES-движок, поэтому накладные расходы минимальны.
FileVault на современном Mac включает шифрование тома Data. Управлять им из терминала - fdesetup. Проверить статус:
Код: Выделить всё
$ fdesetup status
FileVault is On.
Код: Выделить всё
$ sudo fdesetup enable
Enter the user name: admin
Enter the password for user 'admin':
Recovery key = 'XXXX-XXXX-XXXX-XXXX-XXXX-XXXX'
Код: Выделить всё
$ sudo fdesetup list
admin,11111111-2222-3333-4444-555555555555
Создаём и удаляем том: diskutil apfs на практике
Самое полезное в space sharing - можно завести отдельный том под задачу (например, под другую версию системы, под чистую песочницу, под общий кэш), и он не отъест место навсегда, а будет делить пул. Добавляем том в существующий контейнер:
Код: Выделить всё
$ diskutil apfs addVolume disk3 APFS "Sandbox"
Started APFS operation on disk3
Preparing to add APFS Volume to APFS Container disk3
Creating APFS Volume
Mounting APFS Volume
Finished APFS operation on disk3
Код: Выделить всё
$ diskutil apfs addVolume disk3 APFS "Sandbox" -quota 50g -reserve 5g
Код: Выделить всё
$ diskutil apfs deleteVolume disk3s7
Started APFS operation on disk3s7
Deleting APFS Volume from its APFS Container
Removing any cryptographic users on the APFS Volume
Deleting APFS Volume
Finished APFS operation on disk3s7
Типичные грабли
- "Свободного места меньше, чем сумма размеров файлов". Виноваты снапшоты и purgeable. Считай место через df и Disk Utility, а не сложением размеров папок.
- du врёт на клонах и снапшотах. BSD-шный du (это macOS, не GNU) считает занятые блоки, и для клонов посчитает данные дважды, а для общих с другим томом блоков - покажет то, что введёт в заблуждение. Для реальной картины - df по тому и diskutil apfs list по контейнеру.
- "Удалил снапшоты, а место не вернулось сразу". Утончение асинхронно, и если на блоки ссылается ещё один снапшот - они не освободятся, пока жив последний из них.
- Откатываю снапшот на работающей системе - отказ. revert загрузочного Data делается из recoveryOS. На живом смонтированном томе - нет.
- Контейнер "не отдаёт место" другому контейнеру. Space sharing работает внутри одного контейнера, между разными контейнерами места не текут - там нужен diskutil apfs resizeContainer.
- cp без -c. Не каждое копирование - клон. Хочешь гарантированно клон в пределах тома - используй cp -c.
Нужен Mac на APFS (любой современный). Команды с sudo выполняй осознанно.
- 1. Посмотри иерархию: diskutil apfs list. Найди свой загрузочный контейнер, отметь Capacity In Use и Capacity Not Allocated.
- 2. Создай снапшот: tmutil snapshot. Затем tmutil listlocalsnapshotdates / - убедись, что он появился.
- 3. Загляни в детали: diskutil apfs listSnapshots /System/Volumes/Data. Отметь поле Purgeable.
- 4. Эксперимент с клоном: mkfile 1g ~/big.dat, запиши df -h ~ . Сделай cp -c ~/big.dat ~/big2.dat и снова df -h ~ - сравни Used. Удали оба файла.
- 5. Добавь свой том: diskutil apfs addVolume diskN APFS "Lab" (N - номер твоего контейнера из шага 1). Проверь, что он смонтировался, и удали: diskutil apfs deleteVolume diskNsM.
- 6. Проверь шифрование: fdesetup status. Если FileVault выключен, оцени, нужен ли он тебе (для ноутбука - почти всегда да).
- 7. Прибери снапшот теста: tmutil deletelocalsnapshots <дата из шага 2>.
- 1. Чем контейнер APFS отличается от тома и что такое space sharing? Почему "размер тома" в diskutil info обычно равен почти всему диску?
- 2. Почему свободного места часто меньше, чем кажется, и что такое purgeable? Какие две команды помогут вернуть место от снапшотов?
- 3. Как copy-on-write порождает одновременно и снапшоты, и клоны файлов? Почему клон не занимает места, пока ты не правишь копию?
- 4. На Apple Silicon диск зашифрован аппаратно всегда. Что тогда даёт FileVault и почему его всё равно стоит включать?
APFS - это не "папки на разделе", а пул свободного места (контейнер) с тонкими томами поверх него, плюс copy-on-write, из которого почти бесплатно растут снапшоты и клоны. Снапшоты - основа обновлений и Time Machine и причина "очищаемого" места; клоны - причина, по которой копия может ничего не весить; шифрование встроено в том и управляется fdesetup. Твой главный инструмент - diskutil apfs (list, listSnapshots, addVolume, deleteVolume, revert) плюс tmutil для снапшотов. Перестань считать место сложением папок - смотри контейнер целиком, и загадки исчезнут.
