ZFS: структуры на диске и алгоритмы работыZFS: on-disk structures and working algorithms

Классический стек хранения — это несколько независимых слоёв: RAID (аппаратный или mdadm) ничего не знает про файлы, файловая система ничего не знает про физическое расположение данных на дисках. ZFS убирает эту границу: она сама решает, на каком диске (или дисках, при зеркалировании/RAID-Z) физически разместить каждый блок, сама считает и хранит его чексумму, и сама знает, есть ли под рукой избыточная копия для восстановления при повреждении. Именно это единство даёт ZFS то, что классической связке ФС+RAID недоступно в принципе: RAID-Z без write hole (потому что ФС знает реальный размер записи и не пишет фиксированный страйп) и мгновенные снапшоты (потому что ФС и так уже пишет через copy-on-write, снапшот — это просто «не трогать старые блоки»).A classic storage stack is several independent layers: RAID (hardware or mdadm) knows nothing about files, and the filesystem knows nothing about the physical layout of data on the disks. ZFS removes that boundary: it decides itself which disk (or disks, under mirroring/RAID-Z) to physically place each block on, computes and stores its checksum itself, and knows itself whether a redundant copy is on hand to recover from on corruption. That unity is exactly what gives ZFS what a classic filesystem+RAID combo can't have in principle: RAID-Z with no write hole (because the filesystem knows the real write size and doesn't write a fixed stripe) and instant snapshots (because the filesystem already writes via copy-on-write anyway — a snapshot is just "don't touch the old blocks").

Первое, что нужно перестать искать в ZFS — это «раздел» в привычном смысле. Вместо этого есть иерархия из четырёх уровней, где верхний (pool) объединяет физическое железо, а всё остальное — уже логические сущности внутри него, свободно делящие общее пространство:The first thing to stop looking for in ZFS is a "partition" in the usual sense. Instead there's a four-level hierarchy, where the top level (the pool) unifies the physical hardware, and everything else is a logical entity inside it, freely sharing the common space:

Каждый блок в ZFS адресуется не просто указателем, а block pointer-ом — структурой, которая помимо физического адреса содержит контрольную сумму содержимого этого блока. Решающая деталь: чексумма хранится не рядом с данными, а в родительском блоке, который на этот блок ссылается. Из-за этого чексуммы выстраиваются в цепочку вверх до корня — классическое merkle-дерево:Every block in ZFS is addressed not by a plain pointer but by a block pointer — a structure that, besides the physical address, holds a checksum of that block's contents. The decisive detail: the checksum isn't stored next to the data — it's stored in the parent block that references it. That's why checksums chain upward to the root — a classic merkle tree:

Отсюда прямо следует self-healing: если том избыточный (mirror, RAID-Z) и чексумма не совпала, ZFS читает ту же логическую позицию с другого диска/копии — и если её чексумма совпадает, молча подменяет повреждённые данные исправными прямо во время обычного чтения, без вмешательства администратора. zpool scrub — та же самая проверка, только принудительно прогнанная по каждому когда-либо записанному блоку пула, а не только по тем, что реально читают приложения: цель — найти и исправить повреждение, пока жива вторая копия, а не в момент, когда редко используемый файл наконец понадобился.Self-healing follows directly from this: if the volume is redundant (mirror, RAID-Z) and a checksum doesn't match, ZFS reads the same logical position from another disk/copy — and if that one's checksum matches, it silently swaps the corrupted data for the good copy right during an ordinary read, with no administrator involved. zpool scrub is the same check, just forced across every block the pool has ever written, not just the ones applications happen to read: the goal is to find and fix corruption while a second copy is still alive, not the moment a rarely used file is finally needed.

RAID-Z решает write hole классического RAID5 — рассинхронизацию данных и parity при сбое питания посреди записи страйпа — трюком, доступным только файловой системе, слитой с менеджером томов: вместо фиксированной ширины страйпа RAID-Z делает страйп переменной ширины, ровно под размер записываемого блока, так что каждая запись — это по определению полный страйп:RAID-Z solves classic RAID5's write hole — data and parity going out of sync on a power failure mid-stripe-write — with a trick only a filesystem fused with its volume manager can pull off: instead of a fixed stripe width, RAID-Z uses a variable-width stripe, sized to exactly the block being written, so every write is by definition a full stripe:

Это стало возможным только потому, что метаданные файловой системы содержат достаточно информации о модели избыточности нижележащего хранилища, чтобы работать с переменной шириной RAID-страйпа — то есть ровно то же самое архитектурное слияние ФС и volume manager-а, о котором шла речь выше. RAID-Z официально называют первым программным решением write hole RAID5, не требующим ни NVRAM-кэша контроллера, ни батарейки.This is possible only because the filesystem's metadata carries enough information about the underlying storage's redundancy model to work with a variable-width RAID stripe — exactly the fusion of filesystem and volume manager discussed above. RAID-Z is officially described as the first software-only fix for RAID5's write hole, needing neither a controller's NVRAM cache nor a battery.

Кэширование в ZFS тоже не полагается на обычный page cache ядра, а реализует собственный многоуровневый механизм — отдельно для чтения и для записи:Caching in ZFS also doesn't rely on the kernel's ordinary page cache — it implements its own multi-tier mechanism, separately for reads and writes:

Снапшот в ZFS — прямое следствие copy-on-write, а не отдельно реализованная фича: он фиксирует состояние dataset-а в момент создания, продолжая указывать на те же самые физические блоки, что и «живая» версия. Пока данные не меняются, снапшот не занимает почти никакого дополнительного места — расход появляется только тогда, когда изменённые блоки в «живой» версии начинают расходиться со снапшотом через обычный механизм CoW.A snapshot in ZFS is a direct consequence of copy-on-write, not a separately implemented feature: it captures a dataset's state at creation time while continuing to point at the exact same physical blocks as the "live" version. As long as the data doesn't change, a snapshot uses almost no extra space — usage only appears once the "live" version's modified blocks start diverging from the snapshot through the ordinary CoW mechanism.

zfs send превращает снапшот (или разницу между двумя снапшотами) в поток байт — не файловый архив, а именно поток блочных изменений, который можно передать по сети или сохранить в файл. Полный send отправляет все данные снапшота целиком; инкрементальный (-i) — только блоки, отличающие один снапшот от другого, что делает регулярную репликацию на удалённую машину дешёвой по трафику даже для больших dataset-ов. Принимающая сторона (zfs receive) для инкрементального потока обязана уже иметь dataset, чей последний снапшот совпадает с начальной точкой потока — иначе применить разницу невозможно.zfs send turns a snapshot (or the difference between two snapshots) into a byte stream — not a file archive, but literally a stream of block-level changes that can be piped over the network or saved to a file. A full send ships an entire snapshot's data; an incremental one (-i) ships only the blocks that differ between two snapshots, which makes regular replication to a remote machine cheap in bandwidth even for large datasets. The receiving side (zfs receive) for an incremental stream must already have a dataset whose latest snapshot matches the stream's starting point — otherwise there's no way to apply the difference.

• OpenZFS documentation — Checksums and Their Use in ZFS
• OpenZFS documentation — RAIDZ
• OpenZFS documentation — zfs-send(8)
• OpenZFS wiki — Documentation/ZfsSend