✖


Jump to content

ZFS

Чтобы узнать о других значениях, см. ZFS (значения) .

ZFS
Разработчик(и) Sun Microsystems Первоначально , Oracle Corporation с 2010 г., OpenZFS с 2013 г.
Варианты Oracle ZFS , OpenZFS
Представлено ноябрь 2005 г .; 18 лет назад ( 2005-11 ) с OpenSolaris
Структуры
Содержимое каталога Расширяемая хеш-таблица
Пределы
Максимальный размер тома 256 триллионов йобибайт (2 128 байты) [1]
Максимальный размер файла 16 эксбибайт (2 64 байты)
Макс нет. файлов
  • В каталоге: 2 48
  • На файловую систему: неограниченно [1]
Максимальная длина имени файла 255 символов ASCII (меньше для стандартов многобайтовых символов, таких как Unicode )
Функции
Вилки Да (так называемые «расширенные атрибуты», но это полноценные потоки)
Атрибуты POSIX , расширенные атрибуты
Файловая система
разрешения 		Разрешения Unix, списки ACL NFSv4
Прозрачный
сжатие 		Да
Прозрачный
шифрование 		Да
Дедупликация данных Да
Копирование при записи Да
Другой
Поддерживается
операционные системы

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

Обзор

[ редактировать ]

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

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

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

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

История

[ редактировать ]
См. также: Solaris (операционная система) , OpenSolaris , OpenIndiana , illumos и Sun Microsystems.

2004–2010: Разработка в Sun Microsystems.

[ редактировать ]

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

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

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

В какой-то момент это название означало «Файловая система Zettabyte». [19] но к 2006 году это имя больше не считалось аббревиатурой. [20] Файловая система ZFS может хранить до 256 квадриллионов зеттабайт (ЗБ).

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

2010-по настоящее время: Разработка в Oracle, OpenZFS.

[ редактировать ]
Основные статьи: Oracle ZFS § History и OpenZFS § History.

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

Функции

[ редактировать ]

Краткое содержание

[ редактировать ]

Примеры функций, специфичных для ZFS, включают:

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

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

[ редактировать ]
См. также: Частота ошибок жесткого диска и их обработка и Тихое повреждение данных.

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

Исследование 1999 года показало, что ни одна из основных и распространенных на тот момент файловых систем (таких как UFS , Ext , [22] XFS , JFS или NTFS ), а также аппаратный RAID (который имеет некоторые проблемы с целостностью данных ) не обеспечивали достаточную защиту от проблем с повреждением данных. [23] [24] [25] [26] Первоначальные исследования показывают, что ZFS защищает данные лучше, чем предыдущие попытки. [27] [28] Это также быстрее, чем UFS. [29] [30] и может рассматриваться как его замена.

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

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

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

Если копий поврежденных данных нет, ZFS переводит пул в состояние сбоя. [34] предотвращение его использования в будущем и отсутствие документированных способов восстановления содержимого пула.

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

RAID («РАИД-З»)

[ редактировать ]

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

Избегание аппаратных RAID-контроллеров

[ редактировать ]

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

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

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

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

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

[ редактировать ]

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

RAID-Z — это схема распределения данных/четности, подобная RAID-5 , но использует динамическую ширину полосы: каждый блок представляет собой собственную полосу RAID, независимо от размера блока, в результате чего каждая запись RAID-Z является записью полной полосы. В сочетании с транзакционной семантикой ZFS копирования при записи это устраняет ошибку записи . RAID-Z также быстрее традиционного RAID 5, поскольку ему не требуется выполнять обычную последовательность чтения-изменения-записи . [37]

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

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

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

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

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

Восстановление серебра и очистка (синхронизация массива и проверка целостности)

[ редактировать ]

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

  • fsck должен быть запущен в автономной файловой системе, что означает, что файловая система должна быть отключена и не может быть использована во время восстановления, тогда как Scrub предназначен для использования в смонтированной, работающей файловой системе и не требует отключения файловой системы ZFS.
  • fsck обычно проверяет только метаданные (например, журнал журнала), но никогда не проверяет сами данные. Это означает, что после fsck данные все равно могут не соответствовать исходным сохраненным данным.
  • fsck не всегда может проверить и восстановить данные, когда контрольные суммы хранятся вместе с данными (часто это происходит во многих файловых системах), поскольку контрольные суммы также могут быть повреждены или нечитабельны. ZFS всегда хранит контрольные суммы отдельно от данных, которые они проверяют, что повышает надежность и возможность очистки тома. ZFS также хранит несколько копий данных — метаданные, в частности, могут иметь более 4 или 6 копий (несколько копий на диск и несколько зеркал дисков на том), что значительно улучшает способность очистки обнаруживать и устранять значительные повреждения тома. по сравнению с ФСК.
  • Scrub проверяет все, включая метаданные и данные. Эффект можно наблюдать, сравнивая время fsck со временем очистки — иногда fsck на большом RAID завершается за несколько минут, что означает, что проверялись только метаданные. Обход всех метаданных и данных на большом RAID занимает много часов, и именно это и делает скраб.
  • в то время как fsck обнаруживает и пытается исправить ошибки, используя доступные данные файловой системы, Scrub полагается на избыточность для восстановления после проблем. В то время как fsck предлагает исправить файловую систему с частичной потерей данных, Scrub переводит ее в неисправное состояние, если нет избыточности. [34]

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

Емкость

[ редактировать ]

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

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

  • 16 эксбибайт (2 64 байты): максимальный размер одного файла
  • 2 48 : количество записей в любом отдельном каталоге [46]
  • 16 эксбибайт: максимальный размер любого атрибута.
  • 2 56 : количество атрибутов файла (фактически ограничено 2 48 для количества файлов в каталоге)
  • 256 квадриллионов зебибайт (2 128 байты): максимальный размер любого zpool
  • 2 64 : количество устройств в любом zpool
  • 2 64 : количество файловых систем в zpool
  • 2 64 : количество zpools в системе

Шифрование

[ редактировать ]

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

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

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

[ редактировать ]

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

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

Другие особенности

[ редактировать ]

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

[ редактировать ]

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

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

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

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

[ редактировать ]

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

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

 Где хранится Чтение кэша Запись кэша
Кэш первого уровня В оперативной памяти Известен как ARC из-за использования варианта алгоритма адаптивного кэша замены (ARC). ОЗУ всегда будет использоваться для кэширования, поэтому этот уровень всегда присутствует. Эффективность алгоритма ARC означает , что доступ к дискам часто не требуется, если размер ARC достаточно велик. Если ОЗУ слишком мало, ARC вообще не будет; в этом случае ZFS всегда требуется доступ к базовым дискам, что значительно влияет на производительность. Обрабатывается с помощью «групп транзакций» — записи сопоставляются в течение короткого периода (обычно 5–30 секунд) до заданного предела, при этом каждая группа в идеале записывается на диск, пока сопоставляется следующая группа. Это позволяет более эффективно организовать запись на базовые диски с риском незначительной потери данных самых последних транзакций в случае сбоя питания или аппаратного сбоя. На практике риск потери мощности предотвращается за счет ведения журнала записи ZFS и пула кэша записи второго уровня SLOG/ZIL (см. ниже), поэтому записи будут потеряны только в том случае, если сбой записи произойдет одновременно с полной потерей второго уровня. пул SLOG уровня, и то только в том случае, если настройки, связанные с синхронной записью и использованием SLOG, установлены таким образом, который допускает возникновение такой ситуации. Если данные принимаются быстрее, чем они могут быть записаны, получение данных приостанавливается до тех пор, пока диски не смогут их догнать.
Кэш второго уровня и журнал намерений На быстрых устройствах хранения (которые можно добавлять или удалять из «живой» системы без сбоев в текущих версиях ZFS, хотя и не всегда в более старых версиях) Известен как L2ARC («ARC уровня 2»), необязательно. ZFS будет кэшировать в L2ARC как можно больше данных, которые могут составлять десятки или сотни гигабайт во многих случаях . L2ARC также значительно ускорит дедупликацию , если всю таблицу дедупликации можно кэшировать в L2ARC. Полное заполнение пустого L2ARC может занять несколько часов (прежде чем ZFS решит, какие данные являются «горячими» и должны быть кэшированы). Если устройство L2ARC потеряно, все операции чтения уйдут на диски, что снизит производительность, но больше ничего не произойдет (данные не будут потеряны). Известный как SLOG или ZIL («Журнал намерений ZFS») — эти термины часто используются неправильно. SLOG (вторичное устройство журнала) — это дополнительный выделенный кэш на отдельном устройстве для записи записей в случае системной проблемы. Если устройство SLOG существует, оно будет использоваться для журнала намерений ZFS в качестве журнала второго уровня, а если отдельное устройство кэширования не предусмотрено, вместо этого на основных устройствах хранения будет создан ZIL. Таким образом, технически SLOG относится к выделенному диску, на который выгружается ZIL, чтобы ускорить работу пула. Строго говоря, ZFS не использует устройство SLOG для кэширования операций записи на диск. Скорее, он использует SLOG, чтобы гарантировать, что записи будут зафиксированы на постоянном носителе как можно быстрее, чтобы в случае сбоя питания или сбоя записи никакие данные, которые были признаны записанными, не были потеряны. Устройство SLOG позволяет ZFS быстро сохранять записи и быстро сообщать о них как о записанных даже для таких устройств хранения, как жесткие диски , которые работают намного медленнее. В ходе обычной деятельности к SLOG никогда не обращаются и не читают его, а также он не действует как кэш; его цель – защитить данные в полете в течение нескольких секунд, затраченных на сопоставление и «запись», на случай, если в конечном итоге запись не удастся. Если все пойдет хорошо, то пул носителей будет обновлен в какой-то момент в течение следующих 5–60 секунд, когда текущая группа транзакций будет записана на диск (см. выше), после чего сохраненные записи в SLOG будут просто уничтожены. игнорируется и перезаписывается. Если запись в конечном итоге завершается неудачно, или в системе происходит сбой или ошибка, препятствующая ее записи, тогда ZFS может идентифицировать все записи, которые, как она подтвердила, были записаны, путем обратного чтения SLOG (единственный раз, когда он читается), и использовать это чтобы полностью восстановить потерю данных.

Это становится критически важным, если происходит большое количество синхронных записей (например, с ESXi , NFS и некоторыми базами данных ), [53] когда клиент требует подтверждения успешного написания перед продолжением своей деятельности; SLOG позволяет ZFS гораздо быстрее подтверждать успешность записи, чем если бы ему приходилось каждый раз записывать в основное хранилище, без риска ввести клиента в заблуждение относительно состояния хранилища данных. Если устройства SLOG нет, то для той же цели будет использоваться часть основного пула данных, хотя это и медленнее.

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

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

Специальный класс ВДЕВ
[ редактировать ]

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

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

[ редактировать ]

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

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

[ редактировать ]

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

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

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

[ редактировать ]

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

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

[ редактировать ]

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

Переменные размеры блоков

[ редактировать ]

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

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

[ редактировать ]

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

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

[ редактировать ]

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

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

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

[ редактировать ]

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

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

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

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

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

[ редактировать ]
  • Явный приоритет ввода-вывода с планированием сроков. [ нужна ссылка ]
  • Заявлена ​​глобально оптимальная сортировка и агрегирование ввода-вывода. [ нужна ссылка ]
  • Несколько независимых потоков предварительной выборки с автоматическим определением длины и шага. [ нужна ссылка ]
  • Параллельные операции с каталогами в постоянном времени. [ нужна ссылка ]
  • Сквозное контрольное суммирование с использованием своего рода « поля целостности данных », позволяющего обнаруживать повреждение данных (и восстанавливать их, если в пуле есть избыточность). На выбор можно использовать 3 хеша, оптимизированные по скорости (fletcher), стандартизации и безопасности ( SHA256 ) и соленые хеши ( Skein ). [65]
  • Прозрачное сжатие файловой системы. Поддерживает LZJB , gzip , [66] LZ4 и Зстд .
  • Интеллектуальная очистка и восстановление серебра (повторная синхронизация). [67]
  • Распределение нагрузки и пространства между дисками в пуле. [68]
  • То же самое с блоками: настраиваемая репликация данных для каждой файловой системы, с нулем, одной или двумя дополнительными копиями, запрашиваемыми на запись для пользовательских данных, и с тем же базовым числом копий плюс одна или две для метаданных (в зависимости от важности метаданных). [69] Если в пуле несколько устройств, ZFS пытается выполнить репликацию на разные устройства. Блоки Ditto — это прежде всего дополнительная защита от поврежденных секторов, а не от полного отказа диска. [70]
  • Конструкция ZFS (копирование при записи + суперблоки) безопасна при использовании дисков с включенным кэшем записи, если они соблюдают барьеры записи. [ нужна ссылка ] Эта функция обеспечивает безопасность и повышение производительности по сравнению с некоторыми другими файловыми системами. [ по мнению кого? ]
  • В Solaris, когда в пул ZFS добавляются целые диски, ZFS автоматически включает их кэш записи. Этого не делается, когда ZFS управляет только дискретными фрагментами диска, поскольку он не знает, управляются ли другие фрагменты файловыми системами, не защищенными от кэша записи, такими как UFS . [ нужна ссылка ] Реализация FreeBSD может обрабатывать очистку диска для разделов благодаря своей структуре GEOM и, следовательно, не страдает от этого ограничения. [ нужна ссылка ]
  • Ограничения квот для каждого пользователя, группы, проекта и набора данных. [71]
  • Шифрование файловой системы начиная с Solaris 11 Express, [72] и OpenZFS (ZoL) 0.8. [54] (в некоторых других системах ZFS может использовать зашифрованные диски для аналогичного эффекта; GELI во FreeBSD можно использовать таким образом для создания полностью зашифрованного хранилища ZFS).
  • Пулы можно импортировать в режиме только для чтения.
  • Восстановить данные можно путем отката всех транзакций во время импорта zpool. [ нужна ссылка ]
  • ZFS не является кластерной файловой системой ; однако кластерная ZFS доступна у третьих сторон. [ нужна ссылка ]
  • Снимки можно делать вручную или автоматически. Более старые версии хранимых данных, которые они содержат, могут быть представлены как файловые системы, доступные только для чтения. Они также могут быть представлены как исторические версии файлов и папок при использовании с CIFS (также известным как SMB, Samba или общие файловые ресурсы ); это известно как «Предыдущие версии», «Теневые копии VSS» или «История файлов» в Windows или AFP и «Apple Time Machine» на устройствах Apple. [73]
  • Диски можно пометить как «запасные». Пул данных можно настроить на автоматическую и прозрачную обработку сбоев диска, активировав запасной диск и начав при необходимости переносить на него данные, которые находились на подозрительном диске.

Ограничения

[ редактировать ]
  • Начиная с версии Solaris 10 Update 11 и Solaris 11.2, невозможно было ни уменьшить количество виртуальных устройств верхнего уровня в пуле, за исключением устройств горячего резерва, кэша и журналов, ни иным образом уменьшить емкость пула. [74] Сообщается, что эта функциональность находилась в разработке в 2007 году. [75] В OpenZFS разрабатываются улучшения, позволяющие сократить количество виртуальных устройств. [76] Онлайн-сжатие путем удаления неизбыточных виртуальных устройств верхнего уровня поддерживается с момента выпуска Solaris 11.4 в августе 2018 г. [77] и OpenZFS (ZoL) 0.8, выпущенные в мае 2019 г. [54]
  • По состоянию на 2008 год не удалось добавить диск в качестве столбца к виртуальному устройству RAID Z, RAID Z2 или RAID Z3. Однако вместо этого можно создать новое виртуальное устройство RAID Z и добавить его в zpool. [78]
  • Некоторые традиционные вложенные конфигурации RAID, такие как RAID 51 (зеркало групп RAID 5), невозможно настроить в ZFS без некоторых сторонних инструментов. [79] Виртуальные устройства могут состоять только из необработанных дисков или файлов, но не из других виртуальных устройств, с использованием команд управления ZFS по умолчанию. [80] Однако пул ZFS фактически создает чередование (RAID 0) между своими виртуальными устройствами, поэтому обычно используется эквивалент RAID 50 или RAID 60.
  • Изменение количества устройств в виртуальном устройстве верхнего уровня требует копирования данных в автономном режиме, уничтожения пула и воссоздания пула с новой конфигурацией виртуального устройства верхнего уровня, за исключением добавления дополнительной избыточности к существующему зеркалу, что можно сделать в любое время. или если все виртуальные устройства верхнего уровня являются зеркалами с достаточной избыточностью, то zpool разделится. [81] Эту команду можно использовать для удаления виртуального устройства из каждого виртуального устройства верхнего уровня в пуле, создавая второй пул с идентичными данными.

Восстановление данных

[ редактировать ]

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

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

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

OpenZFS и ZFS

[ редактировать ]

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

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

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

[ редактировать ]
  • 2008: Sun поставила линейку устройств хранения данных серии 7000 на базе ZFS. [84]
  • 2013: Oracle поставила серию файловых систем на базе ZFS ZS3 и SPC-2 . с одним из них заняла первое место в тесте [85]
  • 2013: iXsystems поставляет NAS-устройства на базе ZFS под названием FreeNAS (теперь TrueNAS CORE) для SOHO и TrueNAS для предприятий. [86] [87]
  • 2014: Netgear выпускает линейку NAS-устройств на базе ZFS под названием ReadyDATA , предназначенных для использования на предприятии. [88]
  • 2015: rsync.net анонсирует платформу облачного хранения , которая позволяет клиентам создавать собственный zpool, а также импортировать и экспортировать данные с помощью zfs send и zfs take. [89] [90]
  • 2020: iXsystems начинает разработку гиперконвергентного программного обеспечения на базе ZFS под названием TrueNAS SCALE для малого и среднего бизнеса и TrueNAS для предприятий. [87]

Oracle Corporation, закрытый исходный код и форк (с 2010 г.)

[ редактировать ]

В январе 2010 года корпорация Oracle приобрела Sun Microsystems и быстро прекратила выпуск дистрибутива OpenSolaris и модели разработки с открытым исходным кодом. [91] [92] В августе 2010 года Oracle прекратила предоставлять общедоступные обновления исходного кода репозитория ОС/Сети Solaris, фактически превратив Solaris 11 обратно в операционную систему с закрытым исходным кодом проприетарную . [93]

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

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

История версий

[ редактировать ]
Более позднюю историю см. в разделах Oracle ZFS § История версий и OpenZFS § История версий .
Легенда:
Старый выпуск
Последняя FOSS стабильная версия
Номер версии файловой системы ZFS Дата выпуска Значительные изменения
1 OpenSolaris Невада [97] строй 36 Первый выпуск
2 OpenSolaris Невада b69 Расширенные записи каталога. В частности, записи каталога теперь сохраняют тип объекта. Например, файл, каталог, именованный канал и т. д., помимо номера объекта.
3 OpenSolaris Невада b77 Поддержка совместного использования файловых систем ZFS через SMB . Поддержка регистронезависимости. Поддержка системных атрибутов. Интегрированная антивирусная поддержка.
4 OpenSolaris Невада b114 Свойства: userquota, groupquota, userused и groupused.
5 OpenSolaris Невада b137 Системные атрибуты; символические ссылки теперь имеют собственный тип объекта
Номер версии пула ZFS Дата выпуска Значительные изменения
1 OpenSolaris Невада [97] б36 Первый выпуск
2 OpenSolaris Невада b38 То же самое с блоками
3 OpenSolaris Невада b42 с двойной четностью Горячие резервы, RAID-Z (raidz2), улучшенный учет RAID-Z
4 OpenSolaris Невада b62 история zpool
5 OpenSolaris Невада b62 сжатие gzip для наборов данных ZFS
6 OpenSolaris Невада b62 Свойство пула "bootfs"
7 OpenSolaris Невада b68 ZIL: добавляет возможность указать отдельное устройство или устройства журнала намерений.
8 OpenSolaris Невада b69 возможность делегировать административные задачи zfs(1M) обычным пользователям
9 OpenSolaris Невада b77 Поддержка сервера CIFS, квоты набора данных
10 OpenSolaris Невада b77 Устройства можно добавлять в пул носителей как «кэш-устройства».
11 OpenSolaris Невада b94 Улучшена производительность очистки/восстановления zpool.
12 OpenSolaris Невада b96 Свойства снимка
13 OpenSolaris Невада b98 Свойства: Usedbysnapshots, Usedby Children, Usedbyrefreservation и Usedbydataset.
14 OpenSolaris Невада b103 поддержка свойств passthrough-x aclinherit
15 OpenSolaris Невада b114 Свойства: userquota, groupquota, userused и groupused; также требуется FS v4
16 OpenSolaris Невада b116 Поддержка недвижимости STMF
17 OpenSolaris Невада b120 RAID-Z с тройной четностью
18 OpenSolaris Невада b121 Снимок ZFS сохраняется
19 OpenSolaris Невада b125 Удаление устройства журнала ZFS
20 OpenSolaris Невада b128 алгоритм сжатия zle, необходимый для поддержки свойств дедупликации ZFS в пуле ZFS версии 21, которые были выпущены одновременно
21 OpenSolaris Невада b128 Дедупликация
22 OpenSolaris Невада b128 zfs получает свойства
23 OpenSolaris Невада b135 тонкий ЗИЛ
24 OpenSolaris Невада b137 Системные атрибуты. Символические ссылки теперь имеют собственный тип объекта. Также требуется FS v5.
25 OpenSolaris Невада b140 Улучшена статистика очистки и перераспределения пула.
26 OpenSolaris Невада b141 Улучшена производительность удаления снимков.
27 OpenSolaris Невада b145 Улучшена производительность создания снимков (особенно рекурсивных).
28 OpenSolaris Невада b147 Замена нескольких виртуальных устройств

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

Поддержка операционной системы

[ редактировать ]

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

ТЫ Zpool-версия Номер сборки Sun/Oracle Комментарии
Оракул Солярис 11.4 49 11.4.51 (11.4 СРУ 51) [100]
Оракул Солярис 11.3 37 0.5.11-0.175.3.1.0.5.0
Oracle Solaris 10 1/13 (U11) 32
Оракул Солярис 11.2 35 0.5.11-0.175.2.0.0.42.0
Oracle Solaris 11 2011.11 34 б175
Oracle Solaris Express 11 2010.11 31 б151а лицензия только для тестирования
ОпенСолярис 2009.06 14 б111б
OpenSolaris (последняя разработка) 22 б134
OpenИндиана 5000 б147 распределение на основе иллюзий ; создает конфликт имен, называя свой код сборки «b151a»
Нексента Ядро 3.0.1 26 б134+ Пользовательское пространство GNU
NexentaStor Сообщество 3.0.1 26 б134+ до 18 ТБ, веб-администратор
NexentaStor Сообщество 3.1.0 28 б134+ Пользовательское пространство GNU
NexentaStor Сообщество 4.0 5000 б134+ до 18 ТБ, веб-администратор
НексентаСтор Предприятие 28 б134 + не бесплатно, веб-администратор
GNU/kFreeBSD «Сжатие» (не поддерживается) 14 Требуется пакет «zfsutils»
GNU/kFreeBSD «Wheezy-9» (не поддерживается) 28 Требуется пакет «zfsutils»
FreeBSD 5000
zfs-предохранитель 0.7.2 23 страдал от проблем с производительностью; несуществующий
ZFS в Linux 0.6.5.8 5000 Кандидат на выпуск 0.6.0 имеет уровень POSIX.
ZFS от KQ Infotech для Linux 28 несуществующий; код интегрирован в ZFS с поддержкой LLNL в Linux
Беленикс 0.8b1 14 б111 дистрибутив Live CD небольшого размера; когда-то на основе OpenSolaris
Шилликс 0.7.2 28 б147 дистрибутив Live CD небольшого размера; как SchilliX-ON 0.8.0 на базе OpenSolaris
StormOS «Да здравствует» дистрибутив единожды на базе Nexenta Core 2.0+, Debian Linux; заменен Dyson OS
банка Японское Sola распространение ; когда-то на основе OpenSolaris
МилаХ 0.5 20 б128а дистрибутив Live CD небольшого размера; когда-то на основе OpenSolaris
FreeNAS 8.0.2/8.2 15
FreeNAS 8.3.0 28 на базе FreeBSD 8.3
FreeNAS 9.1.0+ 5000 на базе FreeBSD 9.1+
XigmaNAS 11.4.0.4/12.2.0.4 5000 на базе FreeBSD 11.4/12.2
Корона 4.5.0 22 б134 ГДЕ
ЭОН NAS (v0.6) 22 б130 встроенный NAS
EON NAS (v1.0бета) 28 б151а встроенный NAS
сон-это 28/5000 Иллюмос/Солярис Устройство хранения; OpenIndiana (Hipster), OmniOS, Solaris 11, Linux (управление ZFS)
ОмниОС CE 28/5000 ветка illumos-OmniOS минимальный стабильный дистрибутив сервера хранения/LTS на базе Illumos, управляемый сообществом
СмартОС 28/5000 Иллюмос b151+ минимальное живое распространение на основе Illumos (загрузка с USB/CD); использование облака и гипервизора (KVM)
macOS 10.5, 10.6, 10.7, 10.8, 10.9 5000 через MacZFS; заменен OpenZFS на OS X
macOS 10.6, 10.7, 10.8 28 через ЗЕВО; заменен OpenZFS на OS X
NetBSD 22
ПолночьBSD 6
Проксмокс VE 5000 встроенная поддержка с 2014 года , pve.proxmox.com/wiki/ZFS_on_Linux
Убунту Линукс 16.04 ЛТС+ 5000 встроенная поддержка через устанавливаемый двоичный модуль , wiki.ubuntu.com/ZFS
ЗФСГуру 10.1.100 5000

См. также

[ редактировать ]

Примечания

[ редактировать ]
  1. ^ Хотя RAID 7 не является стандартным уровнем RAID, он был предложен как общий термин для любой конфигурации RAID с четностью >3. [38]

Ссылки

[ редактировать ]
  1. ^ Jump up to: Перейти обратно: а б «Что такое ZFS?» . Руководство по администрированию файловой системы Oracle Solaris ZFS . Оракул. Архивировано из оригинала 4 марта 2016 года . Проверено 29 декабря 2015 г.
  2. ^ «Лицензирование ZFS в Linux» . Гитхаб . Проверено 17 мая 2020 г.
  3. ^ «Запуск проекта OpenZFS» . LWN.net . 17 сентября 2013. Архивировано из оригинала 4 октября 2013 года . Проверено 1 октября 2013 г.
  4. ^ «Анонс OpenZFS» . ОпенЗФС . 17 сентября 2013 года. Архивировано из оригинала 2 апреля 2018 года . Проверено 19 сентября 2013 г.
  5. ^ open-zfs.org / History. Архивировано 24 декабря 2013 г., на Wayback Machine. «OpenZFS является преемником проекта ZFS с открытым исходным кодом [...] Эффекты разветвления (с 2010 г. по настоящее время)»
  6. ^ Шон Майкл Кернер (18 сентября 2013 г.). «LinuxCon: OpenZFS продвигает хранилище с открытым исходным кодом» . infostor.com. Архивировано из оригинала 14 марта 2014 года . Проверено 9 октября 2013 г.
  7. ^ «Запуск проекта OpenZFS» . LWN.net . 17 сентября 2013. Архивировано из оригинала 11 октября 2016 года . Проверено 1 октября 2013 г.
  8. ^ «OpenZFS — сообщества, сотрудничающие над кодом и функциями ZFS» . freebsdnews.net. 23 сентября 2013. Архивировано из оригинала 14 октября 2013 года . Проверено 14 марта 2014 г.
  9. ^ «Часто задаваемые вопросы по Starline ZFS» . Старлайн . Проверено 20 июля 2024 г.
  10. ^ Jump up to: Перейти обратно: а б «19.4. Администрирование zfs» . www.freebsd.org . Архивировано из оригинала 23 февраля 2017 года . Проверено 22 февраля 2017 г.
  11. ^ Салус, Питер (1994). Четверть века Unix . Аддисон-Уэсли. стр. 199–200. ISBN  0-201-54777-5 .
  12. ^ «Что такое SunOS и Solaris?» . База знаний . Технологические службы Университета Индианы. 20 мая 2013 года . Проверено 10 ноября 2014 г.
  13. ^ Браун, Дэвид. «Разговор с Джеффом Бонвиком и Биллом Муром» . Очередь АКМ . Ассоциация вычислительной техники. Архивировано из оригинала 16 июля 2011 года . Проверено 17 ноября 2015 г.
  14. ^ «ZFS: последнее слово в файловых системах» . Сан Микросистемс. 14 сентября 2004 года. Архивировано из оригинала 28 апреля 2006 года . Проверено 30 апреля 2006 г.
  15. ^ Мэтью Аренс (1 ноября 2011 г.). «10-летний юбилей ZFS» . Архивировано из оригинала 28 июня 2016 года . Проверено 24 июля 2012 г.
  16. ^ Jump up to: Перейти обратно: а б Бонвик, Джефф (31 октября 2005 г.). «ZFS: последнее слово в файловых системах» . blogs.oracle.com . Архивировано из оригинала 19 июня 2013 года . Проверено 22 июня 2013 г.
  17. ^ «Sun празднует успешную годовщину OpenSolaris» . Сан Микросистемс. 20 июня 2006 года. Архивировано из оригинала 28 сентября 2008 года . Проверено 30 апреля 2018 г.
  18. ^ Майкл Сингер (25 января 2005 г.). «Солнце взломало Солярис» . ИнтернетНьюс.com . Проверено 12 апреля 2010 г.
  19. ^ «Часто задаваемые вопросы по ZFS на OpenSolaris.org» . Сан Микросистемс. Архивировано из оригинала 15 мая 2011 года . Проверено 18 мая 2011 г. Самая большая приставка SI, которая нам понравилась, была «зетта» (о «йотте» не могло быть и речи).
  20. ^ Джефф Бонвик (3 мая 2006 г.). «Вы говорите «дзета», я говорю «зетта» . Блог Джеффа Бонвика . Архивировано из оригинала 23 февраля 2017 года . Проверено 21 апреля 2017 г. Поэтому мы, наконец, решили вернуть название ZFS, которое ничего не означает.
  21. ^ «Oracle и NetApp отклоняют иски ZFS» . theregister.co.uk. 9 сентября 2010 года. Архивировано из оригинала 9 сентября 2017 года . Проверено 24 декабря 2013 г.
  22. ^ Расширенная файловая система (Ext) имеет структуру метаданных , скопированную из UFS. «Реми Кард (интервью, апрель 1998 г.)» . Апрельская ассоциация. 19 апреля 1999 года. Архивировано из оригинала 4 февраля 2012 года . Проверено 8 февраля 2012 г. (на французском языке)
  23. ^ Виджаян Прабхакаран (2006). «ЖЕЛЕЗНЫЕ ФАЙЛОВЫЕ СИСТЕМЫ» (PDF) . Доктор философии в области компьютерных наук . Университет Висконсин-Мэдисон. Архивировано (PDF) из оригинала 29 апреля 2011 г. Проверено 9 июня 2012 г.
  24. ^ «Паритет потерян и паритет восстановлен» . Архивировано из оригинала 15 июня 2010 года . Проверено 29 ноября 2010 г.
  25. ^ «Анализ повреждения данных в стеке хранения» (PDF) . Архивировано (PDF) из оригинала 15 июня 2010 г. Проверено 29 ноября 2010 г.
  26. ^ «Влияние повреждения диска на СУБД с открытым исходным кодом» (PDF) . Архивировано (PDF) из оригинала 15 июня 2010 г. Проверено 29 ноября 2010 г.
  27. ^ Кадав, Асим; Раджимвале, Абхишек. «Анализ надежности ZFS» (PDF) . Архивировано (PDF) из оригинала 21 сентября 2013 г. Проверено 19 сентября 2013 г.
  28. ^ Юпу Чжан; Абхишек Раджимвале; Андреа Арпачи-Дюссо ; Ремзи Х. Арпачи-Дюссо (2010). «Сквозная целостность данных для файловых систем: пример ZFS» (PDF) . Конференция USENIX по файловым технологиям и технологиям хранения данных . CiteSeerX   10.1.1.154.3979 . S2CID   5722163 . Викиданные   Q111972797 . Проверено 6 декабря 2010 г.
  29. ^ Ларабель, Майкл. «Сравнение ZFS и UFS во FreeBSD по сравнению с EXT4 и Btrfs в Linux» . Phoronix Media 2012. Архивировано из оригинала 29 ноября 2016 года . Проверено 21 ноября 2012 г.
  30. ^ Ларабель, Майкл. «Может ли HAMMER DragonFlyBSD конкурировать с Btrfs и ZFS?» . Phoronix Media 2012. Архивировано из оригинала 29 ноября 2016 года . Проверено 21 ноября 2012 г.
  31. ^ Jump up to: Перейти обратно: а б с Бонвик, Джефф (8 декабря 2005 г.). «Сквозная целостность данных ZFS» . blogs.oracle.com . Архивировано из оригинала 3 апреля 2012 года . Проверено 19 сентября 2013 г.
  32. ^ Кук, Тим (16 ноября 2009 г.). «Демонстрация самовосстановления ZFS» . blogs.oracle.com . Архивировано из оригинала 12 августа 2011 года . Проверено 1 февраля 2015 г.
  33. ^ Ранч, Ричард (4 мая 2007 г.). «ZFS, копирование и защита данных» . blogs.oracle.com . Архивировано из оригинала 18 августа 2016 года . Проверено 2 февраля 2015 г.
  34. ^ Jump up to: Перейти обратно: а б «zpoolconcepts.7 — документация OpenZFS» . openzfs.github.io . Проверено 5 апреля 2023 г.
  35. ^ «ZFS без слез: использование ZFS без памяти ECC» . www.csparks.com . Декабрь 2015. Архивировано из оригинала 13 января 2021 года . Проверено 16 июня 2020 г.
  36. ^ wdc.custhelp.com. «Разница между дисками версии Desktop и RAID (Enterprise)» . Архивировано из оригинала 5 января 2015 года . Проверено 8 сентября 2011 г.
  37. ^ Jump up to: Перейти обратно: а б с д Бонвик, Джефф (17 ноября 2005 г.). «РЕЙД-З» . Блог Джеффа Бонвика . Блоги Oracle . Архивировано из оригинала 16 декабря 2014 года . Проверено 1 февраля 2015 г.
  38. ^ Jump up to: Перейти обратно: а б Левенталь, Адам (17 декабря 2009 г.). «RAID с тройной четностью и не только» . Очередь . 7 (11): 30. дои : 10.1145/1661785.1670144 .
  39. ^ «Производительность, емкость и целостность ZFS Raidz» . www.calomel.org . Архивировано из оригинала 27 ноября 2017 года . Проверено 23 июня 2017 г.
  40. ^ «Почему RAID 6 перестает работать в 2019 году» . ЗДНет . 22 февраля 2010. Архивировано из оригинала 31 октября 2014 года . Проверено 26 октября 2014 г.
  41. ^ «Для ZFS не существует эквивалента утилиты fsck. Эта утилита традиционно служила двум целям: восстановлению файловой системы и проверке файловой системы». «Проверка целостности файловой системы ZFS» . Оракул. Архивировано из оригинала 31 января 2013 года . Проверено 25 ноября 2012 г.
  42. ^ «Скрабы ZFS» . freenas.org. Архивировано из оригинала 27 ноября 2012 года . Проверено 25 ноября 2012 г.
  43. ^ «Вам также следует запустить очистку перед заменой устройств или временным сокращением избыточности пула, чтобы убедиться, что все устройства в данный момент работают». «Руководство по передовому опыту работы с ZFS» . Solarisinternals.com. Архивировано из оригинала 5 сентября 2015 года . Проверено 25 ноября 2012 г.
  44. ^ Джефф Бонвик. «128-битная память: ты под кайфом?» . oracle.com . Архивировано из оригинала 29 мая 2015 года . Проверено 29 мая 2015 г.
  45. ^ «ZFS: кипятит океан, поглощает луну (блог Дэйва Бриллхарта)» . Архивировано из оригинала 8 декабря 2015 года . Проверено 19 декабря 2015 г.
  46. ^ «Руководство по администрированию Solaris ZFS» . Корпорация Оракл. Архивировано из оригинала 13 января 2021 года . Проверено 11 февраля 2011 г.
  47. ^ «Шифрование файловых систем ZFS» . Архивировано из оригинала 23 июня 2011 года . Проверено 2 мая 2011 г.
  48. ^ «Наличие защищенного пирога и его клонирование (также известное как шифрование + дедупликация с помощью ZFS)» . Архивировано из оригинала 29 мая 2013 года . Проверено 9 октября 2012 г.
  49. ^ «ZFS — Debian Wiki» . wiki.debian.org . Архивировано из оригинала 8 сентября 2019 года . Проверено 10 декабря 2019 г.
  50. ^ «Solaris ZFS обеспечивает гибридные пулы хранения данных — разрушает экономические барьеры и барьеры производительности» (PDF) . Сан.ком. 7 сентября 2010 г. Архивировано (PDF) из оригинала 17 октября 2011 г. . Проверено 4 ноября 2011 г.
  51. ^ Грегг, Брендан. «ЗФС Л2АРК» . Блог Брендана . Dtrace.org. Архивировано из оригинала 6 ноября 2011 года . Проверено 5 октября 2012 г.
  52. ^ Грегг, Брендан (8 октября 2009 г.). «Гибридный пул хранения данных: максимальная скорость» . Блог Брендана . Dtrace.org. Архивировано из оригинала 5 апреля 2016 года . Проверено 15 августа 2017 г.
  53. ^ «Настройка производительности Solaris ZFS: синхронная запись и ZIL» . Константин.glez.de. 20 июля 2010. Архивировано из оригинала 23 июня 2012 года . Проверено 5 октября 2012 г.
  54. ^ Jump up to: Перейти обратно: а б с «Выпуск zfs-0.8.0» . Гитхаб . ОпенЗФС. 23 мая 2019 года . Проверено 3 июля 2021 г.
  55. ^ «Спецификация ZFS на диске» (PDF) . Sun Microsystems, Inc. 2006. Архивировано из оригинала (PDF) 30 декабря 2008 г. См. раздел 2.4.
  56. ^ «RAIDZ — документация OpenZFS» . openzfs.github.io . Проверено 9 февраля 2023 г.
  57. ^ Эрик Спроул (21 мая 2009 г.). «Гайки и болты ZFS» . SlideShare.net. стр. 30–31. Архивировано из оригинала 22 июня 2014 года . Проверено 8 июня 2014 г.
  58. ^ «Дедупликация ZFS» . blogs.oracle.com . Архивировано из оригинала 24 декабря 2019 года . Проверено 25 ноября 2019 г.
  59. ^ Гэри Симс (4 января 2012 г.). «Создание сетевого хранилища на базе ZFS с использованием FreeNAS 8» . Обучение TrainSignal . TrainSignal, Inc. Архивировано из оригинала (блога) 7 мая 2012 года . Проверено 9 июня 2012 г.
  60. ^ Рэй Ван Долсон (май 2011 г.). «[zfs-discuss] Резюме: Требования к памяти для дедупликации» . список рассылки zfs-discuss. Архивировано из оригинала 25 апреля 2012 года.
  61. ^ «ZFSTuningGuide» . Архивировано из оригинала 16 января 2012 года . Проверено 3 января 2012 г.
  62. ^ Крис Меллор (12 октября 2012 г.). «GreenBytes демонстрирует полноценный клон VDI Pumper» . Регистр . Архивировано из оригинала 24 марта 2013 года . Проверено 29 августа 2013 г.
  63. ^ Крис Меллор (1 июня 2012 г.). «Новичок достает свою шкатулку, планирует дешево продать ее всем желающим» . Регистр . Архивировано из оригинала 12 августа 2013 года . Проверено 29 августа 2013 г.
  64. ^ Крис Меллор (11 декабря 2014 г.). «Дедуп, дедуп... дедуп, дедуп, дедуп: Oracle полирует бриллиант ZFS» . Регистр . Архивировано из оригинала 7 июля 2017 года . Проверено 17 декабря 2014 г.
  65. ^ «Контрольные суммы и их использование в ZFS» . github.com . 2 сентября 2018 года. Архивировано из оригинала 19 июля 2019 года . Проверено 11 июля 2019 г.
  66. ^ «Руководство по администрированию Solaris ZFS» . Глава 6 Управление файловыми системами ZFS . Архивировано из оригинала 5 февраля 2011 года . Проверено 17 марта 2009 г.
  67. ^ «Дымящиеся зеркала» . blogs.oracle.com . 2 мая 2006. Архивировано из оригинала 16 декабря 2011 года . Проверено 13 февраля 2012 г.
  68. ^ «Распределение блоков ZFS» . Блог Джеффа Бонвика . 4 ноября 2006 г. Архивировано из оригинала 2 ноября 2012 г. Проверено 23 февраля 2007 г.
  69. ^ «То же блоки — удивительное средство от ленты» . Блог . 12 мая 2006 года. Архивировано из оригинала 26 мая 2013 года . Проверено 1 марта 2007 г.
  70. ^ «Добавление новых дисков и аналогичное поведение блоков» . Архивировано из оригинала 23 августа 2011 года . Проверено 19 октября 2009 г.
  71. ^ «ОпенСолярис.орг» . Сан Микросистемс. Архивировано из оригинала 8 мая 2009 года . Проверено 22 мая 2009 г.
  72. ^ «Что нового в Solaris 11 Express 2010.11» (PDF) . Оракул. Архивировано (PDF) из оригинала 16 ноября 2010 г. Проверено 17 ноября 2010 г.
  73. ^ «10. Совместное использование — Руководство пользователя FreeNAS 9.3 Содержание» . doc.freenas.org . Архивировано из оригинала 7 января 2017 года . Проверено 23 февраля 2017 г.
  74. ^ «Идентификатор ошибки 4852783: уменьшить емкость пула» . Проект OpenSolaris. Архивировано из оригинала 29 июня 2009 года . Проверено 28 марта 2009 г.
  75. ^ Геббельс, Марио (19 апреля 2007 г.). «Навсегда удаление vdevs из пула» . zfs-discuss (список рассылки). [ постоянная мертвая ссылка ] Архивная ссылка. Архивировано 13 января 2021 г. в Wayback Machine.
  76. ^ Крис Зибенманн Информация о будущем удалении vdev . Архивировано 11 августа 2016 г. на Wayback Machine , Univ Toronto, блог, цитата: неофициальное объявление в Твиттере Алекса Риса. Архивировано 11 августа 2016 г. на Wayback Machine.
  77. ^ «Функции управления данными – что нового в Oracle® Solaris 11.4» . Архивировано из оригинала 24 сентября 2019 года . Проверено 9 октября 2019 г.
  78. ^ «Expand-O-Matic RAID Z» . Адам Левенталь. 7 апреля 2008 года. Архивировано из оригинала 28 декабря 2011 года . Проверено 16 апреля 2012 г.
  79. ^ «ЗФС Той» . SourceForge.net . Проверено 12 апреля 2022 г.
  80. ^ "zpoolconcepts(7)" . Документация OpenZFS . ОпенЗФС. 2 июня 2021 г. Проверено 12 апреля 2021 г. Виртуальные устройства не могут быть вложенными, поэтому виртуальное устройство зеркало или RAIDZ может содержать только файлы или диски. Зеркало зеркал (или другие комбинации) не допускаются.
  81. ^ "zpool(1M)" . Скачать.oracle.com. 11 июня 2010 года. Архивировано из оригинала 13 января 2021 года . Проверено 4 ноября 2011 г.
  82. ^ «Турбонаддувное восстановление данных ZFS» . Архивировано из оригинала 29 ноября 2018 года . Проверено 29 ноября 2018 г.
  83. ^ «ZFS и OpenZFS» . iXSystems . Проверено 18 мая 2020 г.
  84. ^ «Sun выпускает собственные устройства хранения данных» . techworld.com.au. 11 ноября 2008 года. Архивировано из оригинала 13 ноября 2013 года . Проверено 13 ноября 2013 г.
  85. ^ Крис Меллор (2 октября 2013 г.). «Oracle уверенно занимает лидирующие позиции благодаря мощному фильтру ZFS» . theregister.co.uk. Архивировано из оригинала 7 июля 2017 года . Проверено 7 июля 2014 г.
  86. ^ «Унифицированное устройство хранения данных ZFS, созданное в Кремниевой долине компанией iXsystem» . ixsystems.com. Архивировано из оригинала 3 июля 2014 года . Проверено 7 июля 2014 г.
  87. ^ Jump up to: Перейти обратно: а б «TrueNAS 12 и TrueNAS SCALE официально представлены!» . ixsystems.com . Проверено 2 января 2021 г.
  88. ^ «ReadyDATA 516 – унифицированное сетевое хранилище» (PDF) . netgear.com. Архивировано (PDF) из оригинала 15 июля 2014 г. Проверено 7 июля 2014 г.
  89. ^ Джим Солтер (17 декабря 2015 г.). «rsync.net: Репликация ZFS в облако наконец-то появилась — и она быстрая» . arstechnica.com. Архивировано из оригинала 22 августа 2017 года . Проверено 21 августа 2017 г.
  90. ^ rsync.net, Inc. «Облачное хранилище с отправкой и получением ZFS через SSH» . rsync.net. Архивировано из оригинала 21 июля 2017 года . Проверено 21 августа 2017 г.
  91. ^ Стивен Сталлион / Oracle (13 августа 2010 г.). «Обновление SXCE» . Иконоборческие тенденции. Архивировано из оригинала 9 ноября 2020 года . Проверено 30 апреля 2018 г.
  92. ^ Аласдер Ламсден. «OpenSolaris отменен и будет заменен Solaris 11 Express» . osol-discuss (список рассылки). Архивировано из оригинала 16 августа 2010 года . Проверено 24 ноября 2014 г.
  93. ^ Solaris все еще открыт, но дистрибутив OpenSolaris мертв. Архивировано 5 сентября 2017 г. в Wayback Machine на Ars Technica Райаном Полом (16 августа 2010 г.).
  94. ^ Гаррет Д'Амор (3 августа 2010 г.). «Иллюмос - Надежда и свет рождаются заново - Представлено Гарретом Д'Амором» (PDF) . иллюмос.орг . Проверено 3 августа 2010 г.
  95. ^ «Куда OpenSolaris? Illumos принимает мантию» . Архивировано из оригинала 26 сентября 2015 года.
  96. ^ Гаррет Д'Амор (13 августа 2010 г.). «Рука может быть вынуждена» . Проверено 14 ноября 2013 г.
  97. ^ Jump up to: Перейти обратно: а б с «Находясь под контролем Sun Microsystems, раз в две недели создавались снимки Solaris Nevada (кодовое название ОС Solaris следующего поколения, которая в конечном итоге придет на смену Solaris 10), и этот новый код затем был включен в новые предварительные снимки OpenSolaris, доступные на Genunix.org . Стабильные выпуски OpenSolaris основаны на [ sic ] этих сборках в Неваде». Ларабель, Майкл. «Похоже, что Oracle поддержит OpenSolaris» . Фороникс Медиа. Архивировано из оригинала 29 ноября 2016 года . Проверено 21 ноября 2012 г.
  98. ^ Любунчич, Игорь (23 мая 2011 г.). «OpenIndiana — надежда еще есть» . ДистроВотч . Архивировано из оригинала 27 октября 2012 года . Проверено 21 ноября 2012 г.
  99. ^ «Добро пожаловать в проект OpenIndiana!» . Проект ОпенИндиана. 10 сентября 2010 года. Архивировано из оригинала 27 ноября 2012 года . Проверено 14 сентября 2010 г.
  100. ^ «Версии пула ZFS» . Корпорация Оракл. 2022. Архивировано из оригинала 21 декабря 2022 года . Проверено 1 января 2023 г.

Библиография

[ редактировать ]
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=ZFS&oldid=1235643296"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: f2d7fbbde674234f9a44ebdacf8b1e05__1721475360
URL1:https://arc.ask3.ru/arc/aa/f2/05/f2d7fbbde674234f9a44ebdacf8b1e05.html
Заголовок, (Title) документа по адресу, URL1:
ZFS - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)