например где-то write-back включали :)

на чем?

на пути к системе хранения, до точки объединения со всех нод

хотя вроде нфс такой, что должен всё синкать

вообще голый проксмокс. writeback выставлен на диске только(который при настройке виртуалки), но это и до проблем было включено, далеко до меня

на другой ноде при запуске этой фс крешится, правильно?

либо при ребуте жёстком

если да - дело в этом

либо при ребуте жёстком

При работе крашится и в ro

тогда очень странно.

вообще голый проксмокс. writeback выставлен на диске только(который при настройке виртуалки), но это и до проблем было включено, далеко до меня

writeback для образа ВМ?

врайтбек вообще не надо делать.

врайтбек вообще не надо делать.

вот только хотел сказать, что это плохая практика

https://pve.proxmox.com/wiki/Performance_Tweaks

вам видимо повезло что проблема раньше не вылезла. writeback - это второй после unsafe по отсутствию надёжности

делайте writetrough.

будет медленнее (зависит от дисков), но валиться не будет

либо, если прям очень доверяете дискам (например, если используется нфс) - тогда самый первый вариант

хотя лучше не надо

а если высокий io на хранилке то потеря естественна?

нет

если это не программный глюк, конечно

на последний думаю тоже, слишком часто стала крашиться и есть подозрение что после перехода на 6ю версию путем apt-get

При том это уже 4е такое вынужденное обновление

writetrough при свапе и высоком la не будет давать потерь?

потерь данных нет, потерб производтельности - да.

вообще на вм своп ни к чему.

лучше памяти добавить - дешевле будет

лучше памяти добавить - дешевле будет

это уже в пути

я просто прорабатываю все

и скорее всего 50% уйдет на vmware

кстати - ио можно ограничивать

кстати - ио можно ограничивать

не во всех жизненных ситуациях, с NFS с этим плохо очень

у виртуалки да

на диске настройка

а вот просто NFS шара

И самый прикол когда в 20 потоков все идет

ну так планировать диски надо)

Отделяю вот диски от виртов)

нфс кстати очень медленный - на среднем сетапе 3500-4500 иопс выжималось

Iscsi?

нфс

нфс

аналог имею ввиду

как раздавать?

если диски медленные - без разницы

ну в новой чисто ssd

тогда зволы

но я б рекомендовал протестироват на производительность всю эту икебану :)

мало ли что ещё вылезет

зволы скоро ускорятся кстати до 3х раз https://github.com/openzfs/zfs/pull/10163

зволы скоро ускорятся кстати до 3х раз https://github.com/openzfs/zfs/pull/10163

behlendorf постарался опять :)))

behlendorf постарался опять :)))

не, Ahrens

Может, плюнуть на омниос 😁😁😁

А насколько вообще логично zfs на ssd? или смысла нет? бед блоков же нет на ssd

А насколько вообще логично zfs на ssd? или смысла нет? бед блоков же нет на ssd

очень логично. а если добавить в комплект оптан для ZIL, то просто огонь! ))

зволы скоро ускорятся кстати до 3х раз https://github.com/openzfs/zfs/pull/10163

и это для sync? Ну просто праздник для ВМок))

зил для ссд не нужен

зил для ссд не нужен

нужен). если это оптан

цель зил - побыстрее записать транзакцию.

http://napp-it.org/doc/downloads/optane_slog_pool_performane.pdf

если зил нет - она пишется в общий массив.

если зил нет - она пишется в общий массив.

там (выше по ссылке) анализ производительности пула на ссд, которому добавили оптан в качестве нитро-

если зил нет - она пишется в общий массив.

я знаю. У оптанов самая низкая задержка среди всех ssd. А для зила это ключевой фактор

для зила ключевой фактор - не потерять данные даже из внутреннего кеша при пропадании питания :)

батарейки там

а скорость это вторично

1.3 Result: Slog If you want sync write on a disk-pool, you must use an Slog. Even a good SSD can help. A Dram based ZeusRAM can heavily improve write performance but Intel Optane as Slog is the Best. If you have a pool from some faster SSD or NVMe vdevs, a dedicated Slog does not help unless its the Optane. The bigger the performance difference between pooldisks and Slog the more helpful is the Slog. If an Slog is as fast or only slightly faster than a pooldisk it is not helpful.

а скорость это вторично

ну глянь пдфку, а? ))) я же не просто пишу. Ну у Георгия спроси - поможет ли оптан для sync записи, даже если пул на ссд собран

не, безусловно, нвме делает всех

но если у тебя там данные потеряются - будет плохо. так что важнее, всё таки, внутренняя батарейка

не, безусловно, нвме делает всех

не просто nvme. А именно оптан. Если конечно у тебя пул на чистых оптанах не собран. Но это очень дорого И у оптанов батарейка есть

ну тогда норм. :)

и их должно быть два :D

в мирроре

в мирроре

почитай пдфку)), ну пжлста))

на какой странице?

I cannot publish results due Oracle restrictions. But I am impressed of the good pool and SMB values on Solaris. You nmust do your own tests

аххахаха)

для зила ключевой фактор - не потерять данные даже из внутреннего кеша при пропадании питания :)

Проблема в том, что данные можно потерять даже при записи в zil, если на этом диске нет конденсатора, да и то, что не успеет попасть в кэш диска всё равно пропадёт. Вопрос вообще использовать механизм кэширования записи при ссд пуле и насколько я понимаю, этот процес построения блока для записи вообще не возможно выключить, т.к это часть zfs и в памятью оно все равно будет писать. Другое дело, энергонезависимая память. Хотя с третьей стороны, ибп который тушит сервер при критическом заряде. Во всех остальных случаях выход из строя аппаратных частей приведёт к невозможности записи транзакций которые небыли сброшены, зил лишь сведёт их количество к минимуму. Или я не прав?