Ну а если вернуться к вопросу с которого началась дискусия. Может быть вы знаете, чем вызвана просадка в 0 при копировании файла проводником в вирутальной машине в пределах одного диска (да и разных по помему тоже)? И как этого избежать и чем придётся пожертвовать? Пользователи действительного говорят о подвисаниях в таком случае, имея в виду подвисание копирования.

Похоже на врайтбек как раз

Тот самый синк

Там не было writeback, а пул аж из 8 mirror как я понял + slog + special + 128GB RAM свободно. Я сомневаюсь, что одна виртуалка прогрузила такой пул.

По пути до стораджа. кешей же много по пути

Или smr 😁

Он тоже так себя ведёт

у меня в винде параметров то таких нет )

у меня в винде параметров то таких нет )

Ввинде часто их нужно создать, чтобы поменять поведение "по умолчанию" на другое. Тип важен.

Или smr 😁

на другом серваке у меня lvm на этих дисках и таких эпических просадок нет.

на другом серваке у меня lvm на этих дисках и таких эпических просадок нет.

У меня просьба, после копирования запустить atop 5 и через 5 сек сделать скриншот загруженности дисков в дополнение к данным о просадке.

зато есть smr диски в другом серваке, там винда на железе стоит. в общем пожалели что сэкономили 600р. на диски 😃 ведет себя крайне непредсказуемо.

на другом серваке у меня lvm на этих дисках и таких эпических просадок нет.

В lvm и нагрузочная способность на порядок (или даже на порядки) меньше. Никаких slog, special и т.д

вот эта штука делает красиво

почему-то с writeback подлагивает интерфейс во время копирования

без кэширования вообще (снят верхний флаг) скорость в целом ниже, но просадок в 0 так же нет

У меня просьба, после копирования запустить atop 5 и через 5 сек сделать скриншот загруженности дисков в дополнение к данным о просадке.

так выглядит при writeback с дефолтными настройками в винде и падении скорости копирования до 0

самое интересное, что до 90% прыгает загрузка этих дисков (ssd) задолго до падения скорости копирования

т.е. какбудто начинается запись на хдд, но в топе их нагруженными не видно

самое интересное, что до 90% прыгает загрузка этих дисков (ssd) задолго до падения скорости копирования

А sdaj и sdak - это механические диски или slog, special и др SSD?

А sdaj и sdak - это механические диски или slog, special и др SSD?

ssd - slog+special

Ну кратковременно zfs может погружать диски и это, если пул не перегружен, не должно влиять на клиентов, но с вашей конфигурацией даже 60% - много.

Можно atop 1 запустить для более оперативного обновления информации

диски хоть и хорошие, но всё же sata. сервер ничего кроме этого не может принять )

да sata - норм, от sas кроме возможности резервирования линка почти не обличаются, если говорить об одинаковых моделях.

ссд - SSDSC2KG480G801

к сожалению nvme не запихать никак

самое интересное, что до 90% прыгает загрузка этих дисков (ssd) задолго до падения скорости копирования

Вот я и хотел исключить перегруженность пула. Пул не перегружен, значет ээфект не связан с перегрузкой.

и sata ssd норм для этих целей. NVME имеет смысл под полностью ssd пул когда нужна латентность маленькая. Для slog и special любые подойдут, лишь бы выдерживали нагрузку по записи, т.е. серверные.

и вот это: Расширенная защита от потери данных при отключении питания Да https://www.intel.ru/content/www/ru/ru/products/memory-storage/solid-state-drives/data-center-ssds/d3-series/d3-s4610-series/d3-s4610-480gb-2-5inch-3d2.html

У меня результаты через часик будут.

Можно atop 1 запустить для более оперативного обновления информации

на топ 1 всё в 101% лежит пока скорость начинает снижаться. все хдд по очереди пробегают с соточкой и уходят.

завтра попробую ссд не в мать сунуть, а в hba

на топ 1 всё в 101% лежит пока скорость начинает снижаться. все хдд по очереди пробегают с соточкой и уходят.

инетресно. Т.е. все-же прогружается. А скорость копирования при этом какую выдаёт?

в целом результат fio меня порадовал. непонятно только почему появляются лаги при writeback.

инетресно. Т.е. все-же прогружается. А скорость копирования при этом какую выдаёт?

когда чтение закэшено, то с 1,3Г, иногда с 700МБ/с падает до 300,200,100 и в 0 лежит некоторое время. вот с 300 уже видно в атопе 101%

ну это еще винда сглаживает график.

безопасна ли такая настройка при cache=none и sync=standard ?

когда чтение закэшено, то с 1,3Г, иногда с 700МБ/с падает до 300,200,100 и в 0 лежит некоторое время. вот с 300 уже видно в атопе 101%

причем в atop5 нет значений выше 90%, а хдд вообще выше 25% не набирают.

в целом результат fio меня порадовал. непонятно только почему появляются лаги при writeback.

Ну так он пытается увеличить среднее кол-во операций. Для этого, как можно дольше накапливает данные в буфере, потом разом сбрасывает их на диск, продолжая накапливать в будере. Видимо на диск они сбрасываются медленнее, чем заполняют буфер и когда буфер заканчивается, с точки зрения виртуалки, виртуальный накопитель долго находится в состоянии busy а винда при этом тупит. У меня идея. А попробуйте ограничить скорость каким-нибудь разумным значением вот тут:

И поиграться с этими параметрами, например убрать bust

безопасна ли такая настройка при cache=none и sync=standard ?

По моему мнению, эта настройка менее безопасная, чем когда там галочки сняты, а sync=disabled... Кроме безопасности, эти варианты могут быть разными с точки зрения нагрузки на процессор

По моему мнению, эта настройка менее безопасная, чем когда там галочки сняты, а sync=disabled... Кроме безопасности, эти варианты могут быть разными с точки зрения нагрузки на процессор

есть падение до 0, долгие пики до 700 и плато на 75

По моему мнению, эта настройка менее безопасная, чем когда там галочки сняты, а sync=disabled... Кроме безопасности, эти варианты могут быть разными с точки зрения нагрузки на процессор

Почему я так считаю? ntfs не обладает транзакционностью как zfs а значит при неожиданном крахе гостя, или всего гипервизора, данные в буфере внутри виртуалке сбростяся и ntfs может разрушить какую-нибудь базу данных, а в редких случаях и сам разрушиться. Если же данные переданы в zfs самое плохое что может произойти - небольшой откат во времени, но это будет конситентный откат.

странно как-то гораничивается, да и не хотелось бы этим пользоваться для всех вм

странно как-то гораничивается, да и не хотелось бы этим пользоваться для всех вм

а если bust стереть?

и writeback внутри венды отключить?

Это очень похоже на вендовый writeback. Чтобы проверить попробуйте выдать машине не 8 гб а 2 и повторить. Еслигорб станет короче по времени - это чисто венда так делает.

Это с какими параметрами?

без burst

а без writeback в свойствах диска в венде?

а без writeback в свойствах диска в венде?

без всяких ограничений из прокса держится около 100, в среднем

без всяких ограничений из прокса держится около 100, в среднем

маловато для 8 vdev-то.

https://t.me/ru_zfs/10302 - я имел в виду вот тут отключить.

а, оно сейчас отключено

привел всё к дефолту откатившись в снапшот

а... хм. что за горбы не понятно.

У меня готов, щас попробую.

с 2 гигами рамы с ограничением скорости из прокса выбросов вверх нет. вниз небольшие и редкие.

без ограничений в целом выгляди так же, максимальные выбросы меньше стали.

https://t.me/ru_zfs/10302 - я имел в виду вот тут отключить.

у вас тестовые компы чтоль?

Кто вообще это включает?

Вот, т.е. это чисто поведение винды когда у нее много свободной оперативки, а writeback отключен?

Вот, т.е. это чисто поведение винды когда у нее много свободной оперативки, а writeback отключен?

да

у вас тестовые компы чтоль?

просто тестируем )

Кто вообще это включает?

Я имел в виду опцию включить, writeback отключить. Скриншот от @simubishi по этому я и обратил внимание.

просто тестируем )

А что тестируете?

Я имел в виду опцию включить, writeback отключить. Скриншот от @simubishi по этому я и обратил внимание.

Зачем данными рисковать?

Пытаемся понять, как избежать почему возникают фирзы при копировании файлов проводником в виртуалке.

А что тестируете?

затупы винды при копировании в проводнике 😃

Я имел в виду опцию включить, writeback отключить. Скриншот от @simubishi по этому я и обратил внимание.

так я пробовал, поведение в целом то же.

затупы винды при копировании в проводнике 😃

Так это тестируется элементарно. Воспроизводится в никсах, Стрейс на ио и иостат на диски.

Так это тестируется элементарно. Воспроизводится в никсах, Стрейс на ио и иостат на диски.

Да это имнно в проводнике. Я думаю это просто буфер самого проодника значит. По тому что когда оперативки много, он его забивает а потом просто перестает читать пока не освободит.

Да это имнно в проводнике. Я думаю это просто буфер самого проодника значит. По тому что когда оперативки много, он его забивает а потом просто перестает читать пока не освободит.

У проводника буфера нет

вот так иостат выглядит при падении скорости в проводнике до 0