специально не отключал, все на дефолтах (FreeBSD 12.1)

попробуем, надо даунтайм планировать только

дык у меня arc только на 60% загружен, выше скрин постил

надо)), проц с поддержкой максимум 128Гб, а там такие приложения что каждый Гб на счету, на арк будет выделено не более 16Гб

а есть графики по каждому текущему физическому диску на throughput, latency, утилизацию?

я имел в виду что если нагрузка прям совсем совсем не дичайшая

ну вот (iostat %b) это на 7 вм, на 10 сегодня считать будем. Замеры 2 суток, раз в 5 секунд

погодь, но у тебя тут мироры, а не zraid

Владимир, это опасная опция. Я бы с крайней осторожностью подходил к её использованию. При таком режиме все операции fsync из виртуальной машины превращаются в async. И при падении хоста у вас образ может быть повреждён

ну да, сейчас мирроры, на SSD планирую на raidz1 переходить

ну чисто теоретически zraid на ссд, будет быстрее чем столько мироров на hdd, хотя вот блин лучше на практике померять))

zvol 64k

а что внутри ВМ крутится? Я понял что винда, а что за приложение? Просто и для самой винды 64k тоже много, у NTFS размер кластера по умолчанию если не ошибаюсь 4к.

денег бы еще кто-то дал на эксприменты )) все на свои делается

load averages: 0.90, 0.57, 0.41

а в нагрузке))

да в смысле))

или во фряхе ла по другому считается, или это не нагрузка нфига))

а как же гарантия последовательности записи данных?

ну не прям в 100%, работает 8 из 10

вы видимо не совсем поняли) меня. Ставя опцию writeback qemu "говорит" виртуалке что запись произведена и виртуальная машина в свою очередь думает что данные записаны. А на хосте операция становится async и будет записана "чуть погодя". Так вот если перед "чуть погодя" что-то случится с хостом - то данные на диск в действительности не попадут. Чтобы данные гарантированно записались и ВМ получила подтверждение что всё записано - нужно чтобы fsync из виртуалки остался fsync и на уровне хоста и попал в ZIL и далее....

игры )

и они крайне активно пишут на диск?

в целом - нет, отдельные могут - когда например качают пару десятков гиг из стима

тогда я не вижу смысла в 64к для zvol. Ставьте 8к по умолчанию, IOPS станут выше. Обновления и загрузка игр из стима вряд ли идут 24 часа в сутки, это разовые операции.

ну это данность, поменять нельзя, к сожалению

почему если не секрет?

Вкратце - потому что этот zvol не я собираю, я только получаю готовый и переделывать его никто не будет.

ну вот у меня случилс ясбой по питанию, и в моём понимании у меня стартанёт виртуалка ну как бы с откатом ну скажем на несколько секунд, что тут плохого?, я понимаю что данные эти просрались, но и сбой по питанию не то чтобы штатная ситуация

виртуалка будет думать что данные записались, так как запись шла через fsync и ОС (qemu) подтвердил что запись выполнена. Когда приложение записывает данные через fsync - то приложение полагает что данные действительно попали на носитель и логика дальнейшей работы строится на этом предположении

ну там так-то вроде одна команда, переделывать не надо, и даже вроде как на лету применится, пусть меня поправят если я не прав

ну пока это никак не противоречит вроде с тем что я сказал

противоречит. опция writeback в настройках qemu отключает fsync на уровне хоста. Вместо этого запись становится async. А внутри ВМ приложения продолжают думать что их fsync выполнился как нужно

НУ погодите ребят, в чём проблема моей логики? что я не так понимаю), ну пните что почитать хотя бы. Я вот прочитал те статейки что кидали, и исходя из того что прочитал у меня сложилось впечателние что сбой по питанию не помеха, потому как запись последовательна и записывает с копированием, что не портит старые данные

представьте что вы кому-то должны 100 рублей. И есть посредник, который должен взять у вас 100 рублей и отдать тому, кому вы должны. При настройках по умолчанию посредник отдаёт ваши 100 рублей кредитору и только после этого сообщает вам что отдал. Вы уверены в том что ваш долг погашен. А при настройках writeback он берёт у вас деньги и сразу вам говорит что отдал. Но на самом деле отдаст (или не отдаст) только спустя какое-то время. И если произойдёт сбой на уровне посредника, то ваши 100 рублей на попадут к кредитору. Но вы то думаете что они дошли получателю. А посредник их потерял во время сбоя

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

хост (qemu) вам подтверждает что запись произошла, но данные ещё в ОЗУ, а не на носителе

хост (qemu) вам подтверждает что запись произошла, но данные ещё в ОЗУ, а не на носителе

Копирование при записи в ZFS происходит не только на уровне файловой системы, но и на уровне управления дисками. Это означает, что ZFS не подвержена пробелу в записи (дыре в RAID) — феномену, когда полоса успела только частично записаться до сбоя системы, с повреждением массива после перезагрузки. Здесь полоса пишется атомарно, vdev всегда последователен

вы тогда перечитайте что такое ZIL. и операции синхронной записи (fsync)

По-факту вы сейчас говорите не использовать не только райтбек, но и не использовать кеш на запись в принципе потому что не безопасно - я правильно понимаю?

то есть там логика отличается?

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

для async и fsync - да, отличается

даже когда кеш отключен у диска?

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