Подробнее

Основные преимущества:

• объединенное хранилище
• Copy-on-write
• снапшоты
• проверка цельности и автопочинка
• RAID-Z
• Максимальный размер файла дохерарх и макс размер хранилища считай что неограничен

объединенное хранилище
Это про совмещение возможностей ФС и менеджера дисков
ZFS может создать ФС охватив все диски, можно так же добавить хранилище в систему дисков. ZFS займется разделением и форматированием дисков

Copy-on-write
В отличии от большинства других ФС, тут новая инфа записывается в отдельный блок и как только запись завершена, метаданные обновляются к новой точке.
Это гарантирует что пока новая инфа корректно и полностью не запишется, старая инфа будет фиксирована
Не требуется запускать fsck после сбоя

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

Снимки могут быть смонтированы RO для восстановления старой версии файла, так же можно откатиться к предыдущему снимку, все изменения будут утрачены

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

RAID-Z
Работает с RAID без вспомогательного софта
Имеет собственную реализацию RAID - «RAID-Z», по сути это вариация RAID-5 с попыткой превзойти

Обсуждения тормознутости и жора ОЗУ

Огромное потребление памяти не прибито гвоздями — его легко можно регулировать переменной vfs.zfs.arc_max.
Можете поделиться источниками, откуда взялось утверждение про тормознутость? У нас весь прод, включая реляционную БД, и все личные домашние компы на ZFS. Проблем с тормознутостью не было. Все просто — если это файловое хранилище (для чего ZFS, собственно, и задумывалось) — не трогаем arc_max, если просто поиграться дома — ставим лимит и пользуем все плюшки (шифрование, сжатие, снепшоты и т.п.) в удовольствие, без перерасхода памяти.

Так у каждого инструмента есть свои задачи и требование как следствие ниша. Я не совсем понимаю какой и в чем ваш High load. Но, обратите внимание на особенности, упомянутые в статье, и вы поймете что эта ФС для NAS/SAN и тому подобному использованию. Это ФС для данных где не нужна «спешка», зато в этом классе у нее почти нет конкурентов.
Поэтому она не «тормознутая», а это вы ее не там использовали и сделали таки еже выводы.

Еще замечания

Напомню всем, что, создав единожды vdev в ZFS вы больше не можете с ним сделать ничего: ни добавить диск, ни удалить, ни поменять сдохший диск на диск большего размера: все эти операции требуют одновременного форматирования всех дисков сразу. Поэтому для мелких нужд ZFS очень плохо подходит — дома и в мелком офисе можно столкнутся с проблемой при апгрейде, потому что временно скинуть куда-либо все данные очень неудобно. И долго.
Адепты ZFS на /r/DataHoarder любят замалчивать этот факт и навязывать ZFS тем, кто строит свою первую файлопомойку для дома. А потом у людей проблемы: построить новый сервер оказывается дешевле, чем добавить места в старый.

Преимущества

Целостность и консистентность - ZFS сделан для максимальной надежности. По умолчанию на все данные подсчитываются контрольные суммы, а для метаданных записываются минимум по две копии в разных местах диска

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

Атомарность - благодаря надежности ФС можно отказаться от WAL журналов приложений, но получается что приложение должно уметь работать с этими транзакциями ФС, просто выключить журнал видимо не получится :))
Так же, приложение может использовать эти журналы еще для чего нибудь, но в целом есть пространство для маневра
В целом, работа через дерево Меркла не бесплатна конечно, постоянные подсчеты хеш сумм отнимают процессорное время, но с другой стороны здесь экономия на собственном журнале, ну и упор на надежность все таки

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

Аналогия с mdadm

В классическом понимании mdadm, чтобы собрать Raid10 (набор мирроров), нужно сделать несколько Vdev Mirror и объединить их в один пул

Логические элементы ZFS

Делятся на 3 подсистемы

• SPA (Storage Pool Allocator) - отвечает непосредственно за нарезку на диски, хранение данных на диске. Этот элемент отвечает за то, куда кладется конкретный блок данных, но с абстракцией от диска. Когда мы к нему обращаемся, то видим единое пространство, вне зависимости от набора конкретных Vdev
• DMU (Data Management Unit) - на этом уровне ZFS представляется обычным объектным хранилищем. Есть реализации когда ее так и используют, т.е. далее накручивают свой слой поверх этого
• DSL (Data and Snapshot Layer) - пользуется предыдущим слоем. Занимается непосредственно файловыми системами, снапшотами, т.е. логикой, которая реализует POSIX-совместимую ФС (в него входит слой ZPL (ZFS POSIX Layer))

Подробнее

У классического page cache Linux есть проблема «вымывания»: если прочесть файл, размер которого превышает объем оперативной памяти, то старые данные из кеша вымоются, т.к. файл по умолчанию будет загружен в page cache

ARC - это умная замена page cache
Когда создавался ZFS, часто использовали жесткие диски, а у них маленькие IOPS. Чтение copy-on-write данных - по умолчанию случайная операция, чтобы ее ускорить, используют разные ухищрения, например аккумулируют данные, записывают большим блоком и так далее, но это не всегда срабатывает, на этот случай нужно умное кеширование
Нормально если при штатной работе 99% запросов чтения попадает в кэш, если меньше то что то не так, стоит добавить оперативной памяти

Если ARC не всегда помещается в память, есть варианты вынести кэш на более быстрый отдельный SSD - это называется L2ARC (Layer 2 ARC)

Подробнее

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

Использование

Блоки типа ARC,ZIL и тд это не диски, которые мы можем использовать, это понятия виртуальные, они всегда есть в ZFS. Есть возможность вынести их на более быстрые носители

ZIL можно вынести на т.н. Slog, которому не нужно быть большим, т.к. синхронная запись обычно идет мелким блоком и быстро сбрасывается на основное хранилище. Т.е. важно как можно быстрее записать конкретный блок и отрапортовать клиенту об успешной записи, а не записать как можно больше данных.
Slog нужен для чтения только при сбое питания

ARC можно дополнить одним или более SSD и выгружать на него определенный вид данных, например, кэшировать только метаданные или данные, которые последовательно или случайно прочитались с основного хранилища

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

Можно оптимизировать любой профиль нагрузки, начиная от размера блока
Например когда хотим оптимизировать copy-on-write то можем писать бОльшим блоком чем в классических ФС, для ZFS по умолчанию принят объем в 128КБайт на блок

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

Второй момент, в случае аппаратного решения, настройка размеров блока, страйпов и пр делается единожды и не меняется

В ZFS же, в рамках одного пула можно создавать несколько датасетов и каждый настраивается персонально
Датасет - отдельная ФС со своими настройками. К примеру, для СУБД можно создать отдельное пространство под основные данные с размером блока 8КБайт и отдельный датасет, оптимизированный для WAL-лог с размером 16КБайт.
Хочется сжимать данные ? - «zfs set compression=on», другие данные читаются очень редко и могут вымывать ARC ? - «zfs set primarycache=metadata«

Имея один пул, можно настраивать под конкретную операцию хоть каждый датасет, мы максимально подстраиваемся под приложения

ZFS пространство разрезано на т.н. metaslabs, которые ведут трекинг того, какие сектора свободны, а какие заняты. Это происходит на уровне SPA слоя, который работает с дисками

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

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

По умолчанию на каждый Vdev создается ~200 meta-slabs. Это чем то похоже на WAL-лог БД

Существует Write Throttling мы можем использовать неограниченное кол-во оперативной памяти для подготовки tgx-группы и за счет этого переживать резкие скачки записи, буферизируя все в оперативную память.
Ес-но речь про асинхронную запись, когда мы можем себе это позволить, так можно последовательно и очень эффективно сложить данные на диск

Если синхронная запись и ее целостность не важна, например, у вас не большая и дорогостоящая PostgreSQL, а сервер на одного пользователя, то синхронную запись можно отключить командой «zfs set sync=disabled«

Т.о. собрав пул из HDD, можно ими пользоваться как дешевыми SSD с точки зрения IOPS
Сколько IOPS даст оперативная память, столько и будет. При этом целостность ZFS обеспечивает в любом случае - при потере питания произойдет откат на последнюю целую транзакцию
В худшем случае теряется последние несколько сек записи, то что настроено в «tgx_timeout», по умолчанию до 5 сек и плюс на заданный размер

Управление памятью

В контуре управления памятью ядра Linux есть т.н. «сжиматели» (наверняка есть лучше перевод), (функции обратного вызова) которые вызываются подсистемами (например ZFS) для уменьшения используемой памяти
Работает в два этапа, сначала ядро спрашивает подсистему сколько памяти она может вернуть, затем просит ее сделать это

Базовый объем памяти который ARC может вернуть, представляет собой сумму «evictable» (mru,mfu,data,metadata) (фактически механизм более сложный) GH, разовый объем ограничивается zfs_arc_shrinker_limit (160Mb ?)

При каждом сжатии, ARC уменьшается на запрошенную ядром величину, «arc_no_grow устанавливается в true» - ???.
Если сжатие происходит с помощью «kswapd_Linux», то это косвенный механизм, увеличивается метрика «memory_indirect_count», если же процесс пытается выделить память а ее нет и напрямую запускает процесс освобождения, это прямой механизм, растет «memory_direct_count«
Собсна прямое освобождение указывает на проблему и является плохим состоянием