Btrfs-мониторинг: когда заканчивается место на сабволюме
df -h на btrfs показывает картину, которая не совпадает с реальностью: суммарный размер подмонтированных точек, а не фактическое занятое место. Когда на системе со снапшотами «заканчивается место», первым делом нужно понять, что именно кончилось, данные, метаданные или лимит снапшотов. Разберём, как читать btrfs-статистику, кто съедает место и что делать, когда система пишет ENOSPC.
Почему df -h на btrfs врёт
df считает по точкам монтирования. Каждый подтом btrfs, смонтированный отдельно: @, @home, @snapshots: выглядит как самостоятельный раздел со своим размером. Но физически все они живут в одном пуле, и df показывает для каждой точки один и тот же объём целиком. Сумма строк в выводе может в разы превышать реальный размер диска, а занятость каждой точки это не «сколько занимает подтом», а «сколько занято во всей файловой системе».
Плюс btrfs умеет сжимать данные и делиться экстентами между подтомами и снапшотами. Один и тот же блок может быть виден из десяти снапшотов, но занимать место один раз. df про это ничего не знает: он складывает видимые размеры, а не уникальные.
Поэтому первое правило мониторинга: df -h годится для грубой оценки «диск вообще полный или нет», а для ответа «сколько реально занято и кем» нужны инструменты btrfs.
Как посмотреть реальную картину: btrfs filesystem
Три команды закрывают три вопроса: сколько выделено, сколько занято и на каком устройстве всё живёт.
btrfs filesystem df /: распределение по типам:
btrfs filesystem df /
Вывод показывает три строки: Data, Metadata, System с двумя числами в каждой: total (сколько места выделено под этот тип) и used (сколько реально занято). Разница между ними: запас, который btrfs держит под будущие записи. Если used по Data приближается к total, файловая система начнёт выделять новые блоки, и тут может упереться в нехватку места.
btrfs filesystem usage /: полный отчёт:
btrfs filesystem usage /
Здесь уже видно устройство, общий размер, занятое и свободное место, а также разбивка по типам с процентами. Это главная команда для еженедельной проверки: один взгляд, и понятно, сколько осталось и куда уходит.
btrfs filesystem show /: сводка по устройству:
btrfs filesystem show /
Показывает UUID, размер устройства и общее занятое место. Полезна, когда на машине несколько дисков и нужно понять, на каком из них живёт корень.
Кто съедает место: снапшоты, кэш pacman, журналы
На системе со снапшотами три главных пожирателя места.
Снапшоты. Каждый снапшот сам по себе почти ничего не весит, он ссылается на существующие данные. Место растёт, когда файлы меняются: старые версии остаются в снапшотах, новые занимают новые блоки. Чем больше обновлений и изменений, тем быстрее растёт разница между «местом в подтоме» и «местом на диске».
Посмотреть список снапшотов:
btrfs subvolume list -s /
А сколько реально занимает каждый подтом через btrfs filesystem du:
btrfs filesystem du / --exclude /proc --exclude /sys
du покажет размер каждого подтома с учётом общих экстентов. Для снапшотов snapper удобнее его же инструмент:
snapper list
Здесь видно даты и типы снапшотов по ним легко понять, какие точки можно удалить без сожаления.
Кэш pacman. Пакеты после установки остаются в /var/cache/pacman/pkg и копятся годами. На btrfs это двойная проблема: кэш лежит в подтоме @, и его рост раздувает разницу между снапшотами. Чистка разобрана в статье про paccache, а здесь запомни главное: paccache -rk2 оставляет две последние версии каждого пакета и освобождает гигабайты.
Журналы. journalctl по умолчанию ограничен размером, но на десктопе с частыми обновлениями журнал легко разрастается. Проверить:
journalctl --disk-usage
Если журнал съел больше пары сотен мегабайт, journalctl --vacuum-size=200M вернёт его к разумным размерам.
Чем «место на диске» отличается от «места в подтоме»
Ключевое отличие btrfs от классических файловых систем: снапшот при создании не копирует данные. Он фиксирует состояние подтома, а сами блоки остаются общими. Место начинает расти только при изменении файлов: старые версии остаются «жить» в снапшотах.
Отсюда два следствия.
Первое: df -h / может показывать почти полный диск, даже если в самом подтоме @ файлов немного. Всё занятое место это исторические версии файлов, которые держат снапшоты. Удалил снапшоты: место вернулось, хотя в подтоме ничего не менялось.
Второе: «нет места» наступает не тогда, когда «заполнился подтом», а когда заполнился весь пул. btrfs не умеет сказать «подтом переполнен», он упирается в общий объём устройства. Поэтому на системе со снапшотами следить нужно за btrfs filesystem usage /, а не за df по конкретной точке.
Признаки нехватки места и что делать
Главный симптом: ошибка No space left on device (ENOSPC). На btrfs она коварная: может появиться при свободных данных, если кончились метаданные. Metadata это структуры, описывающие файлы и экстенты; при большом количестве мелких файлов и снапшотов они растут быстрее данных. btrfs filesystem df / покажет: Data ещё свободна, а Metadata упёрлась в потолок.
Второй признак: ошибки в чистке снапшотов. snapper cleanup падает с ENOSPC, когда не может записать изменения в метаданные. При этом снапшоты продолжают копиться, и ситуация ухудшается.
Что делать, по порядку:
- Удалить лишние снапшоты:
sudo snapper -c root delete 1..5
Сначала snapper list, чтобы не удалить свежие точки. Освободившиеся блоки btrfs вернёт не сразу, но место для метаданных появится.
- Почистить кэш pacman:
sudo paccache -rk2
- Сбалансировать файловую систему:
sudo btrfs balance start -dusage=50 /
Балансировка перераспределяет блоки и возвращает пустые экстенты в пул. -dusage=50 трогает только блоки данных, заполненные меньше чем наполовину это безопасно и быстро. Если не помогло, попробуй -dusage=70, потом -musage=50 для метаданных. Полная балансировка без фильтров на большом диске может занять часы не запускай её без необходимости.
После балансировки снова btrfs filesystem usage /: картина должна измениться в сторону свободного места.
Профилактика: лимиты, мониторинг, привычка
Три привычки, которые не дают месту закончиться.
Лимиты snapper. В /etc/snapper/configs/root стоят TIMELINE_LIMIT_*: сколько снапшотов каждого уровня хранить. Если место уходит быстро, уменьши лимиты: например, TIMELINE_LIMIT_HOURLY="3" вместо 5. Настройка подсистемы разобрана в гайде про снапшоты с первого дня, здесь важно одно: лимиты это и есть главный предохранитель.
Мониторинг. Щедро на алерты: лучше получить лишнее предупреждение, чем однажды не загрузиться. Простой вариант: cron-задача, которая раз в день гоняет btrfs filesystem usage / и пишет в лог, или скрипт, который шлёт уведомление, когда занято больше 85%. Порог выбирай с запасом: на btrfs последние проценты уходят быстро, потому что снапшоты продолжают расти даже при «почти полном» диске.
Привычка. Раз в неделю, btrfs filesystem usage / и взгляд на snapper list. Пять секунд, которые показывают тренд: если занятое место растёт быстрее, чем обычно, значит, что-то изменилось, новые лимиты, разросшийся журнал или кэш. Поймал на ранней стадии: починил за минуту.
Частые вопросы
Почему df показывает больше, чем размер диска?
Потому что df суммирует подмонтированные точки, а подтомы btrfs делят один пул. Каждая точка показывает весь объём файловой системы, и сумма строк превышает реальный размер. Для реальной картины используй btrfs filesystem usage /.
Что делать, если ENOSPC при свободном месте в df?
Скорее всего, кончились метаданные. Проверь btrfs filesystem df /: если Metadata used близко к total, удали лишние снапшоты и запусти btrfs balance start -musage=50 /.
Снапшотов мало, а место кончилось. Как так?
Место занимают не сами снапшоты, а разница между текущим состоянием и историей. Если файлы активно менялись, старые версии лежат в снапшотах и держат место. Плюс кэш pacman и журналы, проверь их в первую очередь.
Как часто делать балансировку?
Только по необходимости. Если btrfs filesystem usage / показывает большой разрыв между total и used по Data, балансировка вернёт место. Регулярная балансировка без причины только нагружает диск.
Полезные ресурсы
- Снапшоты btrfs с первого дня: настройка подсистемы, лимиты, чистка
- Снапшоты и откат: стратегия GRUB + btrfs: загрузка в точки отката
- Чистка кэша пакетов: paccache: освобождение места в /var/cache/pacman
- Btrfs: ArchWiki: подтома, снапшоты, балансировка
- Snapper: ArchWiki: конфигурации, лимиты, чистка
Заключение
Мониторинг места на btrfs: это три команды (btrfs filesystem df, usage, show), понимание, что снапшоты едят место только при изменении файлов, и привычка смотреть на тренд раз в неделю. df -h оставь для грубой оценки, а решения принимай по выводу btrfs. ENOSPC на такой системе почти всегда лечится чисткой снапшотов и балансировкой: главное, заметить проблему до того, как она превратится в невозможность записать обновление.
Не получилось? Поможем настроить
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии