Различия

Показаны различия между двумя версиями страницы.

--- linux:zfs:deep_info [2023/10/28 07:47]
admin
+++ linux:zfs:deep_info [2023/11/04 17:06] (текущий)
admin [Производительность]
@@ Строка 4: / Строка 4: @@
 Zettabyte File System - ФС с деревом Меркла, от Sun Microsystems, создана в 2004-2005 гг для Solaris.\\
 Поддерживает большие объемы данных, объединяет концепции файловой системы, массивов RAID, менеджера логических томов, принципы легковесных файловых систем, представляет простое управление томами хранения данных\\
+<details>
+<summary>:!: Подробнее</summary>
 На момент создания была новаторской, есть открытая реализация "OpenZFS"\\
 Обеспечивает полный контроль над физическими носителями и логическими томами и постоянное поддержание консистентности ФС.\\
@@ Строка 10: / Строка 13: @@
 Собсна в открытом доступе есть именно "OpenZFS", он появился сразу после закрытия исходников первого, основан основателями ZFS\\
 По сути из-за формальностей, OpenZFS распространяется под лицензией "CDDL" из за чего не может быть включена в ядро Linux по умолчанию, поэтому есть танцы с ее установкой, но в целом у каждой собаки есть инструкция как на нее поставить ZFS\\
 Основные преимущества:\\
   * объединенное хранилище
@@ Строка 19: / Строка 22: @@
   * Максимальный размер файла дохерарх и макс размер хранилища считай что неограничен
+**объединенное хранилище**\\
-<details>
-<summary>:!: Подробнее</summary>
-=== объединенное хранилище ===
 Это про совмещение возможностей ФС и менеджера дисков\\
 ZFS может создать ФС охватив все диски, можно так же добавить хранилище в систему дисков. ZFS займется разделением и форматированием дисков\\
-=== Copy-on-write ===
+**Copy-on-write**\\
 В отличии от большинства других ФС, тут новая инфа записывается в отдельный блок и как только запись завершена, метаданные обновляются к новой точке.\\
 Это гарантирует что пока новая инфа корректно и полностью не запишется, старая инфа будет фиксирована\\
@@ Строка 33: / Строка 33: @@
-=== Снапшоты ===
+**Снапшоты**\\
 ZFS использует снапшоты для того чтобы следить за изменениями в файловой системе\\
 Снимок хранит оригинальную версию ФС и текущую, в которой все изменения с момента создания снимка\\
@@ Строка 40: / Строка 40: @@
 Снимки могут быть смонтированы RO для восстановления старой версии файла, так же можно откатиться к предыдущему снимку, все изменения будут утрачены\\
+**проверка цельности и автопочинка**\\
-=== проверка цельности и автопочинка ===
 Для всей информации в ZFS существует чек-сумма (дерево Меркла), создается при записи/изменении. При чтении она подтверждается, в случае не совпадения ZFS понимает ошибку и пытается ее исправить\\
-=== RAID-Z ===
+**RAID-Z**\\
 Работает с RAID без вспомогательного софта\\
 Имеет собственную реализацию RAID - "RAID-Z", по сути это вариация RAID-5 с попыткой превзойти\\
@@ Строка 59: / Строка 58: @@
 <details>
 <summary>:!: Обсуждения тормознутости и жора ОЗУ</summary>
 <code bash>
 Огромное потребление памяти не прибито гвоздями — его легко можно регулировать переменной vfs.zfs.arc_max.
@@ Строка 72: / Строка 70: @@
 **Еще замечания**\\
 <code bash>
 Напомню всем, что, создав единожды vdev в ZFS вы больше не можете с ним сделать ничего: ни добавить диск, ни удалить, ни поменять сдохший диск на диск большего размера: все эти операции требуют одновременного форматирования всех дисков сразу. Поэтому для мелких нужд ZFS очень плохо подходит — дома и в мелком офисе можно столкнутся с проблемой при апгрейде, потому что временно скинуть куда-либо все данные очень неудобно. И долго.
@@ Строка 78: / Строка 75: @@
 </code>
 </details>
@@ Строка 94: / Строка 90: @@
-==== Преимущества ====
 <details>
-<summary>:!: </summary>
+<summary>:!: Преимущества</summary>
 **Целостность и консистентность** - ZFS сделан для максимальной надежности. По умолчанию на все данные подсчитываются контрольные суммы, а для метаданных записываются минимум по две копии в разных местах диска\\
@@ Строка 119: / Строка 114: @@
 т.е. как конкретно мы будем хранить данные - с упором на производительность или на объем, это ответственность **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>
@@ Строка 133: / Строка 132: @@
   * **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>
-===== ZFS Arch =====
@@ Строка 164: / Строка 451: @@
-====  ====
-=====  =====
 <details>
@@ Строка 176: / Строка 461: @@
 </code>
 </details>
@@ Строка 185: / Строка 471: @@
 </code>
 </details>

zxcx

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

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

Различия

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