ZFS — файловая система с деревом Меркла и поддержкой копирования при записи с функциями менеджера томов, созданная Sun Microsystems в 2004—2005 годах для операционной системы Solaris. Поддерживает большие объёмы данных, позволяет создавать RAID-массивы. Существуют открытые реализации ZFS, в частности, OpenZFS лицензируется под CDDL (в отличие от подобной ZFS файловой системы BTRFS, лицензируемой по GPL). По состоянию на 2024 год OpenZFS активно развивается.
Основные преимущества ZFS — это полный контроль над физическими носителями и логическими томами и постоянное поддержание согласованности файловой системы. Оперируя на разных уровнях абстракции данных, ZFS способна обеспечить высокую скорость доступа к ним, контроль их целостности, а также минимизацию фрагментации данных. ZFS гибко настраивается, позволяет в процессе работы изменять объём доступного пространства хранения и задавать разный размер блоков данных для разных применений, обеспечивает параллельность выполнения операций чтения-записи.
История ZFS была спроектирована и создана в Sun Microsystems командой во главе с Джефом Бонвиком (), анонсирована 14 сентября 2004 года. Исходный код для финального релиза был интегрирован в главную ветку разработки Solaris 31 октября 2005 года.
ZFS вошла в 27 сборку OpenSolaris, выпущенную 16 ноября 2005 года. Sun заявила, что ZFS была интегрирована в 6/06 обновление для Solaris 10 в июне 2006 года, по прошествии одного года с момента открытия сообщества OpenSolaris.
Первоначально ZFS называлась «Zettabyte File System», но позже название превратилось в простую аббревиатуру.
ZFS была выпущена под коммерческой лицензией в составе операционной системы Solaris, затем SUN Microsystems открыла исходные коды ZFS в проекте OpenSolaris под лицензией CDDL. После приобретения SUN Microsystems компанией Oracle код снова был закрыт, однако к этому времени ZFS уже была включена в FreeBSD и другие проекты с открытыми лицензиями, которые вели разработку независимо и обменивались исходными кодами путём «обратного портирования» ().
В 2013 году запущен проект , в котором применяются новые возможности и исправления из Illumos и распространяются во все порты в другие платформы, и наоборот.
Специфика
Максимальные возможности ZFS — 128-битнаяПростейшая проверка показывает, что в текущей реализации более 16 ЭиБ пул не может использовать. Эту проверку легко провести самостоятельно, так как устройства по 8 ЭиБ предоставляет сама ZFS хоть сотнями на реальный гигабайт места при использовании сжатия. файловая система, что позволяет ей хранить в 18,4 × 1018 раз больше данных, чем все известные 64-битные системы. ZFS спроектирована так, чтобы её ограничения были настолько недостижимы, что в обозримом будущем не встретятся на практикеКак заявил руководитель проекта Бонвик, «заполнение 128-битных файловых систем превысит квантовые возможности хранения данных на Земле. Вы не сможете заполнить и хранить 128-битный объём, не вскипятив при этом океан.» Пример того, насколько велики эти числа: если создавать 1000 файлов каждую секунду, для достижения предела количества файлов в ZFS потребуется около 9000 лет. Расчёт показывает, что требуемое время составляет 8925,5129601298833079654997463217 лет без учёта изменения угловой скорости записи на диск и других издержек. В ответ на вопрос о заполнении ZFS без кипячения океанов, Бонвик пишет: «Хотя мы все хотели бы, чтобы Закон Мура выполнялся бесконечно долго, квантовая механика накладывает некоторые фундаментальные ограничения на скорость вычислений и информационную вместимость любого физического устройства. В частности, было показано, что 1 килограмм материи, ограниченный 1 литром пространства, может выполнять не более 1051 операций в секунду над не более чем 1031 бит информации [см. Seth Lloyd, „Ultimate physical limits to computation .“ Nature 406, 1047—1054 (2000)]. Целиком заполненный 128-битный объём будет содержать 2128 блоков = 2137 байт = 2140 бит; поэтому минимальная масса, необходимая для хранения этого количества бит, будет (2140 бит) / (1031 бит/кг) = 136 млрд кг.».
Некоторые теоретические пределы в ZFS:
248 — количество снимков в любой файловой системе (2 × 1014); 248 — количество файлов в любой индивидуальной файловой системе (2 × 1014); 256 зеттабайт (1021 байт) — максимальный размер файловой системы; 16 эксбибайт (264 байт) — максимальный размер одного файла; 16 эксбибайт (264 байт) — максимальный размер любого атрибутаНа атрибуты, используемые ОС, накладываются дополнительные ограничения, например, размер атрибута ФС для списка доступа по NFS в Solaris ограничен примерно 10⁴ байт, что соответствует от 2000 до 20 пользователей в зависимости от длин логинов и хостов.; 3 × 1023 петабайт — максимальный размер любого пула хранения (zpool); 256 — количество атрибутов файла (фактически ограничивается 248 на количество файлов в файловой системе ZFS); 256 — количество файлов в каталоге (реально ограничен 248 на количество файлов в файловой системе ZFS); 264 — количество устройств в любом пуле; 264 — количество пулов в системе; 264 — число файловых систем в одном пуле; 255 байт — максимальная длина имени файла (не полного имени, а относительно родительской папки); 255 байт — максимальная длина полного имени хранилища данных (файловой системы, тома, снимка, общего ресурса и т. д.). При этом утилиты управления ФС накладывают дополнительные ограничения.
Пулы хранения В отличие от традиционных файловых систем, которые располагаются на одном устройстве и, следовательно, при использовании более чем на одном устройстве для них требуется менеджер томов, ZFS строится поверх виртуальных пулов хранения данных, называемых zpool. Пул построен из виртуальных устройств (vdevs), каждое из которых является либо физическим устройством, либо зеркалом (RAID 1) одного или нескольких устройств, либо (RAID Z) — группой из двух или более устройств. Ёмкость всех vdevs затем доступна для всех файловых систем в zpool.
Для ограничения пространства, доступного конкретной файловой системе или тому, может быть установлена квота. Кроме того, возможно использование резервирования пространства хранения (лимита) — это гарантирует, что всегда будет оставаться некоторый доступный объём для конкретной файловой системы или тома.
Версии пула ZFS Существуют различные версии файловой системы ZFS и версии пула ZFS (zpool), в зависимости от версии доступны различные функциональные возможности. По состоянию на ноябрь 2012 существует 34 версии пула ZFS. Все версии пула изначально выпускаются для Solaris.
В версии 2 была включена поддержка реплицируемых метаданных (). Ввиду того, что структура формата ZFS древовидная, невосстановимые ошибки в метаданных пула могут привести к тому, что пул нельзя будет открыть. Данная функция предоставляет автоматическую репликацию метаданных (до трёх копий каждого блока) независимо от избыточности зависимых пулов (). Например, в пуле с единственным зеркалом наиболее критичные метаданные будут трижды записаны на каждой стороне зеркала, в общей сложности шесть копий. Это позволяет удостовериться, что, если данные потеряны вследствие повреждения, все данные в пуле будут доступны для нахождения и пул будет работоспособным.
В версии 3 включена поддержка технологий горячего резерва и RAID-Z двойной чётности (raidz2); в версии 4 внедрена поддержка ведения истории пула ZFS (zpool history); в версии 5 добавлена поддержка сжатия на лету для наборов данных ZFS методом gzip; в версии 6 включена поддержка свойства bootfs (позволяет переключать корневую ФС загружаемой ОС через атрибут, помимо опции загрузчика).
В версии 7 реализована поддержка «целевого журнала» (, ZIL, букв. «журнал намерений»), который предоставляет приложениям возможность узнать, что данные, ими изменённые, находятся в стабильном хранилище, по возврату из системного вызова. Целевой журнал хранит записи этих системных вызовов, они воспроизводятся заново, если произошёл сбой питания или критическая ошибка, при которой основной пул не подтвердил их выполнение. Когда целевой журнал находится вне основного пула, он выделяет блоки, которые идут цепочкой через пул.
В версии 8 реализована возможность делегировать административные задачи по управлению ZFS обычным пользователям, до этого возможность управлять ZFS была только у администраторов.
В версии 9, в дополнение к существующим функциям квотирования и резервирования, добавлено назначение квот и резервов, не включающих потребление пространства хранения вложенными структурами данных, такими как клоны и квоты (zfs set refquota, zfs set refreservation). Резервирование автоматически устанавливается, когда созданный неразрежённый () том ZFS соответствует размеру раздела. Также в версии 9 добавлена поддержка CIFS-сервера.
В версии 10 появилась возможность добавлять устройства в пул как кэширующие для обеспечения дополнительного уровня кэширования между основной памятью и системой хранения. Использование кэширующих устройств существенно увеличивает производительность при нагруженных операциях неупорядоченного считывания, в основном статичного содержимого. В версии 12 появилась поддержка свойств снимков, в версии 13 стали доступны следующие свойства снимков: usedbysnapshots, usedbychildren, usedbyrefreservation, usedbydataset, в версии 14 доступны также свойства passthrough-x и aclinherit, в версии 15 включены свойства userused, groupused, userquota, groupquota.
В версии 17 реализована поддержка RAID-Z тройной чётности. В версии 18 поддержана функция задержки снимков (ZFS snapshot holds). Начиная с версии 19 появилась возможность удалить присоединённое устройство для хранения журналов, ранее такое устройство удалить было невозможно. В 20-й версии включён алгоритм сжатия zle.
В версии 21 реализована дедупликация (существенным образом использует zle). Начиная с версии 30 поддерживается шифрование файловой системы, начиная с версии 32 поддерживается блок размером 1 Мбайт, а в версии 34 реализовано создание общих сетевых ресурсов с наследованием между файловыми системами.
В версии 37 добавлена поддержка алгоритма сжатия lz4 (более эффективного и быстрого по сравнению с имевшимися).
Модель транзакций с использованием копирования при записи ZFS использует модель объектных транзакций на основе механизма копирования при записи. Все указатели на блоки внутри файловой системы содержат 256-битную контрольную сумму в целевом блоке, которая проверяется, когда блок прочитан. В качестве контрольной суммы может использоваться либо сумма Флетчера, либо криптографическая хеш-функция SHA-256. См. главу 2.4. Для данных могут быть выбраны и другие контрольные суммы. Блоки данных, содержащие активные (в этот момент) данные, никогда не перезаписываются вместе; напротив, выделяется новый блок, изменённые данные записываются в него, а затем — метаданные любых блоков, которые на него ссылаются, таким образом всё перераспределяется и записывается. Чтобы уменьшить накладные расходы, в этом процессе группируется несколько обновлений в группу транзакции, также, если требуется, ведётся журнал использования при синхронной записи.
Пул ZFS ведёт журнал нескольких последних десятков версий данных пула (на несколько последних минут, часов или дней, в зависимости от интенсивности изменения данных), предназначенный для восстановления данных в случае, если ошибка в системе привела пул в нерабочее неизлечимое состояние. Благодаря копированию при записи все эти версии данных в журнале самодостаточны, но разделяют между собой общие данные.
Снимки и клоны