ZFS

ZFS
ZFS
Разработчик	Oracle (ранее Sun Microsystems), OpenZFS[англ.] (разработчики форка)
Файловая система	ZFS
Дата представления	2005-11 (OpenSolaris)
Структура
Содержимое папок	Расширяемая хеш-таблица
Ограничения
Максимальный размер файла	16 эксбибайт
Максимум файлов	248
Максимальная длина имени файла	255 байт
Максимальный размер тома	256 зебибайт
Допустимые символы в названиях	без кодировки или UTF-8 (выбирается опцией)
Возможности
Точность хранения даты	1 нс
Потоки метаданных	Да (названные Extended Attributes (расширенные атрибуты))
Атрибуты	POSIX, дополнительные
Права доступа	POSIX
Фоновая компрессия	Да
Фоновое шифрование	Начиная с версии пула 30
Поддерживается ОС	Solaris, OpenSolaris, FreeBSD, Linux (через FUSE или отдельный модуль ядра (ZFS on Linux)), Apple Mac OS X 10.5, Windows (ZFSin)

ZFS — файловая система с деревом Меркла и поддержкой копирования при записи с функциями менеджера томов, созданная Sun Microsystems в 2004—2005 годах для операционной системы Solaris. Поддерживает большие объёмы данных, позволяет создавать RAID-массивы. Существуют открытые реализации ZFS, в частности, OpenZFS лицензируется под CDDL (в отличие от подобной ZFS файловой системы BTRFS, лицензируемой по GPL). По состоянию на 2024 год OpenZFS активно развивается.

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

История

ZFS была спроектирована и создана в Sun Microsystems командой во главе с Джефом Бонвиком (англ. Jeff Bonwick), анонсирована 14 сентября 2004 года^[2]. Исходный код для финального релиза был интегрирован в главную ветку разработки Solaris 31 октября 2005 года^[3].

ZFS вошла в 27 сборку OpenSolaris, выпущенную 16 ноября 2005 года. Sun заявила, что ZFS была интегрирована в 6/06 обновление для Solaris 10 в июне 2006 года, по прошествии одного года с момента открытия сообщества OpenSolaris^[4].

Первоначально ZFS называлась «Zettabyte File System», но позже название превратилось в простую аббревиатуру^[5].

ZFS была выпущена под коммерческой лицензией в составе операционной системы Solaris, затем SUN Microsystems открыла исходные коды ZFS в проекте OpenSolaris под лицензией CDDL. После приобретения SUN Microsystems компанией Oracle код снова был закрыт, однако к этому времени ZFS уже была включена в FreeBSD и другие проекты с открытыми лицензиями, которые вели разработку независимо и обменивались исходными кодами путём «обратного портирования» (англ. backports).

В 2013 году запущен проект OpenZFS^[англ.]^[6]^[7], в котором применяются новые возможности и исправления из Illumos и распространяются во все порты в другие платформы, и наоборот^[8].

Специфика

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

ZFS — 128-битная^{[источник не указан 3083 дня]}^[9] файловая система, что позволяет ей хранить в 18,4 × 10¹⁸ раз больше данных, чем все известные 64-битные системы. ZFS спроектирована так, чтобы её ограничения были настолько недостижимы, что в обозримом будущем не встретятся на практике^[10].

Некоторые теоретические пределы в ZFS:

2⁴⁸ — количество снимков в любой файловой системе (2 × 10¹⁴);
2⁴⁸ — количество файлов в любой индивидуальной файловой системе (2 × 10¹⁴);
256 зеттабайт (10²¹ байт)^{[источник не указан 3164 дня]} — максимальный размер файловой системы;
16 эксбибайт (2⁶⁴ байт) — максимальный размер одного файла;
16 эксбибайт (2⁶⁴ байт) — максимальный размер любого атрибута^[11];
3 × 10²³ петабайт^{[источник не указан 3164 дня]} — максимальный размер любого пула хранения (zpool);
2⁵⁶ — количество атрибутов файла (фактически ограничивается 2⁴⁸ на количество файлов в файловой системе ZFS);
2⁵⁶ — количество файлов в каталоге (реально ограничен 2⁴⁸ на количество файлов в файловой системе ZFS);
2⁶⁴ — количество устройств в любом пуле;
2⁶⁴ — количество пулов в системе;
2⁶⁴ — число файловых систем в одном пуле;
255 байт — максимальная длина имени файла (не полного имени, а относительно родительской папки);
255 байт — максимальная длина полного имени хранилища данных (файловой системы, тома, снимка, общего ресурса и т. д.).

При этом утилиты управления ФС накладывают дополнительные ограничения.

Пулы хранения

В отличие от традиционных файловых систем, которые располагаются на одном устройстве и, следовательно, при использовании более чем на одном устройстве для них требуется менеджер томов, ZFS строится поверх виртуальных пулов хранения данных, называемых zpool. Пул построен из виртуальных устройств (vdevs), каждое из которых является либо физическим устройством, либо зеркалом (RAID 1) одного или нескольких устройств, либо (RAID Z) — группой из двух или более устройств. Ёмкость всех vdevs затем доступна для всех файловых систем в zpool.

Для ограничения пространства, доступного конкретной файловой системе или тому, может быть установлена квота. Кроме того, возможно использование резервирования пространства хранения (лимита) — это гарантирует, что всегда будет оставаться некоторый доступный объём для конкретной файловой системы или тома.

Версии пула ZFS

Существуют различные версии файловой системы ZFS и версии пула ZFS (zpool), в зависимости от версии доступны различные функциональные возможности. По состоянию на ноябрь 2012 существует 34 версии пула ZFS. Все версии пула изначально выпускаются для Solaris.

В версии 2 была включена поддержка реплицируемых метаданных (англ. ditto blocks). Ввиду того, что структура формата ZFS древовидная, невосстановимые ошибки в метаданных пула могут привести к тому, что пул нельзя будет открыть. Данная функция предоставляет автоматическую репликацию метаданных (до трёх копий каждого блока) независимо от избыточности зависимых пулов (англ. underlying pool-wide redundancy). Например, в пуле с единственным зеркалом наиболее критичные метаданные будут трижды записаны на каждой стороне зеркала, в общей сложности шесть копий. Это позволяет удостовериться, что, если данные потеряны вследствие повреждения, все данные в пуле будут доступны для нахождения и пул будет работоспособным.

В версии 3 включена поддержка технологий горячего резерва и RAID-Z двойной чётности (raidz2); в версии 4 внедрена поддержка ведения истории пула ZFS (zpool history); в версии 5 добавлена поддержка сжатия на лету для наборов данных ZFS методом gzip; в версии 6 включена поддержка свойства bootfs (позволяет переключать корневую ФС загружаемой ОС через атрибут, помимо опции загрузчика).

В версии 7 реализована поддержка «целевого журнала» (ZFS Intent Log, ZIL, букв. «журнал намерений»), который предоставляет приложениям возможность узнать, что данные, ими изменённые, находятся в стабильном хранилище, по возврату из системного вызова. Целевой журнал хранит записи этих системных вызовов, они воспроизводятся заново, если произошёл сбой питания или критическая ошибка, при которой основной пул не подтвердил их выполнение. Когда целевой журнал находится вне основного пула, он выделяет блоки, которые идут цепочкой через пул.

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

В версии 9, в дополнение к существующим функциям квотирования и резервирования, добавлено назначение квот и резервов, не включающих потребление пространства хранения вложенными структурами данных, такими как клоны и квоты (zfs set refquota, zfs set refreservation). Резервирование автоматически устанавливается, когда созданный неразрежённый (non-sparse) том 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.^[12] Для данных могут быть выбраны и другие контрольные суммы. Блоки данных, содержащие активные (в этот момент) данные, никогда не перезаписываются вместе; напротив, выделяется новый блок, изменённые данные записываются в него, а затем — метаданные любых блоков, которые на него ссылаются, таким образом всё перераспределяется и записывается. Чтобы уменьшить накладные расходы, в этом процессе группируется несколько обновлений в группу транзакции, также, если требуется, ведётся журнал использования при синхронной записи.

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

Снимки и клоны

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

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

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

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

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

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

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

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

Различные размеры блока

ZFS использует переменный размер блоков до 1 мегабайта (с 32 версии пула, ранее было до 128 килобайт). Администратор может настраивать максимальный размер используемых блоков, но некоторые работы не будут выполняться (или будут выполняться с ошибками), если использовались слишком крупные блоки. Автоматические настройки рабочих характеристик соответствуют привилегиям^{[уточнить]}.

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

Пул ZFS также поддерживает различные размеры секторов устройств и автоматически выбирает наибольший размер блока из устройств, указанных при создании пула (после этого размер блока пула не может быть изменён). Стабильно поддерживаются размеры 512 байт, 4 КиБ (4K). Поддерживаются и блоки больших размеров, но ОС при этом может работать не стабильно.

Сквозной контроль целостности данных

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

При считывании любого блока подсчитывается его контрольная сумма и результат сравнивается с контрольной суммой. В случае расхождения ошибка сразу обнаруживается. Разумеется, если в пуле заранее не было запланировано никакого резервирования (ни RAID-Z, ни иного), то ошибку уже не исправить, но зато испорченные данные не будут выданы за истинные.

Смысл сквозного контроля целостности данных в том, чтобы предотвратить скрытую незаметную порчу данных в результате сбоя оборудования или встроенного программного обеспечения накопителей или контроллеров. Несмотря на то, что вероятность такого события кажется низкой, некоторые исследования показывают, что она вполне значима для организаций любого масштаба^[13].

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

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

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

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

Среди дополнительных возможностей — функция установки конкретного приоритета ввода-вывода со сроком планирования, поддержка нескольких независимых потоков с упреждением автоматического обнаружения длины и шага, интеллектуальная очистка и коррекция^[14], загрузка и совместное использование накопителей в пуле^[15], многократное воспроизведение метаданных^[16], поддержка механизма копирования при записи, возможность выбора загрузочной файловой системы в загрузчике ОС, установки основной загрузочной файловой системы, создания нескольких корневых файловых систем, из которых одна (со всеми дочерними) будет использоваться при загрузке ОС, возможность интеграции обновления программ и ОС с созданием снимков и клонов файловых систем, в которых хранятся программы, и использования этих снимков для лёгкого восстановления прежней версии, а клонов — для создания мультизагрузочной системы с возможностью загрузки разных конфигураций или версий ОС (Solaris по умолчанию так и обновляется), опция для ограничения имён файлов корректным текстом в UTF-8 в выбранной нормальной форме, опция нечувствительности к регистру символов в именах файлов.

Управление кэшем

ZFS также вводит адаптивную замену кеша (ARC), новый метод управления кэшем вместо традиционных для Solaris виртуальных страниц кэша в памяти.

Адаптивный порядок байт

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

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

Атрибуты пула

Атрибуты пула — это способ управления возможностями и настройками пула. Они имеют специальные типы и ограничения на запись. В них указывается, доступен ли пул на запись или на чтение, включена ли дедупликация данных, ФС для загрузки ОС по умолчанию, альтернативный корень для монтирования, характеристики пула и другое.

Системные атрибуты хранилищ данных

Системные атрибуты хранилищ — это способ управления возможностями и настройками хранилищ. Они имеют специальные типы и ограничения на запись. В них указываются настройки шифрования, сжатия, контрольных сумм, дедупликации, резервного копирования, кэширования, размер блоков хранения данных конкретных хранилищ. Также через них указывается размер томов, точки монтирования ФС, доступность отдельных хранилищ на запись, принадлежность хранилищ к зонам, мандатам, резервы, квоты, настройки автоматического создания сетевых общих ресурсов (NFS, SMB), права доступа к ним и другое. В этих атрибутах указываются характеристики хранилищ. Эти атрибуты упрощают управление функциями, связанными с ФС, но прежде выполняемых вручную (например, настройка монтирования нескольких дополнительных файловых систем, создание сетевых общих ресурсов).

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

Пользовательские атрибуты хранилищ данных

Каждому хранилищу данных (ФС, тому, снимку и др.) могут быть назначены пользовательские атрибуты. Пользовательские атрибуты отличаются от системных по именам. Для пользовательских атрибутов можно использовать любые имена (от 1 до 2¹⁰ байт), но рекомендуется использовать имена, содержащие двоеточие (для исключения конфликтов с системными атрибутами), имя своего домена перед этим двоеточием (для исключения с другими пользователями), имя атрибута после двоеточия. Пользовательские атрибуты наследуются дочерними хранилищами.

В связи с разветвлением разработки новых возможностей в разных ОС несколько таких атрибутов используется в качестве новых системных.

Пользовательские атрибуты используются пользователями и отдельными программами (например, программой автоматического создания и резервного копирования time-slider).

Системные атрибуты файлов

Для файлов любого типа может быть указано значение нескольких системных атрибутов.^[17] Эти атрибуты позволяют управлять действиями с файлом. Такие же системные атрибуты есть у расширенных атрибутов файлов.

Помимо атрибутов, хранящих даты создания, последнего доступа, последнего изменения, последнего изменения метаданных, есть атрибуты^[18]:

Название атрибута	Название атрибута в команде `chmod`^[19]	Назначение	Что делает ОС с этим атрибутом
Скрытый	`hidden`	Файлы с этим атрибутом не отображаются в общем списке, если эта опция включена и поддерживается в программе вывода файлов.	Ничего.
Разреженный	`sparse`	Файл с этим атрибутом рекомендуется обрабатывать как разреженный, то есть содержащий блоки нулевых байт, не хранимых на накопителе, а подразумеваемых. Этот атрибут рекомендательный и не связан с тем, является ли файл разреженным на самом деле. Программа обработки файлов для работы с разреженными файлами всё равно должна получать данные о разреженных блоках файла у ФС.	Ничего.
Системный	`system`	Файл с этим атрибутом предназначен для ОС, он не является пользовательским. Обычно не учитывается программами.	Ничего.
Только для чтения	`readonly`	Файл с этим атрибутом нельзя изменить (только данные, но не атрибуты). Распространяется на всех без исключений.	Блокирует доступ на запись, если атрибут установлен.
Для архивирования	`archive`	Файл требуется архивировать.	Ничего.
Неудаляемый	`nounlink`	Для каталогов: имя каталога и имена его непосредственных потомков нельзя удалить или изменить. Для остальных типов файлов: имя файла нельзя удалить или изменить.	Блокирует доступ на изменение имени и удаление, если атрибут установлен.
Неизменяемый	`immutable`	Файл с этим атрибутом нельзя изменить (данные, атрибуты, кроме этого самого атрибута и даты последнего доступа). Распространяется на всех без исключений.	Блокирует доступ на изменение, если атрибут установлен.
Только для дополнения	`appendonly`	Данные файла можно изменять, только дополняя, но нельзя перезаписывать.	Блокирует доступ на перезапись, если атрибут установлен.
Не для дампов	`nodump`	В Solaris не используется. Пришёл из BSD. Требует соответствующих привилегий для изменения.	В Solaris не используется.
В карантине антивируса	`av_quarantined`	Доступ к файлу ограничен до снятия карантина. Атрибут может быть установлен и снят только при наличии прав суперпользователя (есть у антивируса).	Блокирует доступ, если атрибут установлен.
Модифицирован (после последней проверки антивирусом)	`av_modified`	Сообщает, что текущая версия файла не проверена антивирусом. Устанавливается автоматически при создании файла и каждом изменении данных файла или размера файла. Может быть установлен пользователем с правами на изменение атрибутов. Может быть сброшен только при наличии прав суперпользователя (есть у антивируса).	Автоматически устанавливает атрибут при изменении данных, создании файла.

Расширенные атрибуты

Для каждого файла любого типа можно создавать расширенные атрибуты. Расширенный атрибут представляет собой именованный массив байт, как обычный файл. Для расширенных атрибутов, как и для обычных файлов, могут быть назначены собственные права доступа и системные атрибуты. В отличие от обычного файла, для расширенных атрибутов не могут быть созданы расширенные атрибуты, жёсткие ссылки. Для расширенных атрибутов файла доступна возможность ограниченно обращаться как к обычным файлам. Для этого для каждого файла создаётся безымянная папка (в момент создания первого расширенного атрибута), в которой доступны обычные файлы, соответствующие расширенным атрибутам этого файла. В Solaris в эту папку можно попасть с помощью утилиты runat^[20].

Делегирование полномочий пользователям

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

Сохранность и резервирование данных

За счёт техники копирования при записи данные в ZFS всегда в согласованном состоянии, файл не может потеряться в момент перезаписи.

При использовании томов с избыточностью (тома RAIDZ) обеспечивается сохранность данных при сбое физического носителя^[21], при этом RAIDZ эффективен для относительно длительного хранения больших файлов, особенно при задании соответствующего файлам размера блока, а при частой перезаписи и при размещении файлов маленьких размеров возникает повышенная нагрузка на процессор и подсистему ввода-вывода.

Ограничения

В реализации ZFS в Solaris 10 отсутствует прозрачное шифрование, как в Solaris 11 и NTFS, хотя существует его реализация в рамках проекта OpenSolaris^[22].

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

Расширение объёма хранения обычно достигается путём добавления группы накопителей, таких как vdev (stripe, RAID-Z, RAID-Z2 или зеркало). Новые данные будут динамически использовать все доступные vdev. Ещё одной возможностью увеличения пространства хранения является поочерёдная замена накопителей на более вместительные с ожиданием после каждой такой операции, пока ZFS сама себя восстановит. Время восстановления зависит от объёма сохранённой информации, а не от размеров накопителей. Если во время восстановления будет создан мгновенный снимок — это перезапустит процесс восстановления. Замена накопителей без потери данных возможна только в одном из режимов работы пула, это позволяющих.

Нет возможности уменьшить количество vdev, не уменьшив при этом размер пула, при этом ведутся работы по устранению этого ограничения. Также невозможно добавить новый накопитель в массив RAID-Z или RAID-Z2 (vdev). Данная функция является тяжёлой для внедрения. Однако вы можете создать RAIDZ vdev и добавить его в zpool.

Нельзя смешивать типы vdev в zpool.

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

ZFS не является изначально кластерной, распределённой или параллельной файловой системой и не предоставляет конкурирующего доступа к данным с различных хостов. ZFS — это локальная файловая система.

В реализации ZFS в Solaris 11 нельзя менять тип vdev в zpool. Например, если у вас есть ZFS-пул, содержащий блочные устройства, нет возможности скопировав содержимое блочных устройств в обычные файлы импортировать пул из этих файлов, и наоборот — перенести пул из обычных файлов на блочные устройства.

Удаление большого количества данных является медленной блокирующей операцией (в версии пула 37 и более ранних), например, удаление фрагментированной файловой системы размером в 100 ГиБ может занять более минуты и блокирует операции получения списка файловых систем и некоторых других действий с файловыми системами в том же пуле.

Нет возможности проконтролировать восстановление пула после восстановления доступа к разным копиям зеркалированного пула. Система сама решает, как восстановить пул, даже если в разные копии пула независимо вносились изменения (это разрешается).

Сильно повреждённый пул не может быть восстановлен и требует пересоздания. При этом, во многих случаях, пользовательские данные можно извлечь из повреждённого пула, импортировав его для чтения.

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

Платформы

Семейство Solaris

ZFS является частью операционной системы Solaris и доступна для обеих платформ — SPARC и x86. Поскольку код ZFS является открытым (лицензия CDDL), порты для других операционных систем и платформ могут производиться без участия Oracle.

OpenSolaris 2008.05 использует ZFS как файловую систему по умолчанию.

Nexenta OS — операционная система с GNU-окружением, построенная поверх ядра OpenSolaris и его среды выполнения, в версии alpha1 в её ядро была включена поддержка ZFS. Несколько позднее Nexenta Systems представила NexentaStor — систему для сетевого хранения с поддержкой ZFS, предоставляющую возможности NAS/SAN/iSCSI и базирующуюся на Nexenta OS. NexentaStor включает в себя графический интерфейс, который упрощает процесс использования ZFS. 2 декабря 2008 года выпущена версия NexentaStor 1.1. В ней обновлено ядро OpenSolaris, улучшена интеграция с CIFS/AD, а также добавлены несколько плагинов и исправлены некоторые ошибки. Имеется две редакции NexentaStor: коммерческая Enterprise Edition и бесплатная Community Edition с ограничением максимальной ёмкости хранилища в 18ТБ. По состоянию на август 2012 года, текущей версией ПО является 3.1.3.

Linux

Из-за лицензионных ограничений CDDL ZFS не включена в ядро, но доступна в виде модуля ядра, который присутствует во многих дистрибутивах Linux^[23].

Долгое время в Linux перенос ZFS на уровень ядра считался юридически невозможным из-за несовместимости лицензий CDDL, под юрисдикцией которой находится ZFS, и GNU GPL, под юрисдикцией которой находится Linux. Однако в мае 2010 года Брайан Белендорф представил новую версию проекта, в рамках которого ведётся работа по реализации встроенной поддержки файловой системы ZFS для Linux. Для обхода лицензионного ограничения Белендорф решил распространять свой продукт целиком под лицензией CDDL в виде отдельно загружаемого модуля, который поставляется отдельно от ядра^[24]^[25]. С марта 2013 года (версия 0.6.1) проект считается готовым к промышленному применению^[23]. Ubuntu 16.04 (64-битная версия) является первым из широко распространённых дистрибутивов Linux, готовым к использованию ZFS^[26].

Инициативная программа Google Summer of Code спонсирует адаптацию ZFS на Linux с использованием модуля FUSE, в котором файловая система ZFS работает в пользовательском пространстве^[27]. Считается, что это решение теоретически чревато потерями производительности^[28]. Но пример с реализацией NTFS (NTFS-3G) через FUSE показывает хорошую производительность по сравнению с другими системами^[29], что даёт основания прогнозировать приемлемую производительность ZFS-FUSE.

На конец 2012 года ZFS-FUSE^[30] представлена в виде версии 0.7.0, в которой включена практически полная поддержка ZFS и всех её функций — внедрена поддержка 23-й версии пула.

FreeBSD

Павел Давидек (Pawel Jakub Dawidek) адаптировал ZFS для FreeBSD в виде модуля для ядра системы. ZFS включена в версию FreeBSD 7.0 (вышла 27 февраля 2008)^[31].

Код ZFSv28 протестирован в версии FreeBSD 9 и портирован в стабильную ветку разработки версии 8. Релизы FreeBSD 8.3, 8.4 и 9.0 поддерживают 28-ю версию пула ZFS. Релиз FreeBSD 9.2 и более поздние версии FreeBSD используют новые возможности «feature flags», базирующиеся на реализации Пула версии 5000^[32].

Во FreeBSD, начиная с 8 версии, для работы ZFS, в отличие от Linux, не требуется наличия FUSE, и, следовательно, отсутствуют проблемы производительности, с этим связанные. Подтверждением этому является то, что ZFS в FreeBSD включена в ядро и присутствует в системе сразу, в числе прочего позволяя осуществить загрузку операционной системы с томов ZFS. А модуль FUSE не входит в операционную систему, и может быть при желании установлен дополнительно из коллекции портов^[33] (что требуется например для поддержки NTFS).

Mac OS X

Apple предпринимала попытку перенести ZFS на систему Mac OS X, велась активная дискуссия в списках рассылки ZFS и предварительные срезы для следующей версии Apple Mac OS X^[34]. Несмотря на то, что Mac OS X 10.5 (9A321) поддерживает ZFS, в ней отсутствует возможность использовать ZFS на корневых разделах, а также нет возможности форматировать локальные диски под ZFS (последнее считается багом^[35]).

В июне 2009 года Apple на своей пресс-конференции WWDC’09 отказалась от ZFS в представленной версии Mac OS X 10.6 Snow Leopard, в документации и материалах сайта были убраны все упоминания о ZFS. Компания не раскрывает причины отказа от использования ZFS^[36].

Хотя в сборке Mac OS X 10.6 Snow Leopard под номером 10A432, помеченной как Golden Master, поддержка ZFS была возвращена, в окончательном релизе Mac OS X 10.6 поддержка ZFS вновь убрана, уже окончательно^[37].

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

Redox

Операционная система Redox планировала использовать ZFS как файловую систему по умолчанию, однако позже перешла на собственную реализацию сходных принципов — TFS^[38]^[39], написанную на основном языке Redox — Rust.

Примечания

↑ zfs/zfs_vnops.c at 12fa7f3436fbd89f4d6b00c2c076405e7a21d62f · zfsonlinux/zfs · GitHub + zfs/zfs_znode.h at 25458cbef9e59ef9ee6a7e729ab2522ed308f88f · zfsonlinux/zfs · GitHub + zfs/zfs_vfsops.c at 25458cbef9e59ef9ee6a7e729ab2522ed308f88f · zfsonlinux/zfs · GitHub
↑ ZFS: the last word in file systems (ZFS: последнее слово в файловых системах) (неопр.). Sun Microsystems (14 сентября 2004). Дата обращения: 30 апреля 2006. Архивировано 4 июня 2012 года.
↑ Jeff Bonwick. ZFS: The Last Word in Filesystems (неопр.). Jeff Bonwick's Blog (31 октября 2005). Дата обращения: 30 апреля 2006. Архивировано 13 октября 2012 года.
↑ Sun Celebrates Successful One-Year Anniversary of OpenSolaris (Sun празднует успешную первую годовщину OpenSolaris) (неопр.). Sun Microsystems (20 июня 2006). Архивировано 13 октября 2012 года.
↑ Jeff Bonwick. You say zeta, I say zetta (Ты скажешь zeta, я скажу zetta) (неопр.). Jeff Bonwick's Blog (4 мая 2006). Дата обращения: 8 сентября 2006. Архивировано 13 октября 2012 года.
↑ The OpenZFS project launches (неопр.). LWN.net (17 сентября 2013). Дата обращения: 1 октября 2013. Архивировано 11 октября 2016 года.
↑ OpenZFS Announcement (неопр.). OpenZFS (17 сентября 2013). Дата обращения: 19 сентября 2013. Архивировано 2 апреля 2018 года.
↑ OpenZFS History (неопр.). OpenZFS. Дата обращения: 24 сентября 2013. Архивировано 24 декабря 2013 года.
↑ Простейшая проверка показывает, что в текущей реализации более 16 ЭиБ пул не может использовать. Эту проверку легко провести самостоятельно, так как устройства по 8 ЭиБ предоставляет сама ZFS хоть сотнями на реальный гигабайт места при использовании сжатия.
↑ Как заявил руководитель проекта Бонвик, «заполнение 128-битных файловых систем превысит квантовые возможности хранения данных на Земле. Вы не сможете заполнить и хранить 128-битный объём, не вскипятив при этом океан.» Пример того, насколько велики эти числа: если создавать 1000 файлов каждую секунду, для достижения предела количества файлов в ZFS потребуется около 9000 лет. Расчёт показывает, что требуемое время составляет 8925,5129601298833079654997463217 лет без учёта изменения угловой скорости записи на диск и других издержек. В ответ на вопрос о заполнении ZFS без кипячения океанов, Бонвик пишет: «Хотя мы все хотели бы, чтобы Закон Мура выполнялся бесконечно долго, квантовая механика накладывает некоторые фундаментальные ограничения на скорость вычислений и информационную вместимость любого физического устройства. В частности, было показано, что 1 килограмм материи, ограниченный 1 литром пространства, может выполнять не более 10⁵¹ операций в секунду над не более чем 10³¹ бит информации [см. Seth Lloyd, „Ultimate physical limits to computation Архивировано 7 августа 2008 года..“ Nature 406, 1047—1054 (2000)]. Целиком заполненный 128-битный объём будет содержать 2¹²⁸ блоков = 2¹³⁷ байт = 2¹⁴⁰ бит; поэтому минимальная масса, необходимая для хранения этого количества бит, будет (2¹⁴⁰ бит) / (10³¹ бит/кг) = 136 млрд кг.»
↑ На атрибуты, используемые ОС, накладываются дополнительные ограничения, например, размер атрибута ФС для списка доступа по NFS в Solaris ограничен примерно 10⁴ байт, что соответствует от 2000 до 20 пользователей в зависимости от длин логинов и хостов.
↑ ZFS On-Disk Specification (неопр.). Sun Microsystems, Inc.. Архивировано из оригинала 28 октября 2015 года. См. главу 2.4.
↑ Data integrity (неопр.). доклад CERN (8 апреля 2007). Дата обращения: 28 января 2008. Архивировано 13 октября 2012 года.
↑ Smokin' Mirrors (неопр.). Блог Jeff'a Bonwick'a (2 мая 2006). Дата обращения: 23 февраля 2007. Архивировано 13 октября 2012 года.
↑ Распределение блоков ZFS (неопр.). Jeff Bonwick's blog (4 ноября 2006). Дата обращения: 23 февраля 2007. Архивировано 13 октября 2012 года.
↑ Те же блоки - Удивительная репелент лента (неопр.). Flippin' off bits Weblog (12 мая 2006). Дата обращения: 1 марта 2007. Архивировано 13 октября 2012 года.
↑ Synopsis — man pages section 1: User Commands (неопр.). Дата обращения: 13 января 2016. Архивировано 24 октября 2016 года.
↑ Synopsis - man pages section 3: Basic Library Functions: fgetattr, fsetattr, getattrat, setattrat - get and set system attributes (неопр.). Дата обращения: 13 марта 2016. Архивировано 11 октября 2016 года.
↑ Synopsis - man pages section 1: User Commands: chmod - change the permissions mode of a file (неопр.). Дата обращения: 13 марта 2016. Архивировано 25 марта 2016 года.
↑ Synopsis — man pages section 1: User Commands (неопр.). Дата обращения: 13 января 2016. Архивировано 2 февраля 2017 года.
↑ Ahrens, 2014.
↑ Проект OpenSolaris: Поддержка шифрования дисков в ZFS. (неопр.) Проект OpenSolaris. Дата обращения: 11 июля 2008. Архивировано 13 октября 2012 года.
↑ ¹ ² Neil McAllister. Production-ready ZFS offers cosmic-scale storage for Linux. Über-reliable filesystem now ready for wide deployment (англ.). The Register (30 марта 2013). Дата обращения: 30 марта 2013. Архивировано 4 апреля 2013 года.
↑ Для Linux доступна нативная поддержка файловой системы ZFS : [арх. 29 мая 2010] // OpenNET. — 2010. — 27 мая.
↑ Matt Ahrens, Brian Behlendorf. OpenZFS on Linux (англ.). LinuxCon 2013 (17 сентября 2013). Дата обращения: 25 декабря 2013. Архивировано из оригинала 13 ноября 2013 года.
↑ Ben Everard. Ubuntu 16.04 It’s back — and it’s brilliant. Linux Voice, issue 27, June 2016
↑ Ricardo Correia. Announcing ZFS on FUSE/Linux (неопр.) (26 мая 2006). Дата обращения: 15 июля 2006. Архивировано 13 октября 2012 года.
↑ Реализация файловой системы на уровне задач пользовательского пространства может нести в себе дополнительные затраты, к примеру переключение контекста. Но такая реализация является основой целой теории микроядерных систем и отличается бо́льшей надёжностью по сравнению с реализацией внутри ядра.
↑ Szabolcs Szakacsits. NTFS-3G Read/Write Driver Performance (неопр.) (28 ноября 2007). Дата обращения: 20 января 2008. Архивировано 4 января 2007 года.
↑ ZFS for Linux 0.7.0 (неопр.). Дата обращения: 7 ноября 2012. Архивировано 20 ноября 2012 года.
↑ Dawidek, Pawel ZFS committed to the FreeBSD base (неопр.) (6 апреля 2007). Дата обращения: 6 апреля 2007. Архивировано 13 октября 2012 года.
↑ FreeBSD 9.2-RELEASE Release Notes (неопр.). FreeBSD. Дата обращения: 30 сентября 2013. Архивировано 3 октября 2013 года.
↑ коллекция портов FreeBSD (неопр.). Дата обращения: 21 апреля 2015. Архивировано 19 апреля 2015 года.
↑ Портирование ZFS в OSX (неопр.). zfs-дискуссии (27 апреля 2006). Дата обращения: 30 апреля 2006. Архивировано 13 октября 2012 года.
↑ Mac OS X 10.5 9A326 Seeded (неопр.). InsanelyMac Forums (14 декабря 2006). Дата обращения: 14 декабря 2006. Архивировано 13 октября 2012 года.
↑ Linux.Org.Ru (неопр.). InsanelyMac Forums (11 июня 2009). Дата обращения: 11 июня 2009. Архивировано 13 октября 2012 года.
↑ Robin Harris - Apple kicks ZFS in the butt (неопр.). Дата обращения: 2 сентября 2009. Архивировано 2 сентября 2009 года.
↑ https://github.com/redox-os/tfs Архивная копия от 26 октября 2018 на Wayback Machine «TFS was created out of the need for a modern file system for Redox OS, as a replacement for ZFS, which proved to be slow to implement because of its monolithic design.»
↑ https://www.phoronix.com/scan.php?page=news_item&px=TFS-File-System-Rust-ZFS Архивная копия от 18 октября 2018 на Wayback Machine, https://www.phoronix.com/scan.php?page=news_item&px=Redox-OS-2016-State Архивная копия от 18 октября 2018 на Wayback Machine

Ссылки

Руководство по администрированию файловых систем ZFS Solaris
ZFS в Linux
Сообщество разработчиков ZFS и детальная информация о файловой системе (англ.)
Практическое руководство по ZFS (англ.)
Ahrens M. ZFS RAIDZ stripe width, or: How I Learned to Stop Worrying and Love RAIDZ : [англ.] : [арх. 20 ноября 2020] / Matthew Ahrens // Delphix. — 2014. — 5 June.

Порты

ZFS через FUSE — Wizy Wiki (англ.)
Linux: ZFS, Licenses and Patents (англ.)

Обзоры и информация

ZFS Uncovered (англ.) — обзор файловой системы ZFS.
ZFS (рус.) на Xgu.ru

[1] zfs/zfs_vnops.c at 12fa7f3436fbd89f4d6b00c2c076405e7a21d62f · zfsonlinux/zfs · GitHub + zfs/zfs_znode.h at 25458cbef9e59ef9ee6a7e729ab2522ed308f88f · zfsonlinux/zfs · GitHub + zfs/zfs_vfsops.c at 25458cbef9e59ef9ee6a7e729ab2522ed308f88f · zfsonlinux/zfs · GitHub

[announce-2] ZFS: the last word in file systems (ZFS: последнее слово в файловых системах) (неопр.). Sun Microsystems (14 сентября 2004). Дата обращения: 30 апреля 2006. Архивировано 4 июня 2012 года.

[3] Jeff Bonwick. ZFS: The Last Word in Filesystems (неопр.). Jeff Bonwick's Blog (31 октября 2005). Дата обращения: 30 апреля 2006. Архивировано 13 октября 2012 года.

[4] Sun Celebrates Successful One-Year Anniversary of OpenSolaris (Sun празднует успешную первую годовщину OpenSolaris) (неопр.). Sun Microsystems (20 июня 2006). Архивировано 13 октября 2012 года.

[5] Jeff Bonwick. You say zeta, I say zetta (Ты скажешь zeta, я скажу zetta) (неопр.). Jeff Bonwick's Blog (4 мая 2006). Дата обращения: 8 сентября 2006. Архивировано 13 октября 2012 года.

[lwn-567090-6] The OpenZFS project launches (неопр.). LWN.net (17 сентября 2013). Дата обращения: 1 октября 2013. Архивировано 11 октября 2016 года.

[openzfs-announcement-7] OpenZFS Announcement (неопр.). OpenZFS (17 сентября 2013). Дата обращения: 19 сентября 2013. Архивировано 2 апреля 2018 года.

[openzfs-history-8] OpenZFS History (неопр.). OpenZFS. Дата обращения: 24 сентября 2013. Архивировано 24 декабря 2013 года.

[128-бит-9] Простейшая проверка показывает, что в текущей реализации более 16 ЭиБ пул не может использовать. Эту проверку легко провести самостоятельно, так как устройства по 8 ЭиБ предоставляет сама ZFS хоть сотнями на реальный гигабайт места при использовании сжатия.

[10] Как заявил руководитель проекта Бонвик, «заполнение 128-битных файловых систем превысит квантовые возможности хранения данных на Земле. Вы не сможете заполнить и хранить 128-битный объём, не вскипятив при этом океан.» Пример того, насколько велики эти числа: если создавать 1000 файлов каждую секунду, для достижения предела количества файлов в ZFS потребуется около 9000 лет. Расчёт показывает, что требуемое время составляет 8925,5129601298833079654997463217 лет без учёта изменения угловой скорости записи на диск и других издержек. В ответ на вопрос о заполнении ZFS без кипячения океанов, Бонвик пишет: «Хотя мы все хотели бы, чтобы Закон Мура выполнялся бесконечно долго, квантовая механика накладывает некоторые фундаментальные ограничения на скорость вычислений и информационную вместимость любого физического устройства. В частности, было показано, что 1 килограмм материи, ограниченный 1 литром пространства, может выполнять не более 10⁵¹ операций в секунду над не более чем 10³¹ бит информации [см. Seth Lloyd, „Ultimate physical limits to computation Архивировано 7 августа 2008 года..“ Nature 406, 1047—1054 (2000)]. Целиком заполненный 128-битный объём будет содержать 2¹²⁸ блоков = 2¹³⁷ байт = 2¹⁴⁰ бит; поэтому минимальная масса, необходимая для хранения этого количества бит, будет (2¹⁴⁰ бит) / (10³¹ бит/кг) = 136 млрд кг.»

[11] На атрибуты, используемые ОС, накладываются дополнительные ограничения, например, размер атрибута ФС для списка доступа по NFS в Solaris ограничен примерно 10⁴ байт, что соответствует от 2000 до 20 пользователей в зависимости от длин логинов и хостов.

[12] ZFS On-Disk Specification (неопр.). Sun Microsystems, Inc.. Архивировано из оригинала 28 октября 2015 года. См. главу 2.4.

[13] Data integrity (неопр.). доклад CERN (8 апреля 2007). Дата обращения: 28 января 2008. Архивировано 13 октября 2012 года.

[14] Smokin' Mirrors (неопр.). Блог Jeff'a Bonwick'a (2 мая 2006). Дата обращения: 23 февраля 2007. Архивировано 13 октября 2012 года.

[15] Распределение блоков ZFS (неопр.). Jeff Bonwick's blog (4 ноября 2006). Дата обращения: 23 февраля 2007. Архивировано 13 октября 2012 года.

[16] Те же блоки - Удивительная репелент лента (неопр.). Flippin' off bits Weblog (12 мая 2006). Дата обращения: 1 марта 2007. Архивировано 13 октября 2012 года.

[17] Synopsis — man pages section 1: User Commands (неопр.). Дата обращения: 13 января 2016. Архивировано 24 октября 2016 года.

[18] Synopsis - man pages section 3: Basic Library Functions: fgetattr, fsetattr, getattrat, setattrat - get and set system attributes (неопр.). Дата обращения: 13 марта 2016. Архивировано 11 октября 2016 года.

[19] Synopsis - man pages section 1: User Commands: chmod - change the permissions mode of a file (неопр.). Дата обращения: 13 марта 2016. Архивировано 25 марта 2016 года.

[20] Synopsis — man pages section 1: User Commands (неопр.). Дата обращения: 13 января 2016. Архивировано 2 февраля 2017 года.

[_a7f4d4e148d5f483-21] Ahrens, 2014.

[Шифрование-22] Проект OpenSolaris: Поддержка шифрования дисков в ZFS. (неопр.) Проект OpenSolaris. Дата обращения: 11 июля 2008. Архивировано 13 октября 2012 года.

[McAllister,_2013-23] ¹ ² Neil McAllister. Production-ready ZFS offers cosmic-scale storage for Linux. Über-reliable filesystem now ready for wide deployment (англ.). The Register (30 марта 2013). Дата обращения: 30 марта 2013. Архивировано 4 апреля 2013 года.

[Opennet-24] Для Linux доступна нативная поддержка файловой системы ZFS : [арх. 29 мая 2010] // OpenNET. — 2010. — 27 мая.

[25] Matt Ahrens, Brian Behlendorf. OpenZFS on Linux (англ.). LinuxCon 2013 (17 сентября 2013). Дата обращения: 25 декабря 2013. Архивировано из оригинала 13 ноября 2013 года.

[26] Ben Everard. Ubuntu 16.04 It’s back — and it’s brilliant. Linux Voice, issue 27, June 2016

[fuse-announce-27] Ricardo Correia. Announcing ZFS on FUSE/Linux (неопр.) (26 мая 2006). Дата обращения: 15 июля 2006. Архивировано 13 октября 2012 года.

[28] Реализация файловой системы на уровне задач пользовательского пространства может нести в себе дополнительные затраты, к примеру переключение контекста. Но такая реализация является основой целой теории микроядерных систем и отличается бо́льшей надёжностью по сравнению с реализацией внутри ядра.

[ntfsperformance-29] Szabolcs Szakacsits. NTFS-3G Read/Write Driver Performance (неопр.) (28 ноября 2007). Дата обращения: 20 января 2008. Архивировано 4 января 2007 года.

[fuse-web-30] ZFS for Linux 0.7.0 (неопр.). Дата обращения: 7 ноября 2012. Архивировано 20 ноября 2012 года.

[fbsd-31] Dawidek, Pawel ZFS committed to the FreeBSD base (неопр.) (6 апреля 2007). Дата обращения: 6 апреля 2007. Архивировано 13 октября 2012 года.

[32] FreeBSD 9.2-RELEASE Release Notes (неопр.). FreeBSD. Дата обращения: 30 сентября 2013. Архивировано 3 октября 2013 года.

[33] коллекция портов FreeBSD (неопр.). Дата обращения: 21 апреля 2015. Архивировано 19 апреля 2015 года.

[34] Портирование ZFS в OSX (неопр.). zfs-дискуссии (27 апреля 2006). Дата обращения: 30 апреля 2006. Архивировано 13 октября 2012 года.

[35] Mac OS X 10.5 9A326 Seeded (неопр.). InsanelyMac Forums (14 декабря 2006). Дата обращения: 14 декабря 2006. Архивировано 13 октября 2012 года.

[36] Linux.Org.Ru (неопр.). InsanelyMac Forums (11 июня 2009). Дата обращения: 11 июня 2009. Архивировано 13 октября 2012 года.

[37] Robin Harris - Apple kicks ZFS in the butt (неопр.). Дата обращения: 2 сентября 2009. Архивировано 2 сентября 2009 года.

[38] ttps://github.com/redox-os/tfs Архивная копия от 26 октября 2018 на Wayback Machine «TFS was created out of the need for a modern file system for Redox OS, as a replacement for ZFS, which proved to be slow to implement because of its monolithic design.»

[39] ttps://www.phoronix.com/scan.php?page=news_item&px=TFS-File-System-Rust-ZFS Архивная копия от 18 октября 2018 на Wayback Machine, https://www.phoronix.com/scan.php?page=news_item&px=Redox-OS-2016-State Архивная копия от 18 октября 2018 на Wayback Machine

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]