Подробнее

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

• объединенное хранилище
• 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)

Подробнее

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