Революция ZFS. Около 2006 года
В своих статьях о FreeNAS я настойчиво повторял, что «ZFS — самая лучшая файловая система», но если вы посмотрите мои сообщения в социальных медиа, то станет ясно, что мне она на самом деле не совсем нравится. Я пришёл к выводу, что такое противоречие требует объяснения и контекста, так что рискнём потревожить фанатов ZFS и сделаем это.
Когда ZFS впервые появилась в 2005 году, она была абсолютно своевременной, но она застряла там до сих пор. Разработчики ZFS сделали много правильных вещей, объединив лучшие функции диспетчера томов с файловой системой «зеттабайтного масштаба» в Solaris 10:
- ZFS достигла такого уровня масштабируемости, который должна иметь каждая современная файловая система, практически без ограничений на количество данных и метаданных и размер файлов.
- ZFS проверяет контрольные суммы всех данных и метаданных для обнаружения повреждёний, это совершенно необходимая функция для долговременного крупномасштабного хранения данных.
- Когда ZFS выявляет ошибку, то может автоматически восстановить данные с зеркал, блоков чётности или альтернативных мест хранения.
- В систему встроены зеркалирование и RAID-Z, за счёт чего многочисленные накопители органично объединяются в один логический том.
- ZFS имеет надёжные функции для подготовки снапшотов и зеркал, в том числе возможность пошагово обновлять данные на других томах.
- Данные можно сжимать на лету, также поддерживается дедупликация.
Когда появилась ZFS, это была революционная система, по сравнению со старыми диспетчерами томов и файловыми системами. И Sun открыла бoльшую часть исходного кода ZFS, позволив портировать её на другие операционные системы. Как любимая игрушка всей индустрии, ZFS быстро появилась на Linux и FreeBSD, и даже Apple начала внедрять её как часть файловой системы следующего поколения в Mac OS X! Будущее казалось таким светлым!
Контрольные суммы для пользовательских данных необходимы, иначе вы неизбежно потеряете данные: «Почему в больших дисках требуется проверка целостности данных» и «Первая директива систем хранения: не терять данные»
С 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[1], и жалуется, если они всё равно выбирают такую схему.
Всё это может показаться мелкими, незначительными придирками, но в совокупности они субъективно отправляют ZFS в средние века, после использования Drobo, Synology или современных облачных систем хранения. С ZFS вам нужно «купить диски, много памяти, создать RAID-массив и никогда его больше трогать», что не совсем соответствует современному использованию систем хранения[2].
Какие варианты?
Наверное, я представил ZFS не совсем в выгодном свете. Когда-то она была революционной, но сейчас начинает проявлять ограничения и выпадать из контекста современного мира с флеш-хранением данных. Так есть ли альтернативы?
В Linux несколько приличных диспетчеров томов и файловых систем, а большинство используют LVM или MD и ext4. Спецов по файловым системам очень порадовала Btrfs, которая сочетает в себе функции диспетчера томов и файловой системы в стиле ZFS, но с дополнительной гибкостью за пределами того, на чём шлёпнулась ReiserFS. И Btrfs действительно могла бы стать «ZFS для Linux», но не так давно разработка споткнулась, после ужасного прошлогоднего бага с потерей данных с рейдах RAID 5 и 6, и больше о них почти ничего не слышно. Но я по-прежнему думаю, что через пять лет буду рекомендовать пользователям Linux использовать Btrfs, особенно с её мощным потенциалом для применения в контейнерах[3].
Для Windows компания Microsoft тоже выкатывает собственную файловую систему нового поколения ReFS с использованием деревьев B+ (похоже на Btrfs), с сумасшедшим масштабированием и функциями стойкости и защиты данных[4]. В сочетании со 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 единственным заслуживающим доверия инструментом для хранения данных за пределами корпоративных систем хранения. В конце концов, надёжное хранение данных — это единственное, что действительно должна делать файловая система. Все мои важные данные сразу идут в ZFS, от фотографий до музыки, от фильмов до офисных файлов. Ещё нескоро я доверюсь чему-нибудь кроме ZFS!
Сноски
1. Для современных больших дисков предпочтительнее RAID-Z2 и RAID-Z3 с большей избыточностью.^
2. Странно, хотя множественные пулы и съёмные диски отлично работают на ZFS, почти никто не говорит о таком варианте использования. Всегда речь идёт об одном пуле под названием “tank”, который включает в себя все диски в системе.^
3. Одна вещь, которой по-настоящему не хватает в Btrfs — это поддержки флеш, и особенно гибридных систем хранения. Но лично я бы предпочёл, чтобы они сначала реализовали поддержку RAID-6.^
4. Хотя контрольные суммы для данных в ReFS по-прежнему отключены по умолчанию.^
Комментарии (66)
apro
01.08.2017 10:49Из-за отсутствия проверки целостности, избыточности и восстановления после ошибок ext3/4 (Linux) абсолютно не подходят
В ext4 есть контрольные суммы для метаданных, и она же журналируемая поэтому конечно есть восстановление после ошибок.
iskatel
02.08.2017 01:53именно! контрольные суммы — только _для метаданных_, опционально (и только в относительно свежих версиях), точно так же сделано в xfs (тоже в свежих).
контрольных сумм для просто данных — нет ни там, ни там.
В mdadm точно так же — нет.
Linux software RAID is not going to protect you from bit corruption and silent data corruption is a well known issue with it. In fact, if the kernel is able to read the data from one disk it would never know that it is bad. The RAID only kicks in if there is an I/O error when reading the data.
Loki3000
01.08.2017 11:07А не слишком ли жирно «минимум 8Гб» для домашней файлопомойки? Я понимаю что энтузиастов много, но все же для домашних задач, как правило, хватает и более скромного железа.
Dmitry_5
01.08.2017 11:48-1У меня 2 гб и ntfs. Обычно память пуста, где-то 1.5 гб выделено под файловый буфер (видно по графику копирования с ssd на nas)
lobzanoff
01.08.2017 12:21У меня на работе среди прочего есть NAS Thecus, в последней прошивке появилась ZFS и, поддаваясь на сладкие речи коллеги Linux-гуру, решил поставить ее. А памяти то там был 1 гиг, кто ж знал… Таких тормозов, а часто и вислова, я не видал давно… Добавления памяти до 4 гиг не помогло. Мало того, что все тормозило, так и некоторые файлы и папки заблокировались, так что копирование с него данных для последующего снесения нафиг и переформатирования под ext4 привело к некоторой потере. Благо это была файлопомойка и хранилище некритичных и дублируемых в другом месте бэкапов, так что не очень расстроился. Теперь вот стоит ext4 и 2 гига памяти. Все летает, тьфу тьфу тьфу
man55
01.08.2017 22:06+3NAS4FREE на плате Intel D525MW, Atom525, 2*1G памяти, два диска 5400 оборотов, зеркало на zfs.
Сценарий использования — бэкапы, файлопомойка, торренты скрещенные с miniDLNA сервером для телека.
Никаких зависонов и вообще проблем, аптайм месяцами.
Были глюки и отвалы при просмотре тяжелых фильмов, долго искал причины и ругался на zfs, оказалось тупо битая память
iskatel
02.08.2017 01:49+1«минимум 8Гб» — на самом деле с запасом, просто с 8 работает быстрее. Минимум это при применении дедупликации, совершенно ненужной дома.
8Gb сегодня стоят недорого, особенно если вспомнить цену нескольких дисков в тот NAS и самого NAS.
Alexsandr_SE
02.08.2017 07:24Я на опыты создал на на стареньком 2-х ядерном ксеоне рейд zfs с дедупликацией (около 400гиг доступно) и 8 гигабайт памяти. Памяти мало. при некоторых операциях записи я получаю скорость работы около 1,5мб/с. Скорость чтения при таких ситуациях всего несколько десятков кб/с. Процессор не нагружен. Эта файловая система как по мне может работать адекватно только на бекапы. Но стоит её расшевелить изменениями данных и минимальная скорость гарантирована.
iskatel
02.08.2017 20:58+1«создал на на стареньком 2-х ядерном ксеоне рейд zfs с _дедупликацией_» «и 8 гигабайт памяти» ну и кто вам доктор?
Alexsandr_SE
02.08.2017 22:01Для файлового хранилища более чем система. Для нагруженного хранилища zfs не годится. Сколько этой штуке понадобится памяти при 12 терабайтах и дедупликации? При любых настройках, включая работу без сжатия и дедупликации я не смог выжать скорости записи более 70мб и 60мб на чтение.
Сами накопители в конфигурации рейда (аналог рейд 10) способны выдать около 170мб/с.iskatel
03.08.2017 02:36но не для включенной дедупликации.
«При любых настройках, включая работу без сжатия и дедупликации я не смог выжать скорости записи более 70мб и 60мб на чтение.»
когда это было, с каким софтом, в каких условиях?Alexsandr_SE
03.08.2017 10:05Подключение через iSCSI, гигабитная сеть. Скорость чтения/записи больше всего по графику напоминают зубья пилы. Скорость небольшая (40мб/с), потом идет рост вверх, доходит пика (80-90мб/с) и опять падает до 40. Какое-то время держится и опять все с начала. Синхронная запись/чтение вообще заваливает чтение до нескольких мб/с в хороших условиях, в плохих там кб/с. В начале думал свич, но такое поведение получилось только под управлением NAS4Fre. К содалению не проверял на других файловых системах. Сама система старые серверок с 6-ю дисками.
iskatel
03.08.2017 18:58Сначала шла речь про дедупликацию, теперь появились iSCSI.
Эти вещи очень любят жрать ресурсы.
" Синхронная запись/чтение " это отдельная тема.
В общем, Ваши тесты — подтверждение тезиса, что включая «все фичи по максимуму», можно положить всё.Alexsandr_SE
03.08.2017 20:19Сейчас работает с дедупликацией. Объема памяти если верить тому, что есть в инете более чем достаточно. На практике маловато, но это машина для бекапа с ограниченным объемом, ночью времени хватает. Но скорость как писал при записи может достигать около 10мб/с или меньше, а синхронное чтение десятки кб/с.
Но и без дедупликации скорость не конек данной системы. К сравнению виндовс сервер с не страдает проблемой скорости. Может там фич меньше просто :)iskatel
04.08.2017 01:45«К сравнению виндовс сервер с не страдает проблемой скорости. Может там фич меньше просто :)»
Там тупо нет многих фич или же они сделаны примитивно.
Например, бэкап всего раздела на «живой», работающей NTFS — это практически полное замирание работы разделов, которые бэкапятся.
Сравните с Zfs snapshot.
«Сейчас работает с дедупликацией.… синхронное чтение десятки кб/с.»
Подозреваю, таки мало памяти.Alexsandr_SE
04.08.2017 09:33Zfs snapshot все же фича, а не просто копирование.
Я тоже думаю, что все упирается в память, но было написано мол 8 гигабайт хватает для 1 терабайта на носителе. По факту это оказалось не так. Файловый сервер скажем на zfs я бы не собирал. Может если будет когда возможность погонять машину с большим кол-ос памяти и посмотрю, но в стесненных условиях такая файловая система работает не лучшим образом.
gmelikov
04.08.2017 09:45Если хотите использовать дедупликацию, то рекомендую изучить требования к ОЗУ более подробно, там нет стандартного размера на 1тб, там есть примерно 320 байт ОЗУ на каждый блок (для dataset это recordsize).
Рекомендую прочитать этот комментарий, давал в нём методы точного расчёта требований.
Также добавлю, что ОЗУ требуется для записи, на чтение дедупликация не влияет (только если вы записываете параллельно с чтением, и при этом у вас кончилась ОЗУ, тогда для каждой операции записи будет много случайных IO чтения на диск).
ICELedyanoj
02.08.2017 11:58Домашний бэкап-сервер. FreeNas на HP DL G6 с 12 х 3ТБ хранилищем.
72Gb RAM.
При активной записи в хранилище можно заметить, как память забивается буквально на глазах. Кеш ZFS будет отъедать всю свободную память — к гадалке не ходи.AntiHelper
02.08.2017 20:04+1У Вас домашний датацентр???
CherryPah
07.08.2017 22:34+1с нынешними реалиями цен взять бу брендовое решение становится дешевле чем новую китайскую SOHO железяку.
Самой дорогой частью будут винтыICELedyanoj
08.08.2017 09:4920x3Tb Hitachi 7K2000, отработавших, судя по смарту, около 3-х лет в каком-то датацентре (счётчик включений был 20-30 за 3 года) обошлись чуть больше 1К у.е.
12 штук пошли в работу, 8 лежат как запасные. Вся железяка без винтов обошлась чуть больше 1.5К, вместе.
На мой взгляд — достаточно недорого, свои данные я ценю гораздо выше.
a0fs
03.08.2017 00:51В Linux нет, в FreeBSD прекрасно живёт на 2. Проблема с Linux — ZFS любит память ( в том смысле как любит её база данных), и дерётся за неё с системой, при этом не достаточно оперативно её освобождая. А интеграция этой ФС с Linux через такую-то матерь только добавляет эпичности сюжету. Когда ZFS вписана в систему, всё становится несколько проще.
poxvuibr
03.08.2017 09:54А интеграция этой ФС с Linux через такую-то матерь только добавляет эпичности сюжету.
Насколько я понимаю, ZFS on Linux — такой же модуль ядра, как ext4 и другие.
a0fs
03.08.2017 20:08Почти. Там имеет место целый слой абстракции, делающий среду работы данного модуля слегка притянутой к Solaris. В результате на единицу массы там слишком много абстракций, а это чревато боком. К чести ZFS следует признать, что даже в этих условиях она работает отлично. Но нужно иметь в виду жадный до оперативы ARC, и выкручивать его максимумы так, чтобы оставалось приложениям и ещё немного для манёвров со стороны ОС.
BerliozNSK
11.08.2017 08:18Я не много не понимаю, буду рад за разъяснение:
Во FreeBSD zfs.ko тянет за собой в зависимостях opensolaris.ko. Для чего? Не для того же?
BerliozNSK
01.08.2017 11:13+3Соглашусь с автором, что у ZFS есть проблемы.
Но если посмотреть на СХД типа VNX или Celerra, то обнаруживается, что ZFS может больше, хотя та же Celerra стоила в 2010-м около четырех миллионов рублей. В тех задачах, в которых я использовал VNX и Celerra, мне не хватало на ZFS разве только что автотиринга, да Fibre Channel, хотя последнее решаемо, в принципе.
А в случае варианта с «бюджетной СХД» (компьютер в 3U корпусе и с ECC памятью), которая отдает LUN по iSCSI в ESXi, да файлы по SMB — ZFS это «то, что доктор прописал»
P.S. Сугубо личное мнение
hdfan2
01.08.2017 13:40+1которая может даже использовать SSD и 3D-XPoint как уровень или кэш.
Не совсем понятно, что имеется в виду под «уровнем». В оригинале «tier». Подозреваю (хотя и могу ошибаться), что имеется в виду «которая может даже использовать SSD и 3D-XPoint либо для хранения данных, либо в качестве кэша».
myemuk
01.08.2017 13:50Полгода назад поставил на ноутбуке btrfs. Или я ее неправильно настроил или наткнулся на баг, но лучше раздел не заполнять полностью. Даже после удаления файлов, свободного места больше не становится.
В первый раз я потратил много времени на очистку. Пришлось внешний хард форматировать в btrfs, добавлять в разделу и запускать команду balance. А после удалять его из набора, чтобы данные опять перекочевали обратно.
Возможно на серверах файловая система btrfs хороша, но на рабочих лошадках пока рановато ставить. Или постоянно проверять «реальное» свободное место командой «btrfs fi sh» В ближайшее время опять вернусь на ext4iborzenkov
01.08.2017 14:08Четыре года назад поставил btrfs на домашний сервер, правда тогда убунта еще на корень ее ставить не умела без бубна, так и работает — корень на reiser, а /data на btrfs
А два года назад на домашний, уже на корень.
На ноуте с покупки была ext4 так что не трогал.
Вроде с местом все ок показывает, и когда сервер забился на 100% проблем не было, просто потер и все ок.
Temtaime
02.08.2017 02:40Не имел проблем после полного(до последнего байта) заполнения btrfs, зато имел другие.
После удаления диска из raid 1 и добавления нового в процессе апгрейда — система перестала монтироваться. Попытки заставить её монтироваться всеми способами из мануалов, включая различные методы восстановления привели к потере части файлов. Смог спасти остальное только благодаря тому, что удалённый диск смонтировался в degraded состоянии.
С тех пор — больше не связываюсь с ней, перешёл на zfs. С контейнерами она, кстати, отлично дружит в связке с proxmox ve.mpolk
02.08.2017 16:28А я, напротив, успешно использую btrfs в продакшне (в виде raid1). Как для системных томов физических серверов, так и в качестве хранилища данных netflow. В последнем случае хранилище представляет собой сборище довольно разнокалиберных потребительских (неэнтерпрайзовых) винчестеров, и именно этот вариант использования доставляет наибольшее удовольствие. Дешевые диски по мере износа тихо сыпятся — это заметно, только если глядеть на счетчики ошибок. Время от времени негромко умирают. Данные при этом не теряются, нетфлоу собирается бесперебойно. Я не спеша заменяю умерший винчестер, и жизнь продолжается. В общем RAID в своем исконном первоначальном смысле (Redundant Array of INEXPENSIVE Disks). По сравнению с тем, как тот же процесс выглядел, когда я пытался осуществлять его на классическом линуксовом raid-е — просто небо и земля. На mdraid-е были крики, обмороки, деградировавшие массивы, изредка потеря данных и т.п.
RAID выше первого я не пробовал (боюсь). RAID1 работает несколько лет на нескольких серверах без каких-либо проблем на Ubuntu 14.04 (ядра 3.13, 3.19 и 4.4 от Убунту) и Oracle Linux UEK3/4 (ядра 3.8 и 4.1 с многочисленными Оракловскими патчами и бэкпортами). Попытка сделать то же самое на ядре 3.10 в Centos 7 привела к довольно скорому развалу массива. Кое-как удалось собрать его и срочно мигрировать на mdraid + ext4. В Центосовском ядре btrfs, насколько я понимаю, какой-то недоделанный.
Shatun
01.08.2017 14:25Для Windows компания Microsoft тоже собирается выкатить собственную файловую систему нового поколения ReFS с использованием деревьев B+ (похоже на Btrfs), с сумасшедшим масштабированием и функциями стойкости и защиты данных
ReFS уже давно есть в серверных редакциях ПО(по-моему с вин сервер 2012), уже есть и в вин10, не уверен правда мб пока только в инсайдерских сборках.erty
01.08.2017 15:10ReFS сильно не хватает прозрачного сжатия файлов. Вот уж не знаю почему они не смогли это реализовать. Но как-раз на файлопомойках очень часто бывает необходима эта фича.
VitalKoshalew
01.08.2017 15:37Тут ошибка перевода: в оригинале "...Microsoft is busy rolling out their own next-generation filesystem. ReFS uses B+ trees...".
svanichkin
01.08.2017 15:53APFS хуже? Ну, судя по заголовку?
akzhan
02.08.2017 20:59Там нет защиты данных от повреждения, точно также, как в большинстве файловых систем по умолчанию.
Для обычного домашнего компьютера это ОК.
Да и вообще, почему этим должна заниматься файловая система?
P.S.: И таки она вышла только для iOS, для MacOS выйдет чуть позже, пока в бетах.
svanichkin
02.08.2017 23:08Как это нет защиты от повреждения? https://ru.wikipedia.org/wiki/Apple_File_System
2 Особенности
2.1 Снимки файловой системы
2.2 Шифрование
2.3 Целостность данных
2.4 Защита от сбоевakzhan
03.08.2017 12:33APFS не поддерживает контрольных сумм для данных, я слишком общо выразился.
Есть прекрасный обзор APFS с точки зрения разработчика ZFS.
VitalKoshalew
01.08.2017 17:30+2Называть клон NetApp-овского WAFL/ONTAP «революционным», мне кажется, не совсем корректно. Всё же стоит отдать дань уважения тем инженерам в NetApp, которые это всё изначально придумали. Как только истёк срок действия большинства патентов NetApp, подобные технологии стали разрабатывать все, кому не лень, о чём и говорится в статье.
Мне кажется, что с приходом SSD, актуальность WAFL-подобных файловых систем теряется: нет особой нужды гнаться за оптимизацией скорости случайной записи (ухудшая скорость линейного чтения за счёт фрагментации), когда можно использовать SSD для тиринга и кэша записи. Опять же, внутри всех без исключения SSD всё равно свой WAFL и прямого доступа к ячейкам/строкам SSD не предоставляет.
Подобная ситуация уже была в индустрии, когда выдающаяся по своим характеристикам HPFS от IBM на основе нормализованных двоичных деревьев с распределённым хранением метаданных канула в лету, как только оперативной памяти стало достаточно, чтобы закэшировать все «примитивные» табличные структуры FAT/NTFS.
Кроме оптимизации случайной записи, плюсами WAFL/ONTAP, и последующих клонов (в т.ч. ZFS) были:
- Сквозные контрольные суммы — в том или ином виде это будет внедрено со временем везде, о чём автор и упоминает. Прямой связи с WAFL-подобными системами у этой технологии нет — в оригинале NetApp заказывала SAS-диски с нестандартным размером сектора, на массовом рынке это невозможно, так что приходится выкручиваться, кто как может, в том числе и в не-WAFL-подобных системах.
- RAID-DP благополучно превратился в вариации на тему RAID-6 (RAID-Z2 etc) и стал уже стандартом de facto. Опять же, WAFL-подобное размещение для этого не обязательно.
- Снэпшоты реализованы на уровне систем виртуализации, а поскольку почти все нагрузки на сегодняшний день виртуализованы, реализация этого механизма на уровне дисковой подсистемы не так привлекательна, как раньше.
Как видно, основные «killer features» либо потеряли свою актуальность, либо реализуются вне зависимости от типа размещения данных. Но, безусловно, инженерам-первооткрывателям стоит сказать «Спасибо!», вот только большинство открытий было сделано в стенах NetApp, а не Sun.
[Disclaimer: за 100% историческую достоверность фактов не ручаюсь, писал по памяти. Если что неверно в описании, кто чей клон — пожалуйста представьте свою версию в комментариях, помню в своё время было много споров на этот счёт.].BasilioCat
01.08.2017 22:43+2Надо отдать должное NetApp — у них получился действительно инженерный шедевр, от железа до метрик. Вот только стоимость их решений доступна лишь очень жирным котам. Революционность ZFS в том, что Sun взяли годные идеи NetApp, и переписали их, избегая запатентованных технологий, и открыли исходники. Как-то давно примерно так поступил Торвальдс и GNU.
Так что скажем спасибо IBM за многомилионные мейнфреймы, благодаря которым у каждого есть дешевые компьютеры, скажем спасибо NetApp, что их разработки, окупившись в энтерпрайзе, пошли «в народ», и скажем «спасибо» Ораклу, похоронившему дальнейшую разработку ZFS, благодаря чему мы застряли в прошлом десятилетии с файловыми системами.
P.S.: Снапшоты при помощи систем виртуализации для файлового хранилища — это как-то странно. У решений поверх стандартных файловых систем они дадут значительно больший оверхед, у VMWare они интегрированы с файловой системой (=тот же подход, что у wafl/zfs)
spqr_voldi
02.08.2017 09:52Также в плюс репликация и создание клонов.
VitalKoshalew
02.08.2017 15:23И клоны средствами виртуализации делаются, хоть и не всегда так удобно, как в NetApp. Репликация в наше время есть у всех солидных СХД и даже просто в Windows (Storage) Server 2016, в Hyper-V она с 2012 года. Уже прогресс дальше пошёл — в сторону гиперконвергентных систем.
Но, для своего времени — да, это тоже были потрясающие инновации.
DaylightIsBurning
01.08.2017 19:55Мне кажется, следующим логичным развитием была бы унификация не только менеджера томов и ФС, но еще и менеджера распределённой ФС с многоуровневым tiering-ом и адаптивной репликацией. На данный момент что-то похожее пилят в lizardfs, есть коммерческие реализации.
vsb
01.08.2017 19:57+1Есть новая интересная система для Linux: bcachefs. Она пока в процессе разработки но в целом уже достаточно стабильна для «поиграться» или некритичных данных.
sanrega
02.08.2017 04:44Действительно ли важно наличие ЕСС-памяти для использования ZFS?
vsb
02.08.2017 09:26+1Наличие ECC-памяти важно для использования любой ФС. Если бит в памяти перевернётся и вы этого не заметите, то этот бит сохранится на диск, например испортив вам ваши бэкапы.
Alexsandr_SE
02.08.2017 09:54Как показывают сотни рабочих ПК регистровая память все же не настолько критична. У кучи контор сервера на обычном ПК и работают пока не разрушаются диски.
VitalKoshalew
03.08.2017 00:30+3А если перевернутся два бита, вы получите BSoD/kernel panic/etc. Часто вы видите такое на исправной памяти? Почему вероятность одиночного bit flip настолько выше двойного?
При этом я не агитирую за отказ от ECC — себестоимость девятого чипа памяти уже давно минимально влияет на цену серверной RAM. Есть — и ладно, всем спокойней, этакое плацебо.
Суть end-to-end checksum в ONTAP, ZFS и т.д. как раз в том, чтобы отследить ошибки на любом этапе, ведь кроме основного ОЗУ те же биты проходят через множество других подсистем, в которых информация тоже может повредиться.
Что касается именно связки ECC+ZFS, вот довольно интересная, на мой взгляд, статья: Will ZFS and non-ECC RAM kill your data?ildarz
03.08.2017 01:26-1Почему вероятность одиночного bit flip настолько выше двойного?
Потому что
гладиолустеорема умножения вероятностей.
vsb
09.08.2017 06:31> А если перевернутся два бита, вы получите BSoD/kernel panic/etc. Часто вы видите такое на исправной памяти? Почему вероятность одиночного bit flip настолько выше двойного?
Почему именно два? Можно и от одного бита его получить. Редки видим, потому что эти случаи редки в принципе и потому, что битов, которые могут вызвать BSOD довольно мало.
> Суть end-to-end checksum в ONTAP, ZFS и т.д. как раз в том, чтобы отследить ошибки на любом этапе, ведь кроме основного ОЗУ те же биты проходят через множество других подсистем, в которых информация тоже может повредиться.
Checksum тут не поможет, если бит испортится ещё до того, как по нему подсчитают checksum. Ну и checksum помогает только констатировать факт — блок испортился. Это лучше, чем не знать этого, но ещё лучше не доходить до такой ситуации.
vadikgo
02.08.2017 08:18+1В свете отказа RedHat от поддержки btrfs начиная с rhel 7, в Linux альтернатив zfs не остаётся.
dmitry_ch
02.08.2017 09:20+2Позиция автора: используйте ZFS (пока)
В статье много сравнений ZFS с другими ФС, но выбранные ФС, увы, почти все на тех ОС, где ZFS никак не получится использовать. Поэтому сравнение напоминает классику «ноги — крылья — хвосты», но не дает выбора.
Вместо NTFS уже давно было бы очень неплохо взять что-то поинтереснее. ZFS был бы просто идеальным вариантом (плюс, из-за массовости платформы, появилась бы тысяча утилит по более-менее обслуживанию ZFS). Но говорить, что NTFS устарела, а ZFS держится (пока), так что ее и надо использовать — это как-то нечестно.
Вот и вопрос, что советует автор: выбирать ОС, где работает ZFS, или как?
TFS (про которую уже выше написали) сейчас выглядит очень многообещающей. Ей бы прорваться в разные ОС — был бы просто праздник, но это такая огромная работа, что говорить о реальности сложно.
Один список целей TFS чего стоит!TFS is designed with the following goals in mind:
Concurrent
TFS contains very few locks and aims to be as suitable for multithreaded systems as possible. It makes use of multiple truly concurrent structures to manage the data, and scales linearly by the number of cores. This is perhaps the most important feature of TFS.
Asynchronous
TFS is asynchronous: operations can happen independently; writes and reads from the disk need not block.
Full-disk compression
TFS is the first file system to incorporate complete full-disk compression through a scheme we call RACC (random-access cluster compression). This means that every cluster is compressed only affecting performance slightly. It is estimated that you get 60-120% more usable space.
Revision history
TFS stores a revision history of every file without imposing extra overhead. This means that you can revert any file into an earlier version, backing up the system automatically and without imposed overhead from copying.
Data integrity
TFS, like ZFS, stores full checksums of the file (not just metadata), and on top of that, it is done in the parent block. That means that almost all data corruption will be detected upon read.
Copy-on-write semantics
Similarly to Btrfs and ZFS, TFS uses CoW semantics, meaning that no cluster is ever overwritten directly, but instead it is copied and written to a new cluster.
O(1) recursive copies
Like some other file systems, TFS can do recursive copies in constant time, but there is an unique addition: TFS doesn't copy even after it is mutated. How? It maintains segments of the file individually, such that only the updated segment needs copying.
Guaranteed atomicity
The system will never enter an inconsistent state (unless there is hardware failure), meaning that unexpected power-off won't ever damage the system.
Improved caching
TFS puts a lot of effort into caching the disk to speed up disk accesses. It uses machine learning to learn patterns and predict future uses to reduce the number of cache misses. TFS also compresses the in-memory cache, reducing the amount of memory needed.
Better file monitoring
CoW is very suitable for high-performance, scalable file monitoring, but unfortunately only few file systems incorporate that. TFS is one of those.
All memory safe
TFS uses only components written in Rust. As such, memory unsafety is only possible in code marked unsafe, which is checked extra carefully.
Full coverage testing
TFS aims to be full coverage with respect to testing. This gives relatively strong guarantees on correctness by instantly revealing large classes of bugs.
SSD friendly
TFS tries to avoid the write limitation in SSD by repositioning dead sectors.
Improved garbage collection
TFS uses Bloom filters for space-efficient and fast garbage collection. TFS allows the FS garbage collector to run in the background without blocking the rest of the file system.DaylightIsBurning
02.08.2017 14:43+1А что именно такого интересного заявлено среди целей TFS, чего не заявлено для ZFS/Brtfs? Tiering, которого не хватает в ZFS не заявлен, распределённость не заявлена.
Andronas
02.08.2017 13:07ZFS для домашних файловых хранилищ слишком сложна. Хотите надежности тогда храните минимум две копии данных в разных географически местах, и тип используемой ФС тут не при чем. Например для дома это локальное файловое хранилище и облако для копии.
ALexhha
02.08.2017 19:03+1А что именно такого интересного заявлено среди целей TFS, чего не заявлено для ZFS/Brtfs?
о Brtfs по ходу уже можно начать забывать. Признав ее deprecated RHEL как бы дает нам намек.
robert_ayrapetyan
03.08.2017 06:44+1Следует заметить, что Оракл в данный момент очень активно пилит ZFS под свои энтерпрайзные облачные сервера.
ildarz
На этот счет все было сказано еще в 1912 году — "Узок круг этих революционеров. Страшно далеки они от народа."
akardapolov
Там есть продолжение:
ZFS отличная система для хранения важных, нечастно изменяемых данных. Профиль нагрузки: записал один раз, читай всегда. Файловая система для ОС, ПО, backup-ы, файлопомойки.
iskatel
«для хранения важных, нечастно изменяемых данных»
А чем плохо для часто изменяемых?
ну кроме некоторого падения производительности и трэша при заполнении pool под завязку?
akardapolov
>> А чем плохо для часто изменяемых?
>> ну кроме некоторого падения производительности и трэша при заполнении pool под завязку?
На нагруженных системах некоторое будет переходить в критическое и ZFS будет висеть на выделенни свободного блока для операции изменения.