а primarycache=all для zvol?

kill -9 процесса kvm. Это будет стресс-тест и не только для СУБД, но и для самой ОС. Вот и будет случай проверить как поднимется винда если диск будет иметь sync=disabled

kill -9 убъет kvm-процесс, а данные-то уже в zfs, они спокойно допишутся. Это скорее тест внутреннего writeback-буфера ОС. Warning! Ahtung! Вот если в гипервизоре echo b>/proc/sysrq сделать - это мгновенно перезагрузит гипервизор!!! Очень небезопасно. Но даже в этом варианте, данные записанные во writeback-буфер диска, будут сохранены. Теоретически при потере питания, они тоже должны сохранятся, диск типа записывает их используя энергию вращения шпинделей... но вот HP например отключает этот буфер в своих дисках. Впрочем я разрушений zfs из-за потери питания на дисках с включенным внутренним буфером не видел. А семый честный и безопасный тест, поднять proxmox в виртуалке nested virtualization и потом kill -9 kvm 😊

kill -9 убъет kvm-процесс, а данные-то уже в zfs, они спокойно допишутся. Это скорее тест внутреннего writeback-буфера ОС. Warning! Ahtung! Вот если в гипервизоре echo b>/proc/sysrq сделать - это мгновенно перезагрузит гипервизор!!! Очень небезопасно. Но даже в этом варианте, данные записанные во writeback-буфер диска, будут сохранены. Теоретически при потере питания, они тоже должны сохранятся, диск типа записывает их используя энергию вращения шпинделей... но вот HP например отключает этот буфер в своих дисках. Впрочем я разрушений zfs из-за потери питания на дисках с включенным внутренним буфером не видел. А семый честный и безопасный тест, поднять proxmox в виртуалке nested virtualization и потом kill -9 kvm 😊

а если у меня только 1 архив и именно он не создался? как быть? лезть в бэкап за вчерашней копией?

Вы же его только что создали и на ваших глазах машина ребутнулась. Наверное вы можете повторить операцию. Но да, определенный ущерб есть. Есть случаи когда это приемлимо, а есть когда - нет (например архив делался не из файлов а принимал данные через pipe с удаленой системы). И я бы хотел чтобы люди видели эту разницу а не слепо ставили sync=always как бы чего не вышло. И почти всегда, не приемлимо ,если есть удаленная система с состоянием. Те. не просто pipe, а такой, который нельзя повторить. Система выплюнула данные перешла в другое состояние и второй раз выдаст другие данные.

Так с NCQ диск сам решает, куда ему шпиндель гнать. Что тут такого?

word/excel файлы это zip-архивы. Если при сохранении файла у меня будет коррапт, то придётся доставать бэкап

Все имеет свою цену. Ворд и эксель каждые 5 мин сохраняют ваш документ в специальной tmp-папке, там будет другая копия, вы потеряете данные только за 5 мин работы. А произойти такой случай может раз в 2 года, например. У вас же сервер на ИБП, два блока питания, два ввода, иБП тоже резервирован... имеет ли смысл увеличивать стоимость инфраструктуры там где это не требуется? и кстати мы говорим о событии перезагрузки или отключения гипервизора непосредственно в момент нажатия на кноку save, а что если sync=standart а вы не успели на кнопочку нажать, вот это событие произошло на 0.1 с раньше? Т.е. sync=standart vs disabled -это в худшем случае 5 сек работы системы (можно уменьшить этот интервал). Вопрос не в том что потери данных возможно. Вопрос в том какие они? Одно дело когда из-за writeback падает файловая система и у вас уничтожается всё, другое дело небольшой откат назад. Но я не спорю, это тоже потери, иногда они неприемлимы.

я тоже сначала не понял, а потом каак понял. с sync=disabled файл может просто оказаться недозаписанным и соответственно поврежденным, хотя система считает что всё ок.

word/excel файлы это zip-архивы. Если при сохранении файла у меня будет коррапт, то придётся доставать бэкап

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

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

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

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

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

вопрос к консистентности, в других ФС, где блок перепишется поверх, из 4К может быть переписано до ребута только 1К, и получаем 4К каши. В zfs он либо успешно запишет весь блок, либо после ребута откатится на предыдущий

вопрос к консистентности, в других ФС, где блок перепишется поверх, из 4К может быть переписано до ребута только 1К, и получаем 4К каши. В zfs он либо успешно запишет весь блок, либо после ребута откатится на предыдущий

естественно, есть нюансы, на то и появляются журналы в ФС, и wal логи в БД)

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

Стапе, секндочку. Обратите внимание, что в примере с kill -9 kvm sync=disabled не уменьшает, а увеличивает безопасность. А ведь виртуальные машины падают чаще гипервизора. Данные переместились в буфер zfs мнгновенно, и они не погибнут во writeback-буфере кильнувшейся ОС

да и чем оно увеличивает безопасность то?)

Как чем, тем что данные записались и все - это зона ответственнсти гипервизора. А в кильнувшейся ОС writeback буфер пустой. Если поставить sync=standatr там могла быть очередь запросов, они бы кильнулись вместе с ОС.

еще интересный момент: отключение кэша ssd в hdparm улучшило все показатели производительности.

ну стоит добавить, что от состояния "коррапт" в такой ситуации sync=standard и sync=disabled отличаются только на txg_timeout , т.е. по дефолту до 5 секунд

Не совсем так. Смотрите разница вот в чем: (1) нет файла->(2)записываем часть 1-> (3)часть 2 ->(4)поняли что записали Если у вас sync=standart и вы вырубили гипервизор в момент (3) -файл тоже будет "поврежден". Если у вас sync=disabled а вы вырубили гипервизор в момент (4), то вы окажетесь точно в каком же стостоянии,. Разница в том, что система успела "увидеть", и возможно куда-то сообщить, что файл записан, а он оказался не записан. что касается харакетра повреждений, то они одинаковые. Т.е. база данных не будет разрушена, т.к. часть файла 2 никогда не будет записана раньше части 1, хотя они оба могут оказаться целиком во writeback-буфере - в этом смысл транзакционности. Базы данных знают что хост может быть неожиданно перезагружен и используют лог, чтобы не разрушалась база данных. Т.е файл не будет поврежден, он буде как в машине времени переведен, как и весь zvol в состояние на несколько секунд раньше.

даже если логи падают на отдельный SLOG с батарейкой?

при sync=disabled zil вообще не используется, iirc

Стапе, секндочку. Обратите внимание, что в примере с kill -9 kvm sync=disabled не уменьшает, а увеличивает безопасность. А ведь виртуальные машины падают чаще гипервизора. Данные переместились в буфер zfs мнгновенно, и они не погибнут во writeback-буфере кильнувшейся ОС

если интересно, могу приложить результаты в архиве

при sync=disabled zil вообще не используется, iirc

ну вот в таком случае sync=standard(always) и будет лучше. Данные сохраняться на SLOG и будут проиграны.

да. будет интересно взглянуть

сейчас меня побьют, но при ограничении арк кэша исчезает проблема долгого залипания ui при копировании большого файла. т.к. он тупо не влезает в кэш и запись становится не такой интенсивной.

можно покрутить write throttling ещё, если сильно хочется, это в общем то он срабатывает https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Async%20Write.html

а может быть фризы UI связаны с попыткой зфс отдать немного RAM поскольку OS в виртуалке запросила у хоста её чтобы впихуть в неё этот большой копируемый файл?

В том кейсе 128ГБ свободно. Там реально мощная система. и 8 mirro zvol так что проблема точно не в производительности. Дело именно в том как оно работает.

все же в курсе, что зфс раму отдает, но не прям мгновенно

ну я хотя бы попытался)

То есть понимаете, эта действительно проблема, когда, сколь угодно мощная система, при бесконечном потоке записи, вместо того чтобы равномерно распределить нагрузку, начинает "залипать". То есть если бы там было не 8 vdev а например 16, ну просто оно бы писало не 800МБ в сек, а 1600 - условно, но залипло бы рано или поздно.

кстати у меня 17 😭

А какая средняя скорость линейной записи, мне просто любопытно?

кстати у меня 17 😭

у меня была система, её звали булька. ой о чем это я. а ну да, поставил туда интел ссд, сделал raidz1. копировать что-то больше 3-4 гб просто невозможно - фризуются все виртуалки (10 штук) и так каждые 10-15 сек, т.е. фриз, локается все на полминуты, потом рассасывается, потом опять у него буфер заполняется и опять фриз и так пока весь файл не скопируется, полный цикл фризов примерно минута плюс минус

Кстати, кол-во vdev должно быть степенью двойки, иначе будет перерасход места. Я только не понимаю почему так. Формулы видел, но почему черт возьми?