zxcx

Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
====== ZFS Deep Info ======

===== Инфо =====
Zettabyte File System - ФС с деревом Меркла, от Sun Microsystems, создана в 2004-2005 гг для Solaris.\\
Поддерживает большие объемы данных, объединяет концепции файловой системы, массивов RAID, менеджера логических томов, принципы легковесных файловых систем, представляет простое управление томами хранения данных\\

<details>
<summary>:!: Подробнее</summary>
На момент создания была новаторской, есть открытая реализация "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 с попыткой превзойти\\


==== Из минусов ====
Требовательна к ОЗУ, хранит много кешей в памяти, поэтому требуется обычно много, пропорционально нагрузке конечно же\\
В случае дефицита памяти очень сильно падает производительность\\
Есть еще ф-я "дедупликации" тоже из этой серии, влияет на объем используемой памяти, вроде выключена по умолчанию\\
</details>


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


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

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


===== Еще описание =====
[[https://mcs.mail.ru/blog/zfs-arhitektura-osobennosti-i-otlichija|Источник]]\\

Плюсы ZFS в том, что он знает что и где лежит, группирует это и дает некоторые другие фишки, в частности безопасное хранение данных - эта ФС сделана с упором на целостность\\
Для достижения хотя бы близкой функциональности надо накрутить много слоев софта (LVM, mdadm, dm-integrity и еще). Что ес-но снижает надежность\\


==== Основы ====
ZFS это "copy-on-write" ФС, она никогда не перезаписывает данные. Мы всегда оперируем новым блоком, для обеспечения консистентности данных не нужен журнал, как в большинстве других системах\\
Сам по себе "copy-on-write" не гарантирует консистентность данных, но в основе работы ZFS лежит "дерево Меркла" (Хеш дерево). Благодаря тому что ZFS всегда использует атомарные транзакции и достигается постоянная консистентность.\\
Как и любой "copy-on-write" системе, нужно иметь на дисках запас свободного места, чтобы было куда записывать данные, которые всегда пишутся в новое место. К этому добавляется проблема порядка записи, дабы избегать фрагментации\\


<details>
<summary>:!: Преимущества</summary>
**Целостность и консистентность** - ZFS сделан для максимальной надежности. По умолчанию на все данные подсчитываются контрольные суммы, а для метаданных записываются минимум по две копии в разных местах диска\\


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


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


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


==== Архитектура ZFS ====
Есть набор дисков, над ними появляется абстракция в виде виртуального устр-ва (device). В терминологии ZFS это т.н. **Vdev** (virtual device)\\
Есть разные реализации Vdev: **mirror**, **raid-z**, так же скоро **dRaid**\\
т.е. как конкретно мы будем хранить данные - с упором на производительность или на объем, это ответственность **Vdev**\\
Из набора виртуальных устр-в составляется общий пул\\

<details>
<summary>:!: Аналогия с mdadm</summary>
В классическом понимании mdadm, чтобы собрать **Raid10** (набор мирроров), нужно сделать несколько Vdev Mirror и объединить их в один пул\\
</details>

Каждый **Vdev** это по сути **stripe**, т.е. отдельная виртуальная единица хранения\\
В рамках пула, каждый уникальный блок данных будет хранится только на одном Vdev\\
{{:linux:zfs:2023-10-28_14-13.png?direct&400|}}\\
{{:linux:zfs:2023-11-03_21-47.png?direct&400|}}\\

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

{{:linux:zfs:2023-10-28_14-15.png?direct&400|}}\\
| {{:linux:zfs:2023-10-28_14-25.png?direct&400|}} | {{:linux:zfs:2023-10-28_14-25_1.png?direct&400|}} |\\
</details>


==== ZFS Arch ====
**ARC (Adaptive Replacement Cache)** - разработан чтобы решить проблему с чтением.\\
Примечателен тем что делает упор не только на последние объекты (LRU-cache) но и на часто используемые объекты (MFU-cache)\\

<details>
<summary>:!: Подробнее</summary>
У классического **page cache Linux** есть проблема "вымывания": если прочесть файл, размер которого превышает объем оперативной памяти, то старые данные из кеша вымоются, т.к. файл по умолчанию будет загружен в page cache\\

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

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


==== ZIL (ZFS intent log) ====
Есть своего рода журнал, для того чтобы "набить" каждую транзакцию максимальным кол-вом данных\\
Этот журнал обычно очень маленький, его записью и занимается **ZIL**\\

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

**ARC и ZIL** хотя и необязательные с технической стороны компоненты, но они нужны для обеспечения высокой производительности хранилища, без них система будет работать медленнее\\
ZFS в продакшене чаще применяют для крупных инсталляций хранилища данных. Архитектура подразумевает эффективную утилизацию большого кол-ва HDD, SSD, RAM, CPU\\

<details>
<summary>:!: Использование</summary>
Блоки типа ARC,ZIL и тд это не диски, которые мы можем использовать, это понятия виртуальные, они всегда есть в ZFS. Есть возможность вынести их на более быстрые носители\\

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

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



===== Паттерны использования =====
ZFS это локальное хранилище, по умолчанию подразумевается хранилище в рамках одного хоста\\

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

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


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

Главный плюс в том что ZFS может очень гибко подстраиваться под систему/задачи, оч важный момент\\

<details>
<summary>:!: </summary>
Во первых это то что метаданные пишутся в начале каждого диска, в случае с переездом достаточно просто подключить диск в другой сервер, главное чтобы версия ZFS была совместимая, ненадо даже соблюдать никакой порядок, система сама все обнаружит и соберет\\

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

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

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


===== Особенности работы ZFS =====

**Фрагментация данных**\\
В copy-on-write системе постоянно появляются новые блоки, а старые не всегда пригодны к удалению\\
<details>
<summary>:!: </summary>
ZFS пространство разрезано на т.н. **metaslabs**, которые ведут трекинг того, какие сектора свободны, а какие заняты. Это происходит на уровне SPA слоя, который работает с дисками\\

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

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

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


**Запись данных**\\
По умолчанию чтение данных в ZFS практически всегда является случайным, но т.к. мы пишем каждый раз в новое место, то можем превращать случайную запись в практически последовательную\\
Если нужна система хранения под запись и редкое чтение, то любая copy-on-write система будет отличным решением\\
Данные пишутся группами транзакций (tgx, transaction groups), можно агрегировать информацию в рамках этих групп\\

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

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

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



===== ARC =====
Adaptive Replacement Cache (Кэш адаптивной замены)\\

<details>
<summary>:!: Некоторая статистика</summary>
[[https://utcc.utoronto.ca/~cks/space/blog/linux/ZFSOnLinuxARCMemoryStatistics|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. Тут просто раскрывается некоторая информация поэтому необязательно отображает всю освобождаемую память\\
</details>


<details>
<summary>:!: Управление памятью</summary>
В контуре управления памятью ядра Linux есть т.н. "сжиматели" (наверняка есть лучше перевод), (функции обратного вызова) которые вызываются подсистемами (например ZFS) для уменьшения используемой памяти\\
Работает в два этапа, сначала ядро спрашивает подсистему сколько памяти она может вернуть, затем просит ее сделать это\\

Базовый объем памяти который ARC может вернуть, представляет собой сумму "**evictable**" (mru,mfu,data,metadata) (фактически механизм более сложный) [[https://github.com/openzfs/zfs/blob/master/module/os/linux/zfs/arc_os.c#L135|GH]], разовый объем ограничивается [[https://openzfs.github.io/openzfs-docs/man/master/4/zfs.4.html#zfs_arc_shrinker_limit|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**", что является редкостью видимо\\
</details>


<details>
<summary>:!: Еще про сокращения памяти</summary>
[[https://utcc.utoronto.ca/~cks/space/blog/linux/ZFSOnLinuxARCTargetSizeChanges|Doc]]\\

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

Сокращение может быть вызвано т.н. "жатвой" ("**Reaping**"), это общая ф-я ZFS, при которой выделенный поток ядра просыпается по крайней мере раз в секунду и проверяет не стала ли "**memory_availabel_bytes**" отрицательной\\
Если так то ZFS ставит "**arc_no_grow**" и запускает процесс освобождения памяти, уменьшая целевой размер ARC на 
<code bash>
((arc_c - arc_c_min) / 128) - memory_available_bytes
</code>
Процесс может быть вызван и немедленно при считывании очередного блока в память ZFS, после проверки "**memory_available_bytes**" на отрицательность\\

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

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

</details>



<details>
<summary>:!: Про размеры </summary>
[[https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSARCItsVariousSizes|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" и не указывается явно\\

<code bash>
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
</code>
</details>


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

<details>
<summary>:!: </summary>
Хоть L2 и пишется на диск, данные на нем не выдерживают перезагрузку, т.к. индексы этих данных разрушены\\

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

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

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

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

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



<details>
<summary>:!: </summary>

</details>



===== ZIL =====
Кэш используется не только для чтения но и для записи, применяя т.н. "**Целевой журнал (ZIL, ZFS Intent Log)**"\\
Каждый пул имеет свой собственный ZIL\\

<details>
<summary>:!: </summary>
ZFS накапливает данные в этом журнале в т.н. **группы транзакций (txgs, transaction groups)**, затем, при наполнении достаточного объема либо по таймауту, txgs записывается на диск\\

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

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

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

</details>


<details>
<summary>:!: Выделение отдельного устр-ва</summary>
Отдельное устр-во называется "SLOG (Separate Intent Log)", перемещая ZIL на отдельное устр-во вы избегаете записи одних и тех же данных дважды на одного поставщика хранения (все таки ZIL похоже применяется, точнее пишется на диск, только в случае синхронной записи, это когда приложение ждет от ядра подтверждения записи данных, вот он и записывает их, ф-я подтверждения это стандартная ф-я, типа fsync(), полагаю разрабам пришлось сделать такой финт для поддержки этого функционала\\
Однако есть момент, при монтировании ФС есть флаги запрещающие синхронную запись, тогда подтверждение будет ложным и мгновенным)\\

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

метрика "**dirty_data_max**" похоже связана с размером ZIL\\


</details>



===== Производительность =====
[[http://onreader.mdl.ru/AdvancedZFS/content/Ch08.html|Doc]]\\
Обычно имеется четыре основных ресурса:\\
  * **В/В системы хранения**
  * **Пропускная способность сети**
  * **Оперативная память**
  * **ЦП**

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

<details>
<summary>:!: </summary>
Например сжатие ZFS уменьшает объем записываемых и считываемых данных, за счет процессорного времени, если оно в избытке конечно же, это частая возможность бустанутся\\




</details>



<details>
<summary>:!: </summary>


</details>











<details>
<summary>:!: </summary>

<code bash>

</code>
</details>



<details>
<summary>:!: </summary>

<code bash>

</code>
</details>
zxcx

Инструменты пользователя

Инструменты сайта

Инструменты страницы
