Файловые системы ближайшего будущего. ZFS

ZFS в порядке сжатия и дедупликации linux

каков порядок записи данных в файловую систему zfs в linux?

единственный конкретный документ я нашел на http://docs.oracle.com/cd/E36784_01/html/E36835/gkknx.html говорит: When a file is written, the data is compressed, encrypted, and the checksum is verified. Then, the data is deduplicated, if possible.

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

Я тестировал mysqlf, и я считаю, что порядок следующий: dedup, compress, encrypt .

мой тест-настройка:

Zpool create tank /dev/sdb zfs create tank/lz4 zfs create tank/gzip9 zfs set compression=lz4 tank/lz4 zfs set compression=gzip-9 tank/gzip9 zfs set dedup=on tank

выход zfs list

NAME USED AVAIL REFER MOUNTPOINT tank 106K 19,3G 19K /tank tank/gzip9 19K 19,3G 19K /tank/gzip9 tank/lz4 19K 19,3G 19K /tank/lz4

сгенерируйте случайный файл с помощью dd if=/dev/urandom of=random.txt count=128K bs=1024

131072+0 Datensätze ein 131072+0 Datensätze aus 134217728 Bytes (134 MB) kopiert, 12,8786 s, 10,4 MB/s

вывод списка zpool в пустой пул:

NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT tank 19,9G 134K 19,9G - 0% 0% 1.00x ONLINE -

затем скопируйте файлы в наборы данных с различными алгоритмами сжатия:

Cp random.txt /tank/lz4 cp random.txt /tank/gzip9

выход zfs list после копирования:

NAME USED AVAIL REFER MOUNTPOINT tank 257M 19,1G 19K /tank tank/gzip9 128M 19,1G 128M /tank/gzip9 tank/lz4 128M 19,1G 128M /tank/lz4

выход zpool list afer копирование:

NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT tank 19,9G 129M 19,7G - 0% 0% 2.00x ONLINE -

коэффициент дедупликации 2.0 после копирование одного файла в разные наборы данных. На мой взгляд, это означает, что дедупликация выполняется на data -блоки перед сжатием и шифрованием.

пожалуйста, кто-нибудь может проверить, правильно ли это?

1 ответов

когда файл записывается, данные сжимаются, шифруются, и контрольная сумма проверяется. Затем данные дедуплицируются, если это возможно.

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

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

Файловая система ZFS — основа надежного и недорого хранилища данных

На страницах проекта сайт была затронута тема организации файлового хранилища:

  • первая часть
  • вторая часть

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

Введение в ZFS

Аббревиатура ZFS получилось из словосочетания zettabyte file system, обозначая тем самым одну из самых современных и совершенных файлововых систем. Например, уже из названия следует, что это зетабайтная файловая система , если быть точнее, то данная FS поддерживает 256 квадриллионов зетабайт. Для справки — один зетабайт равен 1 073 741 824 терабайт!

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

К основным плюсам данной FS — практически неограниченное дисковое пространство и встроенные инструменты построения отказоустойчивых RAID-Z массивов, относится также и атомарная запись данных . Под этим термином понимается следующее — данные либо полностью записываются на диск, либо не записываются вовсе. Такая технология позволяет избежать проблем, которые возникают в случаях сбоев работы сети, подсистемы питания и отказа операционной системы.

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

Изначально ZFS была разработана в недрах компании Sun Microsystems для операционной системы Solaris. Сейчас благодаря ряду проектов, данная файловая система стала доступной для других ОС. К ним относятся — помимо Solaris, еще и OpenSolaris, Apple Mac OS X 10.5, FreeBSD, Linux (через FUSE или отдельный модуль ядра (ZFS on Linux)). Выбор конкретной ОС для своего проекта или проще говоря, для файлового хранилища остается за вами. Наибольшее распространение получила FreeBSD и производная — NAS4Free.

Конструктивные особенности системы хранения

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

  • Объем дискового пространства

Из потребностей и требований к объему создаваемого хранилища, определяется количество HDD , их модели, а также тип конфигурации RAID-Z. Сразу приведу несколько рекомендаций:

— максимальная надежность и производительность достигается при испольловании жестких дисков одной модели и производителя

— ОС не следует размещать в самом хранилище, лучше использовать отдельный HDD/USB-напопитель

— количество дисков должно соответствовать выбранной системе RAID-Z

  • Варианты RAID-Z

Существует несколько разновидностей RAID-Z массивов, но сейчас мы рассмотрим два наиболее практичных и популярны:

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

— raid-z2 — в данном случае для контроля четности выделяется 2 диска (минимум дисков для такой конфигурации — 5 шт.). Эта система является более отказоустойчивой.

  • Жесткие диски

Как было сказано ранее — лучше всего использовать одинаковые диски одного производителя (объем, модель и т.п.). При этом, стоит учитывать один важный момент, который молодые специалисты упускают. Настоятельно рекомендуется приобретать на один диск больше, т.е. производить закупку по формуле n+1 количество дисков. Это снизит время простоя и риски потери информации при «заводском браке» или повреждении HDD при транспортировке, а также сократит время в будущем по замене неисправного жесткого диска. Стоит отметить, ZFS поддерживает «hot spare», т.е. можно выполнить конфигурирование пула и дисков так, что один из них будет использоваться для горячей замены (без остановки хранилища), в том числе и в автоматическом режиме. Также стоит понимать, что от количества жестких дисков зависит и скорость работы хранилища (за счет распределения нагрузки по дискам в моменты чтения и записи).

  • Другие компоненты системы

Исходя из требований к объему хранилища, стоит выбирать мат. платы, контроллеры, блоки питания и корпуса для серверов с возможность расширения. При организации хранилища корпоративного класса стоит использовать только MB и RAM с контролем четности (ECC)!

  • Масштабируемость системы

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

Подведем итог

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

Кратко перечислю основные преимущества и свойства ZFS:

  • встроенные инструменты для работы с разделами HDD и организации RAID-Z
  • нет привязки к оборудованию
  • нечувствительна к незапланированным отключениям электропитания
  • автоматическая подмена вышедших из строя HDD, исправление ошибок и перестроение RAID
  • поддерживаются огромные размеры томов, файлов, пулов, а также легкая масштабируемость хранилища
  • быстрое и удобное администрирование ZFS Pool’ов
  • при увеличении HDD повышается производительность хранилища
  • дедупликация и сжатие данных

К минусам данной файловой системы можно отнести:

  • высокие требования к ресурсам CPU и RAM
  • хранилища, используемые для важных корпоративных данных, должны быть построены при использовании ECC RAM.

Следующая статья будет практической — работа с дисками, создание и администрирование пулов данных.

В предыдущих постах я неоднократно упоминал о zfs. Причем получалось, что и памяти и процессора она требует не по детски. Остался вопрос - и зачем? Сразу скажу, что не претендую на полноту и пр. Что такое zfs можно взглянуть в Википедии. Заинтересовавшимся серьёзнее советую нагуглить zfs administration guide (вроде бы был и по русски). Моё намерение - объяснить зачем вдруг дома файловая система корпоративного уровня. Прим. У читателя, особенно второй части поcта, предполагается уверенное понимание того, что такое дисковые массивы, напр. RAID5. Если понимания нет - вряд ли такие массивы стоит дома самому строить и этот текст читать.


1. Целостность файловой системы . Каждый сталкивался с ситуацией, когда файловую систему приходилось чинить. Успешно или не очень. zfs построена так, что в ней даже нет утилиты вроде виндовой chkdsk или линуксовой fsck. Ситуация, когда файловая система оказалась в противоречивом состоянии, просто невозможна. Реализовано через Copy-on-write (данные пишем не поверх старых, а выделяем новый блок, пишем туда, если все ОК - заменяем указатель со старых данных на новые. Подробнее - см гугл). В результате логическая структура диска не испортится из-за того, что-то не вовремя отключили или свет отрубился. Ну разве записанное в последние 10 сек пропадет. (впрочем, диск может и физически сгореть при играх с электричеством).

2. Уверенность, что не прочитаешь мусор, думая, что читаешь данные . Железо несовершенно. Например, если дребезжат контакты на SATA кабелях, на диск будет записано совсем не то, что было в памяти. И никто, замечу, долгое время об этом не узнает. Мой профессиональный опыт связан с полиграфией. Не раз приходилось на выводе видеть картинку до середины нормальную - а дальше шум. zfs хранит с каждым блоком данных его контрольную сумму. При считывании данных сумма автоматически сличается. Казалось бы, так просто...

3. Уверенность, что хранимые данные не протухли . Да, данные при хранении имеют тенденцию портиться. Что хорошо известно тем, кто поверил маркетингу производителей DVD болванок про 100 лет и записал на них свои архивы. Особенно это важно для "холодных" данных, долгое время лежащих без движения. Архивах, старых фото и т.п. Проверить данные вроде как просто - надо их считать и сличить контрольные суммы. Для zfs, понятно - достаточно файлы прочитать. Для регулярной проверки есть команда, в фоновом режиме все проверяющая.

4. Снимки файловой системы. Легкость запоминания состояния файловой системы на данный момент времени, хранение таких снимков и откат к ним при необходимости. Защищает от дурацких действий человека. Модель Copy-on-write просто располагает к такой функциональности - блоки удаленных или перезаписанных данных просто не освобождаем, а ссылки на них храним в снимке. В результате снимок занимает места столько, сколько содержит измененных по сравнению текущим моментом данных, а не весь объем данных.

Это все было для данных без избыточности, типа одиночного диска. Но zfs позволяет формировать массивы с избыточностью , подобные (и превосходящие) RAID1 (зеркало), RAID5 (избыточность в размере одного диска), RAID6 (двух) и даже "RAID7" (сохраняющий данные при выходе их строя любых трех дисков массива). Массивы можно объединять, получая что-то вроде RAID10 или RAID50. И чем же zfs массивы лучше?

5. Аппаратная независимость . Чтобы сделать аппаратный RAID5, тем более RAID6, нужен дорогой RAID контроллер. zfs raidz - вариант программного RAID, требуются только доступ к дискам, например SATA порты. zfs raidz вполне может быть построен на портах разных контроллеров и из дисков разных моделей (в использовании разных моделей дисков есть и плюсы и минусы). И перенесен чуть не на любое железо, куда можно подключить диски. Я, например, неоднократно переставлял диски между SATA портами, прозрачно импортировал массив, созданный в режиме IDE на контроллере, в ACHI режиме и на SAS контроллере. Хотя операционная система нумерует диски по портам и определяет IDE, ACHI и SAS диски по-разному, zfs все это способен молча отработать (до определенных пределов, конечно. Сдуру что хочешь можно сломать.)

6. Отсутствие Дыры по Записи . (Wiki) То есть разрушения данных, если диск массива не может принять данные. Дорогие RAID контроллеры оборудуют батарейками, которые позволяют много дней хранить данные, не успевшие попасть на диск, и записывать их в массив при появлении возможности.

7. Устойчивость при сбое диска . Пусть у нас одинаковые RAID5 и zfs raidz1. В каждом из них сбоит один из дисков, меняем его на новый. И в процессе замены (а она занимает многие часы для больших массивов) не читается блок на одном из оставшихся дисков массива.

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

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

8. Работа с полезными данными, а не всем массивом . Например, если я заменяю диск в RAID5 массиве, время восстановления зависит от объема массива. Если в zfs raid1 - от объема записанной в массив информации, тк не используемое для данных место не будет синхронизироваться.

Преимуществ еще много, но мне для дома интереснее именно эти. В корпоративном применении - есть и другие (сжатие данных, дедупликация...). Упомяну важные для меня недостатки .

1. Нарастить raidz массив на один диск нельзя . Можно заменить все терабайтные диски на тритеры - и увеличить объем. Можно собрать из 3 (и более) дисков еще один raidz и добавить его к существующему. Но превратить raidz1 из 5 дисков в raidz1 из 6 можно только слив куда-то информацию, разрушив массив и создав новый.

2. Массив нельзя уменьшить . Можно только увеличивать. Например, заменить в массиве терабайтные винты на двухтерабайтные - можно. А на полутерабайтные - нельзя, даже если в массиве хранится 1 килобайт инфы.
Можно подсоединить к массиву еще один - а отсоединить нельзя. Все такие процедуры - только через сохранение инфы куда-то вовне, разрушение массива и создание нового.

3. Ресурсоемкость . zfs постоянно считает контрольные суммы, что создает нагрузку на процессор и жрет под кеши память. В корпоративном применении есть мнение - гигабайт памяти на терабайт массива. Дома мне хватает 330 атома и 4 Гб памяти (а раньше и на 2 Гб работало - особой разницы не увидел). Хотя атома для полной утилизации гигабитной сети мне не хватает, но 40-50мб/с мои потребности закрывает.. А вот если железо старое и еще значительно слабее - zfs не для Вас.

Да, напомню, если понравилось - в NAS4free , которому и посвящен весь цикл постов, управление NAS, включая операции с zfs, идет через понятный новичку веб интерфейс.

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

Первая директива систем хранения: не возвращать неправильные данные!

Революция ZFS. Около 2006 года

С 2007 по 2010-й: ZFS пошла под откос

Но что-то ужасное случилось с ZFS на пути к её триумфу: судебные иски, проблемы с лицензиями и FUD - тактика психологической манипуляции от недоброжелателей.

Первые тучи появились в 2007 году, когда NetApp подала иск к Sun на основании того, что ZFS нарушает их патенты на WAFL. Sun ответила встречным иском в том же году - и юридические тяжбы затянулись. Хотя в ZFS определённо не было кода NetApp, но механизм копирования при записи в снапшоты был похож на WAFL, и некоторые из нас в индустрии обеспокоились, что иск NetApp повлияет на доступность открытых исходников ZFS. Этих рисков оказалось достаточно для Apple, чтобы отказаться от поддержки ZFS в Mac OS X 10.6 “Snow Leopard” прямо перед выпуском этой ОС.

Вот отличный блог о ZFS и Apple от Адама Левенталя, который работал над этим проектом в компании: ZFS: Apple’s New Filesystem That Wasn’t

Тогда Sun переживала трудные времена, и Oracle воспользовалась моментом для покупки компании. Это посеяло новые сомнения о будущем ZFS, поскольку Oracle известна как не большой любитель широкой общественной поддержки свободных проектов. А лицензия CDDL, которую Oracle применила к коду ZFS, признана несовместимой с GPLv2, которая используется в Linux, что делает невозможным использование ZFS в самой популярной в мире ОС для серверов.

Хотя проект OpenSolaris продолжился и после приобретения Oracle, а ZFS включили во FreeBSD, но это было в значительной степени за пределами корпоративного сектора. Конечно, NexentaStor и GreenBytes помогли продвинуть ZFS в корпоративном секторе, но недостаток поддержки серверов Sun со стороны Oracle тоже начал влиять на ситуацию.

Какие проблемы у ZFS сейчас?

OpenZFS практически не отличается от той файловой системы, что была десять лет назад.

Многие продолжают скептически относиться к дедупликации, которая требует много дорогой памяти. И я действительно имею в виду дорогой: практически каждый ZFS FAQ однозначно требует наличия памяти только ECC и минимум 8 ГБ. По моему собственному опыту с FreeNAS, для активного маленького сервера с ZFS подойдёт 32 ГБ, а это стоит $200-300 даже по сегодняшним ценам.

И ZFS так и по-настоящему не приспособился к флеш-памяти, которая сейчас используется повсеместно. Хотя флеш можно использовать для кэшей ZIL и L2ARC, это сомнительное преимущество для систем с достаточным количеством RAM, и у ZFS нет настоящей функции гибридного хранилища данных. Смехотворно, что в документации ZFS повсеместно упоминаются несколько гигабайт флеш-памяти SLC, когда на рынке уже есть многотерабайтные диски 3D NAND. И никто не говорит о NVMe, хотя это стандарт для высокопроизводительых ПК.

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

  • Заменить абсолютно все диски в пуле на диски большей ёмкости (что классно, но дорого).
  • Создать дисковую последовательность с другим набором дисков (что может привести к несбалансированной производительности, избыточности и куче других потенциально глупых ошибок).
  • Построить новый пул и перенести туда наборы данных командой zfs send (так поступаю я, хотя тут свои хитрости).

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

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

Какие варианты?

Наверное, я представил ZFS не совсем в выгодном свете. Когда-то она была революционной, но сейчас начинает проявлять ограничения и выпадать из контекста современного мира с флеш-хранением данных. Так есть ли альтернативы?

В Linux несколько приличных диспетчеров томов и файловых систем, а большинство используют LVM или MD и ext4. Спецов по файловым системам очень порадовала Btrfs, которая сочетает в себе функции диспетчера томов и файловой системы в стиле ZFS, но с дополнительной гибкостью за пределами того, на чём шлёпнулась ReiserFS. И Btrfs действительно могла бы стать «ZFS для Linux», но не так давно разработка споткнулась, после ужасного прошлогоднего бага с потерей данных с рейдах RAID 5 и 6, и больше о них почти ничего не слышно. Но я по-прежнему думаю, что через пять лет буду рекомендовать пользователям Linux использовать Btrfs, особенно с её мощным потенциалом для применения в контейнерах .

Для Windows компания Microsoft тоже собирается выкатить собственную файловую систему нового поколения ReFS с использованием деревьев B+ (похоже на Btrfs), с сумасшедшим масштабированием и функциями стойкости и защиты данных . В сочетании со Storage Spaces, у Microsoft будет жизнеспособная система хранения следующего поколения для Windows Server, которая может даже использовать SSD и 3D-XPoint как уровень или кэш.

И есть ещё Apple, которая по слухам несколько раз меняла систему хранения, до того как остановиться на APFS , которая вышла в этом году в macOS High Sierra. APFS во многом похожа на Btrfs и ReFS, хотя реализована совершенно иначе, с большей ориентацией на пользователя. Уступая в некоторых сферах (пользовательские данные не проверяются контрольной суммой и не поддерживается сжатие), APFS - именно та система, которая нужна для iOS и macOS. И APFS - это последний гвоздь в гроб идеи «ZFS на Mac OS X».

В каждой из трёх основных ОС теперь есть файловая система нового поколения (и диспетчер томов). В Linux есть Btrfs, в Windows - ReFS и Storage Spaces, а в macOS есть APFS. FreeBSD вроде бы сохранила приверженность ZFS, но это незначительная часть рынка. И каждая система корпоративного уровня уже продвинулась намного дальше того, что может делать ZFS и системы корпоративного уровня на базе ZFS от Sun, Nexenta и iXsystems.

Но ZFS по-прежнему намного превосходит старые файловые системы для домашнего пользователя. Из-за отсутствия проверки целостности, избыточности и восстановления после ошибок NTFS (Windows), HFS+ (macOS) и ext3/4 (Linux) абсолютно не подходят для долговременного хранения данных. И даже ReFS и APFS из-за отсутствия проверки целостности не подходят там, где потеря данных неприемлема.

Позиция автора: используйте ZFS (пока)

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

В мире *nix-систем все более популярными становятся файловые системы ZFS и Btrfs. Популярность эта вполне заслуженна - в отличие от своих предшественников, они лишены некоторых проблем и имеют множество неоспоримых достоинств. А не так давно им присвоен статус стабильных. Все это и побудило написать данную статью.

WARNING!

Некоторые описываемые здесь команды способны необратимо уничтожить твои данные. Трижды проверяй введенное, прежде чем нажимать Enter.

Пожалуй, прежде чем перейти к практике, нужно дать некоторые пояснения, что собой представляют файловые системы нового поколения. Начну с ZFS. Эта ФС была разработана для Solaris и в настоящее время, поскольку Oracle закрыла исходный код, форкнута в версию OpenZFS. В дальнейшем под ZFS будет подразумеваться именно форк. Вот лишь некоторые из ключевых особенностей ZFS:

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

Btrfs начала разрабатываться в пику ZFS компанией Oracle - еще до покупки Sun. Я не буду описывать ее особенности - они в ZFS и Btrfs, в общем-то, схожи. Отличия же от ZFS таковы:

  • поддержка версий файлов (в терминологии Btrfs называемых поколениями) - есть возможность просмотреть список файлов, которые изменялись с момента создания снапшота;
  • отсутствие поддержки zvol, виртуальных блочных устройств, на которых можно разместить, к примеру, раздел подкачки, - но данное отсутствие вполне компенсируется loopback-устройствами.

Знакомство с ZFSonLinux

Для установки ZFSonLinux потребуется 64-разрядный процессор (можно и 32, но разработчики не обещают стабильности работы в таком случае) и, соответственно, 64-разрядный дистрибутив с ядром не ниже 2.6.26 - я использовал Ubuntu 13.10. Памяти тоже должно быть достаточно - не менее 2 Гб. Предполагается, что основные пакеты, необходимые для сборки и компиляции модулей и ядра, уже установлены. Накатываем дополнительные пакеты и качаем нужные тарболлы:

$ sudo apt-get install alien zlib1g-dev uuid-dev libblkid-dev libselinux-dev parted lsscsi wget $ mkdir zfs && cd $_ $ wget http://bit.ly/18CpniI $ wget http://bit.ly/1cEzO0V

Распаковываем оба архива, но сперва собираем SPL - слой совместимости с Solaris, а уж затем собственно ZFS. Отмечу, что, поскольку мы ставим свежайшую версию ZFSonLinux, DKMS (механизм, позволяющий автоматически перестраивать текущие модули ядра с драйверами устройств после обновления версии ядра) недоступен, и в случае обновления ядра придется собирать пакеты заново вручную.

$ tar -xzf spl-0.6.2.tar.gz $ tar -xzf zfs-0.6.2.tar.gz $ cd spl-0.6.2 $ ./configure $ make deb-utils deb-kmod

Прежде чем компилировать ZFS, нужно поставить хидеры, заодно поставим и остальные свежесобранные пакеты:

$ sudo dpkg -i *.deb

Наконец, собираем и ставим ZFS:

$ cd ../zfs-0.6.2 $ ./configure $ make deb-utils deb-kmod $ sudo dpkg -i *.deb


Перенос корневой ФС на ZFS с шифрованием и созданием RAIDZ

Предположим, ты хочешь получить безопасную, зашифрованную, но в то же время отказоустойчивую файловую систему. В случае с классическими ФС старого поколения тебе пришлось бы выбирать между шифрованием и отказоустойчивостью, поскольку эти вещи несколько несовместимы. В ZFS, однако, существует возможность «склеить» их между собой. Современная проприетарная реализация этой ФС поддерживает шифрование. Открытая реализация с версией пула 28 это не поддерживает - но ничто не мешает с помощью cryptsetup создать том (или несколько томов) LUKS и уже поверх них разворачивать пул. Что до отказоустойчивости ZFS, поддерживается создание мультидисковых массивов. Технология эта называется RAIDZ. Различные ее варианты позволяют пережить отказ от одного до трех дисков, и она, в силу некоторых особенностей ZFS, свободна от одного из фундаментальных недостатков традиционных stripe + parity RAID-массивов - write hole (ситуация с RAID 5 / RAID 6, когда при активных операциях записи и отключении питания данные на дисках в итоге отличаются).

INFO

Шифрование замедляет работу с данными. Не стоит его использовать на старых компьютерах.

Конечно, проще всего, если у тебя не стоит никакой системы - в этом случае заморачиваться придется меньше. Но живем мы не в идеальном мире, поэтому расскажу о том, как перенести уже установленную систему без раздела /boot на массив RAIDZ поверх томов LUKS.

Перво-наперво нужно создать сам этот раздел - без него перенос будет невозможен, поскольку система банально не загрузится. Предположим для простоты, что на диске имеется единственный раздел с Ubuntu, а хотим мы создать RAIDZ первого уровня (аналог RAID 5, для него требуется минимум три устройства, RAIDZ же больших уровней в домашних условиях смысла делать я не вижу). Создаем с помощью предпочитаемого редактора разделов два раздела - один размером 256–512 Мб, где и будет размещен /boot , и еще один, с размером не меньше текущего корневого, причем последнюю процедуру повторяем на всех трех жестких дисках. Перечитаем таблицу разделов командой

# partprobe /dev/disk/by-id/ata-VBOX_HARDDISK_VB203f5b52-a7ff5309

и создадим файловую систему (ext3) на разделе поменьше:

# mke2fs -j /dev/disk/by-id/ata-VBOX_HARDDISK_VB203f5b52-a7ff5309-part2 -L boot

Разумеется, в твоем случае идентификаторы жестких дисков будут другими. Вслед за этим нужно зашифровать раздел, на котором будет находиться том LUKS, и повторить эту процедуру для всех остальных разделов, на которых в конечном счете будет находиться массив RAIDZ:

# cryptsetup -h=sha512 -c=aes-cbc-essiv:sha256 -s=256 -y luksFormat /dev/disk/by-id/ata-VBOX_HARDDISK_VB203f5b52-a7ff5309-part3 # cryptsetup -h=sha512 -c=aes-cbc-essiv:sha256 -s=256 -y luksFormat /dev/disk/by-id/ata-VBOX_HARDDISK_VB2fdd0cb1-d6302c80-part1 # cryptsetup -h=sha512 -c=aes-cbc-essiv:sha256 -s=256 -y luksFormat /dev/disk/by-id/ata-VBOX_HARDDISK_VB781404e0-0dba6250-part1

Подключаем зашифрованные тома:

# cryptsetup luksOpen /dev/disk/by-id/ata-VBOX_HARDDISK_VB203f5b52-a7ff5309-part3 crypto0 # cryptsetup luksOpen /dev/disk/by-id/ata-VBOX_HARDDISK_VB2fdd0cb1-d6302c80-part1 crypto1 # cryptsetup luksOpen /dev/disk/by-id/ata-VBOX_HARDDISK_VB781404e0-0dba6250-part1 crypto2

И создаем пул ZFS:

# zpool create -o ashift=12 zroot raidz dm-name-crypto0 dm-name-crypto1 dm-name-crypto2

Следом создаем две вложенные друг в друга файловые системы:

# zfs create zroot/ROOT # zfs create zroot/ROOT/ubuntu-1310-root

Отмонтируем все файловые системы ZFS и устанавливаем некоторые свойства ФС и пула:

# zfs umount -a # zfs set mountpoint=/ zroot/ROOT/ubuntu-1310-root # zpool set bootfs=zroot/ROOT/ubuntu-1310-root zroot

Наконец, экспортируем пул:

# zpool export zroot



Перенос и конфигурация системы

Сначала копируем каталог /boot на нешифрованный раздел, чтобы следом установить туда загрузчик:

# mkdir /mnt/boot # mount /dev/disk/by-label/boot /mnt/boot # cp -r /boot/* /mnt/boot/ # umount /mnt/boot

После этого перенесем grub на отдельный раздел /boot , для чего добавим в /etc/fstab cтрочку

# <...> LABEL=boot /boot ext3 errors=remount-ro 0 0

Монтируем и перегенерируем конфиг grub:

# grub-mkconfig -o /boot/grub/grub.cfg

Для проверки перезагружаемся. Если все нормально, удаляем старое содержимое каталога /boot , не забыв предварительно отмонтировать раздел.

Пришло время клонировать Ubuntu. Весь процесс клонирования описан в полной версии статьи, которую можно найти на сайте ][, здесь же затрону некоторые тонкости, относящиеся к ZFS. Для нормальной загрузки с пула ZFS нужны некоторые скрипты initramfs. К счастью, изобретать их не нужно - они лежат на GitHub. Скачиваем репозиторий (все действия производим в chroot):

# git clone http://bit.ly/1esoc8i

И копируем файлы в необходимые места. Я внес единственную правку: вместо пула rpool поставил zroot. Теперь нужно записать hostid в файл /etc/hostid . Это нужно сделать из-за того, что ZFS портирована с Solaris, и слой совместимости требует его наличия:

# hostid >/etc/hostid

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

# mkinitramfs -o /boot/initrd.img-$(uname -r)-crypto-zfs

Раздел /boot должен быть подмонтирован.

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

# vi /etc/grub.d/40_custom menuentry "Ubuntu crypto ZFS" { # <...> linux /vmlinuz-3.11.0-14-generic boot=zfs rpool=zroot initrd /initrd.img-3.11.0-14-generic-crypto-zfs }

Запускаем update-grub , перезагружаемся, выбираем новый пункт меню и радуемся.

Тюнинг ZFS и полезные трюки c Btrfs

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

В случае же использования Btrfs никаких особых проблем не наблюдается. Тем не менее какие-то тонкости все же имеют место - в особенности если есть желание не просто «поставить и забыть», а задействовать новые возможности. О некоторых из них я и расскажу ниже.

Отключение изменения времени доступа к файлам и оптимизация для SSD-накопителей

Как известно, в *nix-системах каждый раз при обращении к файлам время доступа к ним меняется. Это всякий раз провоцирует запись на носитель. Если ты работаешь одновременно с множеством файлов или у тебя SSD-накопитель, это может оказаться неприемлемым. В классических файловых системах для отключения записи atime нужно было добавить параметр noatime в опции команды mount или в /etc/fstab . В ZFS же для отключения используется следующая команда (конечно, в твоем случае ФС может быть другой):

# zfs set atime=off zroot/ROOT/ubuntu-1310-root

В Btrfs, помимо вышеупомянутой опции noatime, имеется опция ssd и более оптимизирующая ssd_spread. Первая из них начиная с ядра 2.6.31, как правило, устанавливается автоматически, вторая предназначена для дешевых SSD-накопителей (ускоряет их работу).

ZFS - дублирование файлов

При работе с очень важными данными порой возникает пугающая мысль, что отключат электроэнергию или выйдет из строя один из жестких дисков. Первое в российских условиях очень даже возможно, а второе хоть и маловероятно, но тоже случается. К счастью, разработчики ZFS, по-видимому, сталкивались с подобным не раз и добавили опцию дублирования данных. Файлы при этом, если возможно, размещаются на независимых дисках. Предположим, у тебя есть ФС zroot/HOME/home-1310 . Для установки флага дублирования набери следующую команду:

# zfs set copies=2 zroot/HOME/home-1310

Более того, если двух копий покажется недостаточно, можно указать цифру 3. В этом случае выполняется тройное резервирование и, если откажут два жестких диска из трех, на которых лежат эти копии, ZFS все равно восстановит их.

Отключение автомонтирования в ZFS

При подключении пула по умолчанию автоматом монтируются все вложенные файловые системы. Это может вызвать некоторый конфуз, поскольку, например, в случае с приведенной выше конфигурацией пользователю не нужен доступ ни к zroot , ни к zroot/ROOT . Существует возможность отключить автомонтирование с помощью двух следующих команд (для данного случая):

# zfs set canmount=noauto zroot/ROOT # zfs set canmount=noauto zroot

Сжатие данных

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

# zfs set compression=on zroot/ROOT/var-log

В Btrfs для включения сжатия нужно поставить опцию compress в /etc/fstab .

Автоматическое создание снапшотов в ZFS

Как известно, ZFS позволяет создавать снапшоты. Ручками, однако, их создавать лениво, да и есть вероятность попросту забыть об этом. В Solaris для автоматизации этой процедуры имеется служба Time Slider, но она - вот незадача! - хоть и использует функции ZFS, в ее состав не входит, поэтому в ZFSonLinux ее нет. Но огорчаться не стоит: имеется скрипт для автоматического их создания и для Linux. Скачаем его и установим нужные права:

# wget -O /usr/local/sbin/zfs-auto-snapshot.sh http://bit.ly/1hqcw3r # chmod +x /usr/local/sbin/zfs-auto-snapshot.sh

Изменим сперва префикс для снапшотов, поскольку по умолчанию он не особо «говорящий». Для этого изменим в скрипте параметр opt_prefix с zfs-auto-snap на snapshot . Затем установим некоторые переменные файловой системы:

# zfs set com.sun:auto-snapshot=true zroot/ROOT/ubuntu-1310-root # zfs set snapdir=visible zroot/ROOT/ubuntu-1310-root

Первый параметр нужен для скрипта, второй же открывает прямой доступ к снапшотам, что тоже нужно для скрипта.

Теперь можно уже создавать скрипт для cron (/etc/cron.daily/autosnap). Рассмотрим случай, когда нужно создавать снапшоты каждый день и хранить их в течение месяца:

#!/bin/bash ZFS_FILESYS="zroot/ROOT/ubuntu-1310-root" /usr/local/sbin/zfs-auto-snapshot.sh --quiet --syslog --label=daily --keep=31 "$ZFS_FILESYS"

Для просмотра созданных снапшотов используй команду zfs list -t snapshot , а для восстановления состояния - zfs rollback имя_снапшота.

ZFS - комплексный пример

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

# zfs create -o compression=on -o mountpoint=/usr zroot/ROOT/usr # zfs create -o compression=on -o setuid=off -o mountpoint=/usr/local /zroot/ROOT/usr-local # zfs create -o compression=on -o exec=off -o setuid=off -o mountpoint=/var/crash zroot/ROOT/var-crash # zfs create -o exec=off -o setuid=off -o mountpoint=/var/db zroot/ROOT/var-db # zfs create -o compression=on -o exec=off -o setuid=off -o mountpoint=/var/log zroot/ROOT/var-log # zfs create -o compression=gzip -o exec=off -o setuid=off -o mountpoint=/var/mail zroot/ROOT/var-mail # zfs create -o exec=off -o setuid=off -o mountpoint=/var/run zroot/ROOT/var-run # zfs create -o exec=off -o setuid=off -o copies=2 -o mountpoint=/home zroot/HOME/home # zfs create -o exec=off -o setuid=off -o copies=3 -o mountpoint=/home/rom zroot/HOME/home-rom

Дефрагментация Btrfs

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

# btrfs filesystem defrag /

На старых ядрах эта процедура удаляла все COW-копии, такие как снапшоты и дедуплицированные данные, так что, если ты их используешь на ядрах старше 2.6.37, дефрагментация тебе только навредит.

RAID на Btrfs

Как и в случае с ZFS, Btrfs поддерживает многотомные массивы, но в отличие от ZFS называются они классически. На данный момент, однако, поддерживаются только RAID 0, RAID 1 и их комбинация, RAID 5 по-прежнему на этапе альфа-тестирования. Для создания нового массива RAID 10 попросту используй такую команду (с твоими устройствами):

# mkfs.btrfs /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1

Ну а если нужно сконвертировать существующую ФС в RAID, то и для этого есть команды:

# btrfs device add /dev/sdb1 /dev/sdc1 /dev/sdd1 / # btrfs balance start -dconvert=raid10 -mconvert=raid10 /

Первая команда добавляет устройства к файловой системе, вторая же как раз и перебалансирует все данные и метаданные для преобразования этого набора томов в массив RAID 10.

Снапшоты Btrfs

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

# btrfs subvol snap -r / /.snapshots/2013-12-16-17-41

Подробнее о создании снапшотов, как ручном, так и автоматическом, можно прочитать в статье «Подушка безопасности», опубликованной в апрельском номере ][ за 2013 год. Здесь же я расскажу, как при наличии снапшота отследить, какие файлы изменились с момента его создания. Для этого в Btrfs есть так называемое поколение файлов. Возможность эта используется для внутренних целей, но есть команда, позволяющая смотреть список последних изменений - ею и воспользуемся. Сначала узнаем текущее поколение файлов:

# btrfs subvol find-new / 99999999

Если такого поколения нет (в чем можно практически не сомневаться), выведется последнее. Теперь эту же самую команду выполним над снапшотом:

# btrfs subvol find-new /.snapshots/2013-12-17-14-28 99999999

Если поколения будут отличаться, а они будут, то смотрим, какие же файлы изменялись со времени создания снапшота. В моем случае команда была следующей:

# btrfs subvol find-new / 96 | awk "{ print $17 }" | sort | uniq

NILFS2 - еще одна файловая система с поддержкой COW

Начиная с ядра 2.6.30 в Linux появилась поддержка еще одной ФС - NILFS2. Аббревиатура эта расшифровывается как new implementation of a log-structured file system. Основная особенность данной ФС заключается в том, что раз в несколько секунд в ней автоматически создаются чек-пойнты - примерный аналог снапшотов с одним отличием: спустя какое-то время они удаляются сборщиком мусора. Пользователь, тем не менее, может преобразовать как чек-пойнт в снапшот, в результате чего для сборщика мусора он становится невидимым, так и наоборот. Таким образом, NILFS2 можно рассматривать как своеобразную «Википедию», где фиксируются любые изменения. Из-за этой особенности - писать любые новые данные не поверх существующих, а в новые блоки - она прекрасно подходит для SSD-накопителей, где, как известно, перезапись данных не приветствуется.

Да, NILFS2 не настолько известна, как ZFS или Btrfs. Но в некоторых случаях ее применение будет более оправданным.

Заключение

Может быть, я покажусь субъективным, но ZFS, если ее сравнивать с Btrfs, выигрывает. Во-первых, некоторые возможности Btrfs до сих пор находятся в зачаточном состоянии, несмотря на то, что ей уже более пяти лет. Во-вторых, ZFS, при прочих равных условиях, более обкатана. И в-третьих, как просто инструментов для работы с ZFS, так и ее возможностей больше.

С другой стороны, как бы ни была хороша ZFS, по лицензионным соображениям она вряд ли когда-нибудь будет включена в mainline kernel. Так что, если не появится какой-нибудь еще конкурент, придется пользоваться Btrfs.

Facebook и Btrfs

В ноябре 2013 года лидер команды разработчиков Btrfs Крис Мейсон перешел на работу в Facebook. Это же сделал и Джозеф Бацик, мейнтейнер ветки btrfs-next. Они вошли в состав отдела компании, специализирующегося на низкоуровневых разработках, где и занимаются ныне ядром Linux - в частности, работают над Btrfs. Разработчики заявили также, что Facebook заинтересована в развитии Btrfs, так что причин волноваться у сообщества нет решительно никаких.