Драйверы хранилища: overlay2, гранулярность copy-up и ловушка inode

Что такое драйвер хранилища и почему победил overlay2

Выбор драйвера хранилища — почти не-решение: overlay2 выбирается за тебя по умолчанию. Но когда дисковый инцидент падает на твой дежурный стол, понимание механизма — разница между одноминутной диагностикой и часом охоты за призраком. Драйвер хранилища — подсистема движка, реализующая слоистую ФС: как стекаются read-only слои образа, как материализуется записываемый слой и что делает copy-on-write при записи. Docker за годы поставлял несколько — aufs, devicemapper, btrfs, zfs, vfs — но ответ практически для любого современного Linux-хоста — overlay2, дефолт. Он построен на ядерном OverlayFS, не требует особой настройки блочного устройства, работает на ext4 и xfs (xfs нужен ftype=1) и единственный активно рекомендуется. Остальные — легаси: devicemapper удалён, aufs ушёл из современных ядер, а vfs существует лишь как no-CoW запасной вариант, копирующий каждый слой целиком (используется внутри контейнеров или для отладки, никогда ради производительности).

$ docker info --format '{{ .Driver }}'
overlay2

$ docker info --format '{{ json .DriverStatus }}'
[["Backing Filesystem","extfs"],["Supports d_type","true"],["Using metacopy","false"]]

Выбор драйвера сегодня в основном не-решение — берите overlay2 — но знать, какой у вас, важно при диагностике, потому что у каждого драйвера своя единица copy-up и накладные расходы. У vfs нет цены copy-up, потому что нет разделения (он дублирует всё, так что 10-слойный образ занимает 10-кратный диск). btrfs и zfs делают copy-up на блочной гранулярности и предлагают снапшоты, но требуют выделенной ФС и несут свой операционный вес. Компромисс overlay2 — файловый copy-up, разделяемый page cache, отсутствие особой настройки — это то, что делает его прагматичным универсальным дефолтом.

Гранулярность overlay2: обоюдоострый файловый copy-up

overlay2 работает на уровне файла, а не блока. Этот единственный факт определяет и лучшее, и худшее его поведение. С хорошей стороны он включает разделяемый page cache: когда десять контейнеров из одного образа читают один файл из общего lowerdir, ядро держит одну запись page cache, а не десять — так что узел с 200 копиями образа не платит 200-кратной памятью за общие страницы. Поэтому overlay2 — рекомендуемый драйвер для высокоплотных PaaS-хостов.

С плохой стороны файловая гранулярность означает, что единица copy-up — весь файл. Измените один байт большого файла — и весь файл сперва копируется в upperdir (разобрано в уроке о записываемом слое), но более тонкая цена — давление на inode и метаданные. Inode (запись в таблице ФС, хранящая метаданные файла: тип, размер, владелец, указатели на блоки) — конечный ресурс: ФС имеет фиксированное их количество, не зависящее от свободного места на диске. Каждый скопированный наверх файл потребляет свежий inode в записываемом слое; образ с сотнями тысяч мелких файлов (node_modules, питоновский site-packages, разросшееся дерево ассетов) может исчерпать таблицу inode ФС хоста задолго до исчерпания блоков. df -h измеряет блоки и читается нормально; df -i измеряет inode и читается на 100%. Это отказ из истории, и он невидим тому, кто смотрит только на байтовое использование диска.

Диагностика и обход проблем уровня драйвера

Senior-ходы следуют из механизма. Первое, измеряй оба ресурса: алерт узла про диск должен проверять df -h и df -i; инцидент исчерпания inode на уровне приложения выглядит идентично инциденту переполнения блоков, но лечится иначе. Второе, держи большие изменяемые файлы и оборот множества мелких файлов вне записываемого слоя — тома полностью обходят драйвер, так что база на томе не платит copy-up и не жжёт inode overlay2. Третье, реклейми агрессивно: остановленные контейнеры, висячие образы и кэш сборки накапливают слои и inode; docker system df показывает разбивку, а docker system prune реклеймит, но на нагруженном CI-хосте это надо планировать, а не надеяться. Четвёртое, на xfs-бэкенде подтверди ftype=1 (overlay2 без него отказывается стартовать) и помни, что у некоторых xfs-настроек фиксированная аллокация inode, которую файлоёмкая нагрузка может перерасти.

Вместе эти четыре хода закрывают оба сценария отказа: трату блоков на copy-up большого файла и невидимый дрейф inode на мелкофайловой нагрузке. Пропусти второй — починишь байты, а не исчерпание файлов; пропусти третий — проблема вернётся за несколько дней на нагруженном CI-флоте.

Внутреннее, что надо усвоить: драйвер хранилища — не ручка для кручения (overlay2 — это ответ), а механизм, поведение которого надо уметь объяснять. Большинство инцидентов «Docker-диск» — это на самом деле файловый copy-up overlay2, встретивший либо большой файл (трата блоков, затыки copy-up), либо множество мелких файлов (исчерпание inode), и том — escape-люк для обоих, потому что он полностью обходит драйвер.