ZFS

ZFS

Разработчик	Sun Microsystems (получено пользователь Oracle Corporation в 2009 г.)
Написано на	C, C ++
семейство ОС	Unix (System V Release 4 )
Рабочее состояние	Текущая
Исходная модель	Смешанная с открытым исходным кодом / с закрытым исходным кодом
Первоначальный выпуск	июнь 2006 г. ; 14 лет назад (2006-06) Solaris 10 6/06 ("U2")
Последний выпуск	11.4 / 28 августа 2018 г.; 2 года назад (28.08.2018)
Маркетинговая цель	Рабочая станция, сервер
Платформы	SPARC, x86-64, IA-32 (кроме Solaris 11), PowerPC (Solaris 2.5 Только.1)
Лицензия	Разное
Официальный сайт	www.oracle.com / solaris

OpenZFS

Первоначальный выпуск	Переносился на различные системы в период с 2006 по 2010 год. Разветвлен из OpenSolaris, август 2010; 10 лет назад (2010-08)
Репозиторий	github.com / openzfs / zfs
Написано в	C
Операции g system	OpenSolaris, illumos distributions, OpenIndiana, FreeBSD, Mac OS X Server 10.5 (только для чтения- только поддержка), NetBSD, Linux через сторонний модуль ядра («ZFS на Linux») или ZFS- FUSE, OSv
Лицензия	с открытым исходным кодом CDDL
Веб-сайт	open-zfs.org

ZFS (старый: Zettabyte файловая система) объединяет файловую систему с менеджером томов . Он начался как часть Sun Microsystems Solaris операционной системы в 2001 году. Большая часть Solaris, включая ZFS, была опубликована под лицензией с открытым исходным кодом. as OpenSolaris в течение примерно 5 лет с 2005 года, прежде чем был помещен под лицензию с закрытым исходным кодом, когда Oracle Corporation приобрела Sun в 2009/2010. В течение 2005–2010 годов версия ZFS с открытым исходным кодом была перенесена на Linux, Mac OS X (продолжение как MacZFS ) и FreeBSD. В 2010 году проект illumos разветвил последнюю версию OpenSolaris, чтобы продолжить ее развитие, как проект с открытым исходным кодом, включая ZFS. В 2013 году была основана OpenZFS для разработки ZFS с открытым исходным кодом. OpenZFS поддерживает и управляет основным кодом ZFS, в то время как используемые, использующие ZFS, содержит определенный код и процессы, необходимые для интеграции ZFS в свои системы. OpenZFS широко используется в Unix-подобных системах.

• 1 Обзор
• 2 История
  • 2.1 Sun Microsystems (до 2010 г.)
  • 2.2 Дальнейшее развитие
• 3 Возможности
  • 3.1 Резюме
  • 3.2 Целостность данных
  • 3.3 RAID ("RaidZ")
    • 3.3.1 Избегание аппаратных RAID-контроллеров
    • 3.3.2 Подход ZFS: RAID-Z и зеркалирование
    • 3.3.3 Resilvering и scrub (синхронизация массива и проверка целостности)
  • 3.4 Емкость
  • 3.5 Шифрование
  • 3.6 Эффективность чтения / записи
  • 3.7 Другие функции
    • 3.7.1 Устройство хранения, запасные части и квоты
    • 3.7. 2 механизма кэширования: ARC, L2ARC, группы транзакций, ZIL, SLOG, специальный VDEV
      • 3.7.2.1 специальный класс VDEV
    • 3.7.3 транзакционная модель копирования при записи
    • 3.7.4 Снимки и клоны
    • 3.7.5 Отправка и получение моментальных снимков
    • 3.7.6 Динамическое чередование
    • 3.7.7 Переменные размеры блоков
    • 3.7.8 Создание облегченной файловой системы
    • 3.7.9 Адаптивная последовательность байтов
    • 3.7.10 Дедупликация
    • 3.7.11 Дополнительные возможности
• 4 Ограничения
  • 4.1 Ограничение в предотвращении повреждения данных
  • 4.2 Другие ограничения, характерные для ZFS
• 5 Восстановление
• 6 OpenZFS и ZFS
  • 6.1 Коммерческие продукты и продукты с открытым исходным кодом
  • 6.2 Корпорация Oracle, закрытый исходный код и разветвление (с 2010 г.)
• 7 История версий
  • 7.1 Список операционных систем, поддерживающих ZFS
• 8 См. Также
• 9 Примечания
• 10 Ссылки
• 11 Библиография
• 12 Внешние ссылки

Управление хранимыми данными обычно включает два аспекта: физическое управление томами одного или нескольких блочных запоминающих устройств, таких как жесткие диски и SD-карты и их организация в логические блочные устройства с точки зрения операционной системы (часто с использованием диспетчера томов, RAID-контроллера или подходящего драйвера устройства ), а также управление данными и файлами, которые хранятся на этих логических блочных устройств (файловая система или другое хранилище данных).

Пример: массив RAID из 2 жестких дисков и кэширующего диска SSD управляется системой Intel RST, частью набора микросхем и Прошивка встроена в настольный компьютер. Пользователь Windows видит как единый том, предоставленный диск с данными в формате NTFS, и NTFS не обязательно знает о манипуляциях, которые могут потребоваться (например, чтение / запись на кэш-диск или если диск вышел из строя). Управление отдельными устройствами и их представлением.

ZFS необычна, потому что, уникальное отличие от других других служб хранения, она объединяет обе эти роли и функции как диспетчер томов, так и файловая система. Следовательно, он имеет полное представление как о физических дисках, так и о томах (включая их состояние и статус, их логическое представление в томах, а также обо всех файлах, хранящихся на них). ZFS предназначено для обеспечения (при наличии подходящего оборудования ), что данные, хранящиеся на дисках, не могут быть потеряны из-за физических ошибок или неправильной обработки аппаратом или системой, или битовой гнилью события и повреждение данных, что может произойти со временем, и его полный контроль над системой хранения, чтобы использовать каждый шаг, связанный с разрушением данных или управлением дисками, проверяется, подтверждается, исправляется, если необходимо, и оптимизируется таким образом, что карты контроллера памяти, тома и файловые менеджеры не могут быть достигнуты.

ZFS также включает механизм для наборов данных и пулов, снимков и репликации, включая клонирование снимков , которое описывается Документация FreeBSD как одна из ее «самых мощных функций», обладающая функциями, которые «не хватает даже другим файловым системам с функцией моментальных снимков». Можно сделать очень большое количество моментальных снимков без производительности, что позволяет использовать операционные системы и изменениями программного обеспечения, или целую производственную («») файловую систему, чтобы делать полные моментальные снимки несколько раз в час, уменьшить потерю данных из-за ошибки пользователя или злонамеренных действий. Моментальные снимки можно откатить «в реальном времени» или просмотреть предыдущие состояния файловой системы даже в очень больших файловых системах, что приведет к экономии по сравнению с формальными процессами резервного копирования и восстановления. Снимки также можно клонировать для формирования новых независимых файловых систем. Доступен моментальный снимок пула (известный как «контрольная точка»), который позволяет откатить операции, которые могут повлиять на всю текущую пула, или которые добавляют или удаляют целые наборы данных.

Sun Microsystems (до 2010 г.)

В 1987 году ATT Corporation и Sun объявили, что они сотрудничают в рамках проекта по объединению популярные варианты Unix на рынке в то время: Berkeley Software Distribution, UNIX System V и Xenix. Это стало Unix System V Release 4 (SVR4). Проект был выпущен под названием Solaris, которое стало преемником SunOS 4 (хотя микро-релизы SunOS 4.1.x имели задним числом Solaris 1).

ZFS была разработана и реализован командой Sun во главе с Джеффом Бонвиком, Биллом Муром и Мэтью Аренсом. Об этом было объявлено 14 сентября 2004 г., но разработка началась в 2001 г. Исходный код ZFS интегрирован в основную часть разработки Solaris 31 октября 2005 г. и выпущен для разработчиков как часть сборки 27 OpenSolaris 16 ноября 2005 г. В июнь 2006 г. Sun объявила о включении ZFS в обновление 6/06 до Solaris 10.

Исторически Solaris разрабатывался как проприетарное программное обеспечение. Sun Microsystems была решительным сторонником программного обеспечения с открытым исходным кодом. В июне 2005 года Sun выпустила большую часть кодовой базы по лицензии CDDL и основала проект OpenSolaris с открытым исходным кодом. Sun была одним из первых сторонников с помощью открытого исходного кода, и с помощью OpenSolaris Sun хотела создать вокруг этого программного обеспечения сообщество разработчиков и пользователей. В Solaris 10 6/06 («U2») Sun добавила файловую систему ZFS. В течение следующих 5 лет (с 2006 по 2010 год) Sun часто обновляла ZFS новыми функциями, и ZFS была перенесена на Linux, Mac OS X (продолжение как MacZFS ) и FreeBSD под этой лицензией с открытым исходным кодом.

Одно время говорилось, что это имя означает «Файловая система Zettabyte», но к 2006 году уже не считалось сокращением. Файловая система ZFS может хранить до 256 квадриллионов зеттабайт (ZB).

В сентябре 2007 года NetApp подала в суд, утверждая, что ZFS нарушила некоторые патенты NetApp на Write Anywhere File Layout. В октябре того же года Солнце подала встречный иск, утверждая обратное. Судебные процессы были завершены в 2010 году нераскрытым урегулированием.

Дальнейшее развитие

Отсортированные версии ZFS начали появляться в 2005 году. После приобретения Oracle Sun компанией Oracle в 2010 году, версия ZFS для Oracle стала закрытым исходным кодом, разработка версий с открытым исходным кодом шла независимо, координируемая OpenZFS с 2013 года.

Резюме

Возможности среди функций ZFS:

• Предназначен для длительного хранения данных и неограниченно масштабируемых размеров хранилища с нулевой потерей данных и широкими возможностями.
• Иерархическое контрольное суммирование всех данных и метаданные, гарантирующие, что вся система хранения может быть проверена при использовании и подтверждена правильность хранения или исправление в случае повреждения. Контрольные хранятся в родительском блоке блок, а не в самом блоке. Это данные со множеством файловых систем, где контрольные суммы хранятся вместе с данными, так что, если данные потеряны или повреждены, контрольная сумма также может быть потеряна или неверна.
• Может хранить указанное количество копий данных или метаданных или выбранных типов для улучшения возможности восстановления важных файлов и повреждений данных.
• Автоматический откат последних изменений в файловой системе и данных в некоторых обстоятельствах, в случае ошибки или несоответствия.
• Автоматическое и (обычно) бесшумное самовосстановление несогласованности данных и сбоя записи при обнаружении для всех ошибок, данные можно восстановить. Данные могут быть восстановлены, используя все следующие: контрольные проверки обнаружения и исправления ошибок, хранящиеся в родительском блоке каждого блока; множественные копии (включая контрольные суммы), хранящиеся на диске; записывать намерения, зарегистрированные в SLOG (ZIL) для записей, которые должны были произойти, но не произошли (после сбоя питания); данные о четкости с дисков и томов RAID / RAIDZ; копии данных с зеркальных дисков и томов.
• Собственная обработка стандартных уровней RAID и дополнительных схем ZFS RAID ("RAIDZ "). Уровни RAIDZ распределяют данные только по требуемым дискам для повышения эффективности (многие системы RAID, определяющие чередование по всем устройствам без разбора), контрольная сумма позволяет восстановить несогласованные или поврежденные данные, чтобы свести к минимуму те блоки с дефектами;
• Собственная обработка многоуровневых устройств хранения и кэширования, которые обычно являются элементами с объемом. ZFS также понимает файловую систему, она может использовать информацию о файле для информирования, интеграцию и оптимизацию многоуровневой обработки хранилища, чего не может отдельное устройство;
• Собственная обработка моментальных снимков и резервное копирование / репликация что можно сделать более эффективным, объединив управление томами и файлами. Соответствующие инструменты на низком уровне требуют внешних сценариев программного обеспечения для использования.
• Собственное сжатие данных и дедупликация, хотя последнее в основном обрабатывается в RAM и требует много памяти.
• Эффективное восстановление RAID-массивов - RAID-контроллеру часто приходится перестраивать весь диск, но ZFS объединяет информацию о диске и файле, чтобы ограничить любое восстановление данных, которые на самом деле отсутствует или поврежден, что значительно ускоряет восстановление;
• На него не влияют изменения оборудования RAID, которые влияют на многие другие системы. Во многих системах, если автономное оборудование RAID, это как карта RAID, выходит из строя, или данные перемещаются в другую систему RAID, в файловой системе не будет информации, которая необходима для управления данными на RAID. массив. Это может быть приведено к полной потере данных, если почти идентичное оборудование не может быть приобретено и использовано в «ступеньки». ZFS сама управляет RAID, пул ZFS можно перенести на другое оборудование или переустановить операционную систему, а структуры и данные RAIDZ будут снова распознаны и доступны ZFS.
• Возможность идентифицировать данные это можно было бы найти в кеше, но вместо этого недавно выбросили; это позволяет ZFS пересмотреть свои решения по кешированию в свете использования и достижений очень высокому уровню попаданий в кеш (процент попаданий в кеш ZFS обычно превышает 80%);
• Альтернативные стратегии кэширования сообщений, которые заставляют нас выполнить обработку данных. Например, синхронная запись, которая может замедлить работу системы хранения, может быть преобразована в асинхронную запись путем записи на быстрое отдельное кэширующее устройство, известное как SLOG (иногда называемое ZIL - ZFS Intent Log).
• Высокая степень настройки - многие внутренние параметры могут быть настроены для оптимальной функциональности.
• Хотя и не предназначено полностью для этого использования кластеров и вычислений с высокой доступностью.

Целостность данных

Одной из основных особенностей, которая отличает ZFS от других файловых систем, является то, что она с упором на целостность данных путем защиты данных пользователя на диске от скрытого повреждения данных, вызванного из-за деградации данных, текущих скачков, ошибок на диске прошивки, фантомной записи (предыдущая запись не была записана на диск), неправильное вращение операций чтения / записи (диск обращается к неправильному блоку), ошибки четности DMA между массивом и памятью сервера или из драйвера (поскольку контрольная сумма проверяет входные ошибки данных массива), драйвера (данные попадают в неправильный буфер внутри ядра), случайные перезаписи (например, переключение на работающую файловую систему) и т. д.

Исследование 1999 г. показало, что ни один из основных и широко распространенные файловые системы (такие как UFS, Ext, XFS, JFS или NTFS ), ни аппаратный RAID (который имеет некоторые проблемы с целостностью данных ) не обеспечивает достаточной защиты от проблем с повреждением данных. Первоначальные исследования показывают, что ZFS защищает данные лучше, чем предыдущие попытки. Он также быстрее, чем UFS, и может рассматривать как его замена.

В ZFS достигается целостность данных за счет использования контрольной суммы на основе Флетчера или хэша SHA-256 во всем дереве файловой системы. Каждый блок данных суммируется, и значение контрольной суммы сохраняется в указателе на этот блок, а не в самом блоке. Затем указатель блока получает контрольную сумму, и значение сохраняется в его указателе. Это контрольное суммирование продолжается на всем пути вверх по иерархии файлов системы до корневого узла, который также вычисляется контрольной суммой, создавая, таким образом, дерево Меркла. Повреждение данных в полете или фантомное чтение / запись (контрольные суммы записанных / прочитанных данных правильно, но на самом деле неверны) не установлено большинством файловых систем, поскольку они хранят контрольную сумму вместе с данными. ZFS хранит контрольную сумму каждого блока в указателе родительского блока, поэтому весь пул проходит самопроверку.

Когда осуществляется к блоку независимо от того, является ли он данными или метаданными, его контрольная сумма вычисляется и сравнивается с сохраненным значением контрольной суммы, чем оно «должно быть». Если контрольные совпадают, данные передаются по стеку программирования, который их запросил; если совпадают, ZFS может восстановить данные, если пул хранения обеспечивает избыточность данных (например, с внутренним зеркалированием ), при условии, что копия данных не повреждена и с сопоставлением контрольных контрольныхм. При желании можно обеспечить дополнительную избыточность в пуле, указав copy = 2 (или copy = 3 или более), что означает, что данные будут храниться на диске дважды (или трижды), фактически уменьшаясь вдвое (или, для копий = 3, что сокращает до одной трети) емкость диска. Кроме того, некоторые виды данных, используемые ZFS для управления пулом, по умолчанию сохраняются несколько раз в целях безопасности, даже при настройке по умолчанию copy = 1.

Если существуют другие копии поврежденных данных или их можно восстановить из контрольных сумм и данных четности, ZFS будет использовать копию данных (или воссоздать ее с помощью механизма восстановления RAID) и пересчитайте контрольную сумму, что в идеале приведет к воспроизведению первоначально ожидаемого значения. Если данные проходят эту проверку целостности, система может обновить все дефектные копии с помощью заведомо исправных данных, и избыточность будет восстановлена.

Согласованность данных, хранящихся в памяти, таких как кэшированные данные в ARC, по умолчанию не проверяется, поскольку ожидается, что ZFS будет работать на оборудовании корпоративного качества с ОЗУ с исправлением ошибок, но возможность проверки данных в памяти существует, и ее можно включить с помощью «флагов отладки».

RAID («RaidZ»)

Чтобы ZFS могла гарантировать целостность данных, необходимо несколько копии данных, обычно распределенные по нескольким дискам. Обычно это достигается с помощью контроллера RAID или так называемого «мягкого» RAID (встроенного в файловую систему ).

Отказ от аппаратных контроллеров RAID

Хотя ZFS может работать с аппаратными устройствами RAID, ZFS обычно работает более эффективно и с большей защитой данных, если у нее есть прямой доступ ко всем устройствам хранения, а диски не подключены к системе с помощью оборудования, микропрограмм или другого «программного» RAID или любого другого контроллера, который изменяет обычный путь ZFS-to-disk I / O. Это связано с тем, что ZFS полагается на диск для честного просмотра, чтобы определить момент, когда данные подтверждены как безопасно записанные, и имеет множество алгоритмов , предназначенных для оптимизации использования кэширования, очистка кеша и обработка диска.

Если стороннее устройство представляет собой диски ZFS как единую систему без нижнего уровня представления, на которое опирается ZFS, существует большая вероятность того, что система работает менее оптимально, и что отказ не может быть предотвращен ZFS или так же быстро или полностью восстановлен с помощью ZFS. Например, если используется аппаратная карта RAID, ZFS может быть не в состоянии определить состояние дисков, деградацию или перестройку массива RAID, может не знать обо всех повреждениях данных и не может быть оптимально link данные на дисках., выполняйте только выборочный ремонт, контролируйте баланс между ремонтом и текущим ремонтом, используя аппаратную карту RAID будет мешать. Контроллеры RAID также обычно добавляют на диски данные, зависящие от контроллера, что предотвращает доступ программного RAID к пользовательским данным. Хотя можно прочитать данные с помощью совместимого аппаратного RAID-контроллера, это не всегда возможно, и если на плате возникла неисправность, то могут быть недоступны другие пользовательские данные производителя, которые должны быть управлять и восстанавливать массив на плате. новой карты.

Следовательно, используются карты RAID или аналогичные ресурсы обработки и повышения производительности и надежности, с ZFS рекомендуется использовать эти методы, поскольку они обычно снижают производительность и надежность системы..

Если диски должны быть подключены через RAID или другой контроллер, рекомендуется использовать простой HBA (хост-адаптер) или карту разветвления или настроить карту в режиме JBOD (т. Е. Отключение функций RAID и кэширования), чтобы устройство можно было подключить, но путь ввода-вывода ZFS-диск не изменился. Карта RAID в режиме JBOD может по-прежнему мешать, если у нее есть кэш или в зависимости от ее конструкции, и может отсоединять диски, которые не требуют вовремя (как это было со многими энергоэффективными жесткими дисками потребительского уровня), а также Для предотвращения выпадения дисков может потребоваться ограниченное по времени восстановления после ошибок (TLER) / CCTL / ERC, поэтому не все карты подходят даже с отключенными функциями RAID.

Подход ZFS: RAID-Z и зеркалирование

Вместо аппаратного RAID ZFS использует «мягкий» RAID, предлагая RAID-Z (четкость на основе RAID 5 и т.п.) и зеркалирование диска (аналогично RAID 1 ). Схемы очень гибкие.

RAID-Z представляет собой схему распределения данных / четности, подобную RAID-5, но использует динамическую ширину полосы: каждый блок собственной полосой RAID, независимо от размера блока, в результате чего получается каждый RAID- Запись Z - это запись с полной полосой. Это в сочетании с транзакционной семантикой копирования при записи ZFS, устраняет ошибку отверстия для записи. RAID-Z также быстрее, чем у него, например, RAID 5, потому что не нужно выполнять обычную последовательность read-modify-write.

Временная диаграмма имеет разный размер, восстановление RAID-Z должен пройти через метаданные файловой системы, чтобы определить фактическую геометрию RAID-Z. Это было возможно при наличии интегрированного представления логической и физической структуры данных. Просмотр метаданных означает, что ZFS может проверять каждый блок на соответствие своей 256-битной контрольной сумме, в то время как традиционные продукты RAID обычно не могут этого сделать.

Помимо обработки сбоев всего диска, RAID-Z также может обнаруживать и исправлять скрытое повреждение данных, предлагая «данные самовосстановления»: при чтении блока RAID-Z ZFS сравнивает его со своей контрольной суммой, и если диски данных не вернули правильный ответ, ZFS считывает четность, а затем передает, какой диск вернул неверные данные. Затем он восстанавливает поврежденные данные и возвращает правильные данные запрашивающей стороны.

RAID-Z и зеркалирование не требуют специального оборудования: им не требуется NVRAM для обеспечения надежности, и им не нужна буферизация записи навсегда или защита данных. Благодаря RAID-Z ZFS быстрое и надежное хранилище с использованием дешевых обычных дисков.

Существует пять различных режимов RAID-Z: чередование (аналогично RAID 0, не предлагает избыточности), RAID-Z1 (аналогично RAID 5, допускает отказ одного диска), RAID-Z2 (аналогично RAID 6, допускает отказ двух дисков), RAID-Z3 (конфигурация RAID 7, допускает отказ от трех дисков) и зеркалирование (аналогично RAID 1, позволяет выйти из строя всем дискам, кроме одного).

Потребность в RAID-Z3 возникла в начале 2000-х, когда стали более распространены диски с многотерабайтной емкостью. Это увеличение емкости - без соответствующего увеличения пропускной способности - означало, что восстановление системы из-за неисправного диска могло занять «недели или даже месяцы». В это время более старые диски в массиве будут подвергаться дополнительной нагрузке, что может привести к повреждению данных или отказу диска. Увеличивая четкость, RAID-Z3 снижает вероятность данных, просто увеличивая избыточность.

Resilvering и scrub (синхронизация массива и проверка целостности)

ZFS не имеет инструмента, эквивалентного fsck (стандартный инструмент проверки и восстановления данных Unix и Linux для файловых систем). Вместо этого ZFS имеет встроенную функцию scrub, которая регулярно проверяет все данные и устраняет скрытые повреждения и другие проблемы. Некоторые различия:

• fsck должен запускаться в автономной файловой системе, что означает, что файловая система должна быть размонтирована и требует во время ремонта, в то время как scrub для использования в смонтированной, работающей файловой системе и не Файловая система ZFS должна быть отключена.
• fsck обычно проверяет только метаданные (например, журнал журнала), но никогда не проверяет сами данные. Это означает, что после fsck данные по-прежнему не совпадают с исходными данными в том виде, в каком они сохранены.
• fsck не всегда может проверять и восстанавливать данные, когда контрольные суммы хранятся вместе с данными (часто бывает во многих файловых системах), потому что контрольные суммы также могут быть повреждены или нечитаемы. ZFS всегда хранит контрольные суммы отдельно от данных, которые проверяют, повышенную надежность и возможность очистки тома. ZFS также хранит несколько копий данных - метаданные, в частности, могут иметь до 4 или 6 копий (несколько копий на диск и несколько зеркал дисков на том), что улучшает способность scrub обнаруживать и устранять серьезные повреждения тома. по сравнению с fsck.
• scrub проверяет все, включая метаданные и данные. Эффект можно увидеть, сравнив время fsck и время очистки - иногда fsck на большом RAID завершается за несколько минут, что означает, что проверялись только метаданные. Просмотр всех метаданных и данных на большом RAID занимает много часов, что и делает скраб.

Официальная рекомендация Sun / Oracle - чистить диски корпоративного уровня раз в месяц, а более дешевые стандартные диски - раз в неделю.

Емкость

ZFS - это 128-битная файловая система, поэтому она может адресовать в 1,84 × 10 больше данных, чем 64-битные системы, такие как Бтрфс. Максимальные ограничения ZFS спроектированы настолько, что они никогда не должны встречаться на практике. Например, для заполнения одного zpool 2 битами данных потребуется 3 жестких диска по 10 ТБ.

Некоторые теоретические ограничения в ZFS:

• 2: количество записей в любом отдельном каталоге
• 16 exbibytes (2 байта): максимальный размер одного файла
• 16 эксбибайт: максимальный размер любого атрибута
• 256 квадриллионов zebibytes (2 байта): максимальный размер любого zpool
• 2: количество атрибутов файла (ограничено 2 для количества файлов в каталоге)
• 2: количество устройств в любом zpool
• 2: количество zpools в системе
• 2: количество файловых систем в zpool

Шифрование

В Oracle Solaris возможность шифрования в ZFS встроенный конвейер ввода-вывода. Во время записи может быть заблокирована, зашифрован, рассчитан контрольная сумма и затем дедуплицирован в указанном порядке. Политика шифрования устанавливается на уровне набора данных при создании наборов данных (файловых систем или ZVOL). Ключи обертывания, предоставленные пользователем / администратором, могут быть в любое время без отключения файлов системы. Поведение по умолчанию заключается в том, что ключ упаковки наследуется любыми дочерними наборами данных. Ключи шифрования данных генерируются случайным образом во время создания набора данных. Только дочерние наборы данных (снимки и клоны) имеют общие ключи шифрования данных. Предоставляется команда переключиться на новый ключ шифрования данных для клона или в любое время - при этом не выполняется повторное шифрование уже используемых данных, вместо этого используется зашифрованный механизм главного ключа.

С 2019 года функция шифрования также интегрирована в OpenZFS 0.8.0, доступную для дистрибутивов Debian и Ubuntu Linux.

Эффективность чтения / записи

ZFS автоматически распределяет данные хранилища для всех vdev в пуле (и всех устройств в каждом vdev) таким образом, чтобы в целом максимизировать производительность пула. ZFS также обновит свою стратегию записи, чтобы учесть новые диски, добавленные в пул, их добавлении.

Как правило, ZFS распределяет операции записи между vdev в зависимости от свободного места в каждом vdev. Это гарантирует, что vdev получает больше операций записи при сохранении новых данных. Это помогает, что по мере увеличения использования пула ситуация не разовьется так, что некоторые vdev будут переполнены, что приведет к записи на ограниченном количестве устройств. Это также означает, что при чтении данных (в большинстве случаев чтения используются чаще, чем записи), различные части данных могут быть прочитаны с максимально возможным количеством дисков одновременно, что обеспечивает более эффективное чтение. Поэтому, как правило, следует управлять пулами и vdev и добавлять новые хранилища, когда одни vdev в пуле почти заполнены, а другие почти пусты.

Другие функции

Устройства хранения, запасные части и квоты

Пулы иметь «горячие» резервы для компенсации выхода из строя дисков. Приведенные в пищу блоки питания могут использоваться в соответствии с физическими данными.

Состав пула хранения не ограничивается другими устройствами, но может состоять из специальных, разнородных коллекций устройств, которые ZFS плавно объединяет в пул, позволяет распределять пространство между различными файловыми системами по мере необходимости. К существующим пулам можно добавить устройства хранения произвольных типов для увеличения их размера.

Емкость хранилища всех vdevs доступна для всех экземпляров файловой системы в zpool. Квота может быть установлена ​​для ограничения пространства, которое может занимать экземпляр файловой системы, которое может быть установлено, чтобы безопас, что пространство будет доступно экземпляру файловой системы.

Механизмы кэширования: ARC, L2ARC, группы транзакций, ZIL, SLOG, специальный VDEV

ZFS использует разные уровни дискового кеша для ускорения операций чтения и записи. В идеале все данные должны храниться в ОЗУ, но обычно это слишком дорого. Следовательно, данные автоматически кэшируются в иерархии для производительности по сравнению с затратами; их часто называют «гибридными пулами хранения». Часто используемые данные хранятся в ОЗУ, а менее часто используемые данные хранятся на более медленных носителях, таких как твердотельные накопители (SSD). Данные, к которым не часто обращаются, не кэшируются и остаются на медленных жестких дисках. Если старые данные внезапно будут много читать, ZFS автоматически переместит их на твердотельные накопители или в оперативную память.

Механизмы кэширования ZFS по одному для чтения и записи, и в каждом случае может существовать два уровня кэширования: один в памяти компьютера (ОЗУ) и один в быстром хранилище (обычно твердотельные накопители ( SSD)), всего четыре кэша.

В ZFS также существует ряд других кешей, разделов кешей и очередей. Например, каждый VDEV имеет свой собственный кэш данных, а кэш ARC делится между данными, хранящимися, и метаданными, используемыми ZFS, с контролем баланса между ними.

Специальный класс VDEV

В ZFS 0.8 и более поздних версиях можно настроить специальный класс VDEV для предпочтительного хранения метаданных файловой системы и, при необходимости, таблицы дедупликации данных (DDT) и небольших блоков файловой системы. Это позволяет, например, создать специальный VDEV на быстром твердотельном хранилище для метаданных, в то время как обычные данные файла хранятся на вращающихся дисках. Это ускоряет операции с интенсивным использованием метаданных, как обход файловой системы, очистку и восстановление, без затрат на хранение всей файловой системы в твердотельном хранилище.

Транзакционная модель копирования при записи

ZFS транзакционная модель копирование при записи транзакционную объектную модель. Все указатели блоков в файловой системе содержат 256-битную контрольную сумму или 256-битную хэш (в настоящее время выбор между Флетчер-2, Флетчер- 4 или SHA-256 ) целевого блока, который проверяется при чтении блока. Блоки, активные данные, никогда не перезаписываются на месте; вместо этого выделяется новый блок, в нем записываются измененные данные, затем любые блоки метаданных, которые на него аналогичным образом считываются, перераспределяются и записываются. Чтобы уменьшить накладные расходы на этот процесс, несколько обновлений сгруппированы в группы транзакций, используется кэш-запись ZIL (журнал намерений ), когда требуется синхронная семантика записи. Блоки расположены в виде дерева, как и их контрольные суммы (см. схему подписи Меркла ).

Моментальные снимки и клоны

Преимущество копирования при записи состоит в том, что, когда ZFS записывает новые данные, блоки, содержащие старые данные, могут быть сохранены, что позволяет создать моментальный снимок поддерживаемая версия файловой системы. Моментальные снимки согласованы в ZFS (они отражают все данные в виде, в каком они существуют в определенный момент времени), и могут быть созданы очень быстро, поскольку все данные, составляющие моментальный снимок, уже сохранены, весь пул хранения снимается несколько раз в час.. Они также занимают много места, поскольку любые используются данные файловой системой и ее снимками. По своей сути моментальные снимки доступны только для чтения, что гарантирует, что они не будут использоваться после создания, хотя на них не полагается на единственное средство резервного копирования. Можно восстановить целые снимки, а также файлы и каталоги внутри снимков.

Также можно создать записываемые моментальные снимки («клоны»), в результате чего образуются две независимые файловые системы, совместно используемые набор блоков. По мере внесения изменений в любую из файловых систем клонов новые блоки, отражающие эти изменения. Это принципа реализации Копирование при записи.

Отправка и получение моментальных снимков

Файловые системы ZFS могут быть перемещены в другие пулы, в том числе на удаленных хостах по сети, поскольку команда отправки потоковое представление состояния файловой системы. Этот поток может либо описывать полное содержимое файловой системы на данном снимке, либо быть дельтой между снимками. Вычисление дельта-потока очень эффективно, и его размер зависит от количества блоков, измененных между моментом снимками. Это эффективную стратегию, например, обеспечивает синхронизацию внешних резервных копий или зеркал высокой доступности пула.

Динамическое чередование

Динамическое чередование для всех устройств для увеличения пропускной способности означает, что при добавлении дополнительных устройств в zpool ширина полосы автоматически увеличивается, чтобы пропускание их; таким образом, используются все диски в пуле, что обеспечивает балансировку нагрузки записи между ними.

Размеры блоков с переменным размером <использует <использует

ZFS блоки переменного размера с размером по умолчанию 128 КБ. Доступные функции позволяют администратору настроить максимальный размер используемого блока, поскольку рабочие нагрузки плохо работают с блоками. Если включено сжатие данных, используются блоки переменного размера. Чтобы он поместился в блок меньшего размера, меньший размер на диске для использования меньшего объема памяти и увеличения пропускной способности ввода-вывода (хотя и за счет увеличения использования ЦП для операций сжатия и распаковки).

Создание облегченной файловой системы

В ZFS манипулировать файловой системой в пуле хранения проще, чем манипулировать томами в традиционной файловой системе; Введение в создание или расширение файловой системы ZFS.

Adaptive endianness

Пулы и связанные с ними Файловые системы ZFS можно перемещать между разными архитектурами платформ, включая системы, реализующие разный порядок байтов. Формат указателя блока ZFS хранит метаданные файловой системы с endian -адаптивного метода; отдельные блоки метаданных записываются с собственным порядком байтов системы, записывающей блок. При чтении, если сохраненный порядок байтов не соответствует порядку байтов в системе, метаданные заменяются байтами в памяти.

Это не влияет на сохраненные данные; как обычно в системах POSIX, файлы представляются приложениям как простые массивы байтов, приложения, создавающие и читающие данные, остаются ответственными за это независимо от порядка байтов системы системы.

Дедупликация

Возможности дедупликации данных были добавлены в исходный репозиторий ZFS в конце октября 2009 г. соответствующие пакеты разработки OpenSolaris ZFS доступны с 3 декабря 2009 г. (сборка 128).

Для эффективного использования дедупликации может потребоваться большая емкость ОЗУ; рекомендуются от 1 до 5 ГБ ОЗУ на каждый ТБ хранилища. Точная оценка памяти, необходимой для дедупликации, производится путем использования количеству уникальных блоков в пуле и количеству блоков на диске и в ОЗУ («ядре»), необходимых для хранения каждой записи - эти цифры сообщаются встроенными такими командами, как zpoolи zdb. Недостаточный объем физической памяти или отсутствие кэша ZFS может привести к перебоям виртуальной памяти при использовании дедупликации, что может привести к падению производительности или к полному нехватке памяти. Дедупликация происходит во время записи, она также сильно нагружает процессор и может замедлить работу системы.

Другие поставщики систем хранения используют модифицированные версии ZFS для достижения очень высоких коэффициентов сжатия данных. Двумя примерами в 2012 году были GreenBytes и Tegile. В мае 2014 года Oracle купила GreenBytes для своей технологии дедупликации и репликации ZFS.

Как описано выше, дедупликация обычно не рекомендуется из-за высоких требований к ресурсам (особенно ОЗУ) и влиянию на характеристики (особенно при записи), кроме особых обстоятельств, когда система и данные хорошо подходят для этого метода экономии места.

Дополнительные возможности

• Явный приоритет ввода-вывода с планированием крайнего срока.
• Заявленные глобально оптимальные сортировки и агрегация ввода-вывода.
• Несколько независимых потоков предварительной выборки с длиной и обнаружение шага.
• Параллельные операции с каталогами с постоянным временем.
• Сквозное контрольное суммирование с использованием своего рода «Поле целостности данных », позволяющее обнаруживать повреждение данных (и восстановление, если у вас есть избыточность в пуле). Можно использовать на выбор 3 хэша, оптимизированных для скорости (fletcher), стандартизации и безопасности (SHA256 ) и соленых хэшей (Skein ).
• прозрачное сжатие файловой. Системы Поддерживает LZJB, gzip и LZ4.
• Интеллектуальная очистка и резервное копирование (повторная синхронизация).
• Распределение нагрузки и использования между пространством дисками в пуле.
• Блоки То же: Настраиваемая репликация данных для каждой файловой системы, с нулевой, одной или двумя дополнительными копиями, запрашиваемыми для каждой записи для пользовательских данных, и с тем же самым базовым числом копий плюс одна или две Для метаданных (в соответствии с важности метаданных). Если в пуле нескольких устройств, ZFS пытается выполнить репликацию на разных устройствах. Блоки То же самое в первую очередь дополнительной защитой от поврежденных секторов, а не от полного отказа диска.
• ZFS (копирование на- запись + суперблоки) бе зопасен при использовании дисков с включенным кешем записи, если они соблюдают барьеры записи. Эта функция обеспечивает безопасность и повышение производительности по сравнению с так другими файловыми системами.
• В Solaris, когда целые диски добавляются в пул ZFS, ZFS автоматически включает их кэш записи. Этого не происходит, когда ZFS управляет дискретными фрагментами диска, поскольку он не знает, управляются ли другие фрагменты файловыми системами, не защищенными от записи кэш-памятью, такими как UFS. Реализация FreeBSD может обработать сброс диска для разделов благодаря своей системе GEOM и, следовательно, не страдает от этого ограничения.
• Для каждого пользователя, для каждой группы, для каждого проекта и для каждого - ограничения квот набора данных.
• Шифрование файлов системы, начиная с Solaris 11 Express (в некоторых других системах ZFS может использовать зашифрованные диски для аналогичного эффекта; GELI во FreeBSD можно использовать таким образом для создания полностью зашифрованных ZFS-хранилище).
• Пулы можно импортировать в режиме только для чтения.
• Можно восстановить данные, откатывая все транзакции во время импорта zpool.
• ZFS не является кластерной файловой системой ; однако кластеризованная файловая система ZFS доступная от третьих лиц.
• Моментальные снимки можно делать вручную или автоматически. Более старые версии хранимых данных, которые содержат, могут быть представлены полные файловые системы только для чтения. Они также могут быть представлены как исторические версии файлов и папок при использовании с CIFS (также известный как SMB, Samba или); это известно как «Предыдущие версии», «Теневые копии VSS» или «История файлов» в Windows, или AFP и «Apple Time Machine» на устройствах Apple.
• Диски можно пометить как «запасные». Пул данных может быть настроен для автоматической и прозрачной обработки сбоев диска путем активации переноса диска и начала переноса данных, которые были на него настроены, когда это необходимо.

Есть несколько ограничений файловой системы ZFS.

Ограничения в предотвращении повреждений данных

Авторы исследования 2010 года, в котором изучалась способность файловых систем обнаруживать и предотвращать повреждение данных, с особым вниманием к ZFS, отметили, что ZFS сама по себе эффективна в обнаружении и исправление ошибок на устройствах хранения, но данные в RAM являются «безопасными» и не подвержены ошибкам. Следует отметить, что «переворот одного бита в памяти сбой в небольшом, но немаловажном проценте данных прогонов», при этом вероятность фиксации неверных на дисках считается от 0% до 3,6% (в зависимости от рабочей нагрузки). "и что ZFS кэширует страницы или копии метаданных в ОЗУ, или хранит данные в своем" грязном "кэше для записи на диск, не проводится проверка того, соответствуют ли контрольные данные на момент Большую часть этого риска можно уменьшить одним из двух способов:

• По мнению авторов, с помощью ECC RAM ; однако авторы считают, что добавление обнаружения ошибок связано с кеш страницами и кучу, что позволит ZFS
• Один из основных компонентов ZFS, Мэтт Аренс, объясняет, что есть возможность включить контрольную сумму данных в с помощью Флага ZFS_DEBUG_MODIFY (zfs_flags = 0x10), который решает.

Другие ограничения, характерные для ZFS

• Расширение емкости достигается добавление групп дисков в качестве vdev верхнего уровня: простое устройство, RAID-Z, RAID Z2, RAID Z3 или зеркальное отображение. на зовать все доступные vdev. Также можно расширить массив, итеративно заменяя каждый диск в массиве диском большего размера и ожидая самовосстановления ZFS; время восстановления будет зависеть от объема хранимой информации, а не от размера диска.
• Начиная с Solaris 10 Update 11 и Solaris 11.2, невозможно было уменьшить количество vdev верхнего уровня в пуле, ни иным образом уменьшить емкость пула. Эта функция, как сообщалось, разработывалась в 2007 году. В OpenZFS разработаны усовершенствования, позволяющие уменьшить количество виртуальных файлов.
• С 2008 года было невозможно добавить диск в качестве столбца в RAID Z, RAID Z2 или RAID Z3 vdev. Однако вместо этого можно создать новый RAID Z vdev и добавить его в zpool.
• Некоторые традиционные вложенные конфигурации RAID, такие как RAID 51 (зеркало RAID 5), не настраиваются в ZFS. Vdev может состоять только из необработанных дисков или файлов, но не из других файлов vdev. Однако пул ZFS эффективно создает полосу (RAID 0) через свои vdev, поэтому обычно используется эквивалент RAID 50 или RAID 60.
• Для перенастройки количества устройств в vdev верхнего уровня требуется копирование данных в автономном режиме, уничтожение пула и восстановление пула с новой конфигурацией верхнего уровня vdev, за исключением дополнительной дополнительной избыточности к существующему зеркалу, что можно сделать в любое время или если все vdev верхнего уровня соответствуют зеркалами с достаточной избыточностью, разделение zpool Команда может быть удалена vdev из каждого vdev верхнего уровня в пуле, создавая второй пул с идентичными.
• IOPS пула хранения ZFS может пострадать, если рейд ZFS не настроен должным образом. Так или иначе это относится ко всем типам RAID. Если zpool основан только из одной группы дисков, настроенной, например, как восемь дисков в RAID Z2, то производительность IOPS будет такой же, как у одного диска (скорость записи будет эквивалентна 6 дискам, но скорость произвольного чтения будет аналогична скорости одного диска). Однако есть способы смягчить эту проблему производительности IOPS, например, добавить SSD в качестве кэша L2ARC, что может повысить IOPS до 100000 с. Короче говоря, zpool должен состоять из нескольких групп vdev, каждый vdev состоит из 8-12 дисков, если используется RAID Z. Не рекомендуется создавать zpool с одним большим vdev, скажем, 20 дисков, потому что производительность IOPS будет ниже. для одного диска, что также означает, что время восстановления будет очень долгим (возможно, недели для будущих больших дисков).
• Оперативное сжатие zpool removeне поддерживалось до выхода Solaris 11.4 в августе 2018
• Восстановление (восстановление) поврежденного диска в ZFS RAID может занять много времени, которое не является уникальным для ZFS, оно так или иначе применимо ко всем типам RAID. Это означает, что восстановление очень больших томов или восстановление их полной избыточности после серьезного повреждения данных или сбоя может занять несколько дней, и в течение этого времени может произойти второй сбой диска, особенно потому, что ремонт создает дополнительную нагрузку на систему в целом.. В свою очередь, это означает, что следует избегать конфигураций, которые позволяют восстанавливать только отказ одного диска, таких как RAID Z1 (аналогично RAID 5). Следовательно, с большими дисками следует использовать RAID Z2 (допускает отказ двух дисков) или RAID Z3 (допускает отказ трех дисков). ZFS RAID отличается от обычного RAID тем, что при замене диска восстанавливаются только живые данные и метаданные, а не весь диск, включая пустые и мусорные блоки, что означает, что замена диска-члена в пуле ZFS, который только частично заполнен, займет пропорционально меньше времени. время по сравнению с обычным RAID.

Исторически, ZFS не поставлялась с такими инструментами, как fsck для восстановления поврежденных файловых систем, потому что сама файловая система была разработана для самовосстановления. ремонт, при условии, что он был построен с достаточным вниманием к конструкции хранения и избыточности данных. Если пул был скомпрометирован из-за плохого оборудования, несоответствующего дизайна или избыточности, или неудачной неудачи, до такой степени, что ZFS не могла смонтировать пул, традиционно не было инструментов, которые позволяли бы конечному пользователю попытаться частичное восстановление хранимых данных. Это привело к появлению тредов на онлайн-форумах, где разработчики ZFS иногда пытались предоставить специальную помощь домашним и другим мелким пользователям, сталкиваясь с потерей данных из-за их неадекватного дизайна или плохого управления системой.

Современная ZFS улучшилась. значительно в этой ситуации с течением времени, и продолжает делать это:

• Удаление или внезапный отказ кэширующих устройств больше не приводит к потере пула. (В худшем случае потеря ZIL может привести к потере очень недавних транзакций, но ZIL обычно не хранит более нескольких секунд последних транзакций. Потеря кэша L2ARC не влияет на данные.)
• Если пул является несмонтируемым, современные версии ZFS будут пытаться определить самую последнюю согласованную точку, в которой пул может быть восстановлен, за счет потери некоторых из самых последних изменений содержимого. Копировать при записи означает, что более старые версии данных, включая записи верхнего уровня и метаданные, могут все еще существовать, даже если они заменены, и если да, то пул можно вернуть в согласованное состояние на их основе. Чем старше данные, тем больше вероятность того, что по крайней мере некоторые блоки были перезаписаны и что некоторые данные будут безвозвратно восстановлены, поэтому в какой-то момент существует ограничение на возможность возврата пула.
• Неофициально, существуют инструменты, позволяющие выяснить причину, по которой ZFS не может смонтировать пул, и помочь пользователю или разработчику внести изменения вручную, необходимые для принудительного монтирования пула. К ним относятся использование zdb (отладка ZFS) для поиска допустимой импортируемой точки в пуле, использование dtrace или аналогичное для определения проблемы, вызывающей сбой при монтировании, или ручной обход проверок работоспособности, которые вызывают прерывание процесса монтирования, и позволяют монтировать поврежденный пул.
• По состоянию на март 2018 года в OpenZFS постепенно развертывается ряд значительно улучшенных методов. К ним относятся:

• рефакторинг кода и более подробная диагностическая и отладочная информация о сбоях монтирования для упрощения диагностики и устранения проблем с поврежденным пулом;
• Возможность доверять или не доверять сохраненной конфигурации пула. Это особенно эффективно, так как позволяет монтировать пул, даже если vdev верхнего уровня отсутствуют или неисправны, когда данные верхнего уровня являются подозрительными, а также выполнять перемотку за пределы изменения конфигурации пула, если это изменение было связано с проблемой. После того, как поврежденный пул смонтирован, читаемые файлы можно скопировать в целях безопасности, и может оказаться, что данные можно восстановить даже для отсутствующих vdev, используя копии, хранящиеся в другом месте в пуле.
• Возможность исправить ошибку ситуация, когда диск, необходимый в одном пуле, был случайно удален и добавлен в другой пул, что привело к потере метаданных, связанных с первым пулом, которые стали нечитаемыми.

Oracle Corporation прекратили публичная разработка ZFS и OpenSolaris после приобретения Sun в 2010. Некоторые разработчики выделили последний публичный выпуск OpenSolaris как проект Illumos. Из-за значительных преимуществ, представленных в ZFS, он был перенесен на несколько различных платформ с различными функциями и командами. Для координации усилий по разработке и предотвращения фрагментации в 2013 году была основана OpenZFS.

По словам Мэтта Аренса, одного из основных архитекторов ZFS, более 50% исходного кода OpenSolaris ZFS был заменен в OpenZFS на вклад сообщества с 2019 года, что сделало «Oracle ZFS» и «OpenZFS» политически и технологически несовместимыми.

Коммерческие продукты и продукты с открытым исходным кодом

• 2008: Sun поставила линейку основанных на ZFS Устройства хранения серии 7000.
• 2013: Oracle поставила серию файловых серверов ZS3 на основе ZFS и с одним из них заняла первое место в тесте.
• 2013: iXsystems поставляет устройства NAS на основе ZFS под названием FreeNAS для SOHO и TrueNAS для предприятий.
• 2014: Netgear поставляет линейка NAS-устройств на основе ZFS под названием ReadyDATA, предназначенных для использования на предприятии.
• 2015: анонсирует платформу облачного хранилища, которая позволяет клиентам предоставлять свои собственный zpool и импортировать d экспортироватьданные с помощью zfs send и zfs receive.

Oracle Corporation, закрытый источник и разветвление (с 2010 г.)

В январе 2010 г. Oracle Corporation приобрела Sun Microsystems и быстро прекратила поддержку дистрибутив OpenSolaris и модель разработки с открытым исходным кодом. В августе 2010 года Oracle прекратила предоставление общедоступных обновлений исходного кода ядра Solaris, фактически превратив Solaris 11 обратно в закрытую проприетарную операционную систему.

В В ответ на меняющийся ландшафт Solaris и OpenSolaris, проект illumos был запущен на веб-семинаре в четверг, 3 августа 2010 г., в результате усилий сообщества некоторых основных инженеров Solaris по продолжению разработки версия Solaris с открытым исходным кодом и завершение процесса получения тех частей с открытым исходным кодом, которые еще не были открыты Sun. illumos был основан как фонд, Illumos Foundation, зарегистрированный в штате Калифорния как торговая ассоциация 501 (c) 6. Первоначальный план явно заявлял, что illumos не будет дистрибутивом или форком. Однако после того, как Oracle объявила о прекращении поддержки OpenSolaris, были задуманы планы по созданию финальной версии ядра Solaris ON, которая позволила бы illumos развиться в собственное ядро. Таким образом, как часть OpenSolaris версия ZFS с открытым исходным кодом была неотъемлемой частью illumos.

ZFS широко использовалась на многих платформах, а также в Solaris. Поэтому в 2013 году координация работ по разработке версии ZFS с открытым исходным кодом была передана зонтичному проекту OpenZFS. Фреймворк OpenZFS позволяет любым заинтересованным сторонам совместно разрабатывать основную кодовую базу ZFS, индивидуально поддерживая любой конкретный дополнительный код, который требуется ZFS для работы и интеграции в их собственные системы.

Примечание. Версия Solaris, разрабатываемая Sun с момента выпуска Solaris 10 в 2005 году, имела кодовое название 'Nevada' и была получена из кодовой базы OpenSolaris. «Solaris Nevada» - это кодовое название ОС Solaris следующего поколения, которая в конечном итоге сменит Solaris 10, и этот новый код затем последовательно использовался в новых сборках моментальных снимков OpenSolaris «Nevada». OpenSolaris больше не поддерживается, и OpenIndiana разветвляется на. Окончательная сборка (b134) OpenSolaris была опубликована Oracle (12 ноября 2010 г.) как путь обновления до Solaris 11 Express.

Список операционных систем, поддерживающих ZFS

Список операционных систем, дистрибутивы и надстройки, поддерживающие ZFS, поддерживаемую им версию zpool и сборку Solaris, на которой они основаны (если есть):

• Сравнение файловых систем
• Список файловых систем
• Управление версиями файловой системы - Список версий файловых систем

• Fork Yeah! Возникновение и развитие иллюзий - слайд-шоу, охватывающее большую часть истории Solaris, решение Sun об открытии исходного кода, создание ZFS и события, которые привели к тому, что исходный код был закрыт и разветвлен после приобретения Oracle.
• Лучшая облачная файловая система была создана до того, как облако появилось
• Сравнение зеркалирования SVM и ZFS
• Распределение хранилища EON ZFS (NAS)
• Сквозная целостность данных для файловых систем: пример использования ZFS
• ZFS - Файловая система Zettabyte, заархивировано из оригинала 28 февраля 2013 г.
• ZFS и RAID-Z: Убер-FS?
• ZFS: Последнее слово в файловых системах, Джефф Бонвик и Билл Мур
• Визуализация журнала намерений ZFS (ZIL), апрель 2013 г., Аарон Топонсе
• Начало работы с ZFS, 15 сентября 2014 г., часть illumos documentation