Подробнее

На момент создания была новаторской, есть открытая реализация «OpenZFS»
Обеспечивает полный контроль над физическими носителями и логическими томами и постоянное поддержание консистентности ФС.
Оперируя на разных уровнях абстракции данных ZFS способна обеспечить высокую скорость доступа к ним, контроль целостности. Позволяет в процессе работы менять объем дискового пространства и задавать разный размер блоков данных для разных применений. Обеспечивает параллельность выполнения чтения/записи

Собсна в открытом доступе есть именно «OpenZFS», он появился сразу после закрытия исходников первого, основан основателями ZFS
По сути из-за формальностей, OpenZFS распространяется под лицензией «CDDL» из за чего не может быть включена в ядро Linux по умолчанию, поэтому есть танцы с ее установкой, но в целом у каждой собаки есть инструкция как на нее поставить ZFS

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

• объединенное хранилище
• 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 сек и плюс на заданный размер

Некоторая статистика

Doc

ZFS сообщает некоторую информацию об ARC в /proc/spl/kstat/arcstats
Параметром размера является «arc_c». Который ARC считает целевым размером

Есть три метрики ОЗУ «memory_all_bytes», «memory_free_bytes» и «memory_available_bytes», общий, доступный и доступный для расширения ZFS объем оперативы, по мнению ZFS конечно же
Доступный ей объем может быть отрицательным, тогда ARC сжимается
«memory_availabe» это «memory_free» минус «arc_sys_free» (параметр, сколько ОЗУ нужно оставлять системе, по умолчанию 1/32, хотя говорится 1/64 от общего объема)

Может ли ARC расти в данный момент, показано в «arc_no_grow», равен 1 когда нет. Как правило включается и остается включенным если «memory_available» меньше 1/32 от «arc_c«
При приближении к этому значению ARC значительно замедляет рост, вроде как

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

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

В контуре управления памятью ядра 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«
Собсна прямое освобождение указывает на проблему и является плохим состоянием

ARC имеет ограничения на объем хранимых метаданных (как общие arc_meta_used так и для «dnode» dnode_size). Когда ARC сжимает метаданные, ему может потребоваться обрезать себя, заставив ФС освободить «dnodes» и другие вещи которые в данный момент удерживаются. В эти моменты увеличивается arc_prune (мнение что по одному на каждую смонтированную ФС)

Когда ARC удаляет данные, он может увеличивать две статистики, «evic_skip» и «evic_not_enough». Последняя выражает кол-во случаев когда при выселении не удалось выселить достаточно чтобы достичь целевой суммы.
Первое - «кол-во буферов, пропущенных из-за того что в них выполняется ввод-вывод, являются буферами косвенной предварительной выборки, которые просуществовали недостаточно долго или не принадлежат SPA, из которого пытаемся выселить»

«Anon» буферы которые не связаны с DVA, буферы в которых хранятся «грязные» (предварительные, полагаю) копии блоков, прежде чем они будут записаны в стабильное хранилище. Они считаются частью «arc_mru» которую нельзя освободить. Они получают DVA по мере их записи и мигрируют в «arc_mru»
В «Anon» хоть и есть статистика «evictable», она всегда равна нулю, т.к. эти данные не подлежат удалению

Некоторая часть подсчитанного здесь пространства может быть «отдана в аренду», отображается в метрике «arc_loaned_bytes«

В рамках настройки записи ZFS временно резервирует для них пространство ARC, о текущем резервировании сказано в «arc_tempreserve».
Общий объем «грязных» данных в ARC равен «arc_tempreserve» + «anon_size» - «arc_loaned_bytes«

Если ZFS решает ограничить выделение новой памяти для записи, увеличивается метрика «memory_throttle_count», что является редкостью видимо

Еще про сокращения памяти

Doc

Целевой и фактический размеры ARC здесь различаются, фактический обычно быстро вырастает до целевого

Сокращение может быть вызвано т.н. «жатвой» («Reaping»), это общая ф-я ZFS, при которой выделенный поток ядра просыпается по крайней мере раз в секунду и проверяет не стала ли «memory_availabel_bytes» отрицательной
Если так то ZFS ставит «arc_no_grow» и запускает процесс освобождения памяти, уменьшая целевой размер ARC на

((arc_c - arc_c_min) / 128) - memory_available_bytes

Процесс может быть вызван и немедленно при считывании очередного блока в память ZFS, после проверки «memory_available_bytes» на отрицательность

Путь «сжатия» вызывается с помощью общей функции управления памятью ядра Linux, это другой процесс освобождения ARC

При «жатве» часто немного уменьшается целевой размер ARC (300/400mb)
При каждом сжатии растет статистика «memory_direct_count» либо «memory_indirect_count», при «жатве» никакая статистика не увеличивается

Про размеры

Doc

Текущий общий размер указан в «arc_size». ARC и содержит «MRU» i «MFU», у которых так же есть метрики «size», но общий размер это не только сумма этих двух
В общем то содержит в себе «data_size», «metadate_size», «bonus_size», «dnode_size», «dbuf_size», «hdr_size», «l2_hdr_size», «adb_chuck_waste_size» (adb - сокращение от буферизированные данные)

Основу составляют «data_size» и «metadata_size«
«arc_meta_used» объединяет все (кроме data_size и adb_chuck_waste_size), которое по сути является метаданными в некотором смысле, это объединение важно поскольку регулируется «arc_meta_limit«

Даже если вы не включили сжатие для данных, ZFS может использовать его для метаданных. Для отражения этого есть метрики «compressed_size» и «uncompressed_size», второе показывает сколько данные весили бы если бы все было без сжатия

«overhead_size» данные хранящиеся во всех «arc_buf_t», классифицируется как накладные расходы т.к. они будут очищены как только на них перестанут ссылаться, если специально не задано иное

«arc_p» (сокращение от раздел) является целевым размером для «MRU».
Целевой размер «MFU» равен «c - p» и не указывается явно

c -> Is the total cache size (MRU + MFU)
p -> represents the limit of MRU
(c - p) -> represents the limit of MFU
c_max, c_min -> hard limits
size -> Total amount consumed by ARC

Хоть L2 и пишется на диск, данные на нем не выдерживают перезагрузку, т.к. индексы этих данных разрушены

Применение L2 становится существенным при наличии большого числа пользователей, приложений, вирт машин, имеющих доступ к одному и тому же набору данных
Если ваш рабочий набор больше чем объем памяти, вашим вторым шансом будет L2

Важный момент в том, что для обслуживания L2 так же используется память
Раз L2 содержит целый набор кэшированых данных и метаданных, индекс этих данных находится в основном ARC
Грубо говоря, каждый гигабайт L2ARC стоит 25Mb ARC (в частности зависит от размера секторов, св-ва recordsize и др. вещей), в реальности десятки гигов отнимает запросто

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

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

При нормальной работе ZFS пишет только 8Мб в секунду в каждое устр-во L2ARC. Это позволяет избегать преждевременного «высасывания» SSD и т.н. «пробуксовки» кэша
Параметр настраивается «vfs.zfs.l2arc_write_max»

ZFS накапливает данные в этом журнале в т.н. группы транзакций (txgs, transaction groups), затем, при наполнении достаточного объема либо по таймауту, txgs записывается на диск

Группа транзакций может содержать порции данных от разных, не связанных процессов
содержит «запросы на запись», порция данных и связанных с ФС метаданных

«ГТ» является списком «что делать», данные чувствительны к отказам системы пока они полностью не будут записаны на диск, в случае отказа ГП потеряется
Уменьшение таймаута может уменьшить объем потенциальной потери но плохо скажется на производительности

Касательно использования диска ZIL и записывания ZIL на диск, тут есть момент с синхронной/асинхронной записью данных
«Пул применяет ZIL только для синхронно- записываемых данных, асинхронные обычно сохраняются в оперативной памяти и фиксируются как часть регулярной группы транзакций»

Выделение отдельного устр-ва

Отдельное устр-во называется «SLOG (Separate Intent Log)», перемещая ZIL на отдельное устр-во вы избегаете записи одних и тех же данных дважды на одного поставщика хранения (все таки ZIL похоже применяется, точнее пишется на диск, только в случае синхронной записи, это когда приложение ждет от ядра подтверждения записи данных, вот он и записывает их, ф-я подтверждения это стандартная ф-я, типа fsync(), полагаю разрабам пришлось сделать такой финт для поддержки этого функционала
Однако есть момент, при монтировании ФС есть флаги запрещающие синхронную запись, тогда подтверждение будет ложным и мгновенным)

Дак вот, вынос на отдельное устр-во, если оно быстрее аппаратно, ну и запись единожды
Второй момент, отдельное устр-во это только устр-во, ZIL как таковая служба продолжает работать, просто на этом устр-ве, «ZIL» работает на «SLOG», если «SLOG» выходит из строя, ZIL автоматом переключается на основной пул, снова

метрика «dirty_data_max» похоже связана с размером ZIL

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