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

+

а если на этот пул положить не только базу? или несколько?

а если на этот пул положить не только базу? или несколько?

есть и такое

нука показывай совй накопитель, у него что латенси ниже 20 микросекунд?))

Ну оптан у меня сейчас не под рукой

я же говорю зависит от нагрузок

есть и такое

и что там?

нука показывай совй накопитель, у него что латенси ниже 20 микросекунд?))

А причем тут latency?

Ну оптан у меня сейчас не под рукой

ну и у него латенси будет соизмеримое

иопсов считает 17к, а база пишет 40к

как я понимаю io операции могут аггрегироваться при прохождении через slog?

А причем тут latency?

мдаааа)))

А причем тут latency?

сейчас поясню)) чтобы выжать 40к в базе в один поток нужно чтобы одна операция занимала 1/40к сек

Верно?

сейчас поясню)) чтобы выжать 40к в базе в один поток нужно чтобы одна операция занимала 1/40к сек

Не обязательно.

Не обязательно.

жги

Не обязательно.

приведите свой расчет?)

жги

io_submit

как ты сможешь сделать иначе?)

io_submit

чё?)

io_submit

ты намекаешь про кеш?

его нет

я же пишу что ARC кеш работает чисто по метаданным

а пейджкеша там нет тоже

ты намекаешь про кеш?

Я намекаю что не обязательно дожидаться завершения операции прежде чем сабмитить новую.

Я намекаю что не обязательно дожидаться завершения операции прежде чем сабмитить новую.

для выполнения в один поток обязательно))

иначе это уже не один поток))

io_submit

эм? казалось что мы про zfs..

итого чтобы выжать 40, нужно иметь латенси порядка 20 микросекунд), это гиперкруто)

причём на ext4 я так нихера не выжимал

Я намекаю что не обязательно дожидаться завершения операции прежде чем сабмитить новую.

а кто говорит что мы ждем запись одного блока? даже в режиме sync это не так, потому что на диск сбрасываются не отдельные блоки из slog, а txg

а кто говорит что мы ждем запись одного блока? даже в режиме sync это не так, потому что на диск сбрасываются не отдельные блоки из slog, а txg

вот это походу и является одной из причин почему в итоге на ZFS получается быстрее

итого чтобы выжать 40, нужно иметь латенси порядка 20 микросекунд), это гиперкруто)

А если речь про 3-4m iops?

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

А если речь про 3-4m iops?

что такое m

в постгрескуле я тоже не до конца понял получил я реально весомый прирост или +- тоже самое, но думаю я ещё не совсем умею это готовить.

для выполнения в один поток обязательно))

Ок, поясню. Юзерспейс может засабмитить пачку операций, которая разложится на biovec в очередях к блочным устройствам. Зачем тут чего-то ждать? Или вы про kernel threads?

что такое m

миллионы

А если речь про 3-4m iops?

у вас база реально выдает нагрузку в 3-4 млн iops на дисковую подсистему?

причём на ext4 я так нихера не выжимал

В один поток и сам зфс работает нормально и с фио, как только даешь 4 и более и рандомную нагрузку конец

у вас база реально выдает нагрузку в 3-4 млн iops на дисковую подсистему?

scylladb вполне может

Ок, поясню. Юзерспейс может засабмитить пачку операций, которая разложится на biovec в очередях к блочным устройствам. Зачем тут чего-то ждать? Или вы про kernel threads?

я про мускуль потоки

Ок, поясню. Юзерспейс может засабмитить пачку операций, которая разложится на biovec в очередях к блочным устройствам. Зачем тут чего-то ждать? Или вы про kernel threads?

вы забываете о том, что zfs это не только файловая система. для какой-нить ext4 утверждения справедливы. но не для zfs, так как оно является интерфейсом (драйвером) для взаимодействия с дисками и аллоцирует блоки самостоятельно, без обращения к ядру. если я все верно понимаю.

https://t.co/Kyg8PWaO5q

В один поток и сам зфс работает нормально и с фио, как только даешь 4 и более и рандомную нагрузку конец

мне наоборот - в один поток не удавалось выжать максимум из raid10 (4xnvme). Только при большом кол-ве джоб уже можно было увидеть утилизацию более 90%

вы забываете о том, что zfs это не только файловая система. для какой-нить ext4 утверждения справедливы. но не для zfs, так как оно является интерфейсом (драйвером) для взаимодействия с дисками и аллоцирует блоки самостоятельно, без обращения к ядру. если я все верно понимаю.

Так и? Объём вычислений не такой большой.

мне наоборот - в один поток не удавалось выжать максимум из raid10 (4xnvme). Только при большом кол-ве джоб уже можно было увидеть утилизацию более 90%

Утилизацию - ок, а при этом вывод какой был , по iops?

мне наоборот - в один поток не удавалось выжать максимум из raid10 (4xnvme). Только при большом кол-ве джоб уже можно было увидеть утилизацию более 90%

Так а что там показывает fio на свежих ядрах с aio/io_uring?

Так и? Объём вычислений не такой большой.

что и?) о каких вычислениях речь? вам привели в пример показатель latency на одну операцию ввода/вывода, ~ 20 мкс. это уровень nvme. могу предположить что размер блока был не 4к и запись была не линейная. для одного потока имхо 40к iops это нормальный показатель, зависящий от шаблона нагрузки со стороны базы..

Так а что там показывает fio на свежих ядрах с aio/io_uring?

io_uring так же не применим в случае zfs

что и?) о каких вычислениях речь? вам привели в пример показатель latency на одну операцию ввода/вывода, ~ 20 мкс. это уровень nvme. могу предположить что размер блока был не 4к и запись была не линейная. для одного потока имхо 40к iops это нормальный показатель, зависящий от шаблона нагрузки со стороны базы..

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

что и?) о каких вычислениях речь? вам привели в пример показатель latency на одну операцию ввода/вывода, ~ 20 мкс. это уровень nvme. могу предположить что размер блока был не 4к и запись была не линейная. для одного потока имхо 40к iops это нормальный показатель, зависящий от шаблона нагрузки со стороны базы..

> о каких вычислениях речь хеши посчитать, компрессию применить.

> о каких вычислениях речь хеши посчитать, компрессию применить.

хеши вычисляются до сброса данных на диск же. компрессия кстати при определенных условиях ускоряет запись )

если процессоры в системе не перегружены, эти накладные расходы в переделах погрешности.

хеши вычисляются до сброса данных на диск же. компрессия кстати при определенных условиях ускоряет запись )

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

сейчас везде ставлю lz4))

ну кроме хранилок больших с бекапами, там zstd

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

Ну это везде описано

если процессоры в системе не перегружены, эти накладные расходы в переделах погрешности.

Так я это прекрасно понимаю. Но тут был аргумент что "zfs - не просто фс"

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

у меня для базы на постгресе до 1.5 раз быстрее при recordsize = 128к)

Ну это везде описано

Ну вот я прочитал и решил проферить)), и офигел)

io_uring так же не применим в случае zfs

Из-за https://github.com/openzfs/zfs/issues/8716 ?

у меня для базы на постгресе до 1.5 раз быстрее при recordsize = 128к)

ну постгресс я ставлю ресайз 8к, хотя видел рекомендации на счёт 128к, но мне важно количество операций

Так я это прекрасно понимаю. Но тут был аргумент что "zfs - не просто фс"

ну да, что не так с аргументом? zol не поддерживает модные/молодежные механизмы IO линукс ядра - это факт. будет ли поддерживать - не знаю. хорошо это или плохо - it depends..

ну постгресс я ставлю ресайз 8к, хотя видел рекомендации на счёт 128к, но мне важно количество операций

у меня блоки бОльшего размера, поэтому 128к самое оно

Утилизацию - ок, а при этом вывод какой был , по iops?

по отдельной джобе - снижение вроде, в целом по сумме джоб - увеличение.

Так а что там показывает fio на свежих ядрах с aio/io_uring?

не тестировал, не могу сказать

по отдельной джобе - снижение вроде, в целом по сумме джоб - увеличение.

Должно было быть + - одинаково)) поэтому и говорю, что в один поток и сам зфс работает норм

А вот то что он тупо разбил нагрузку по потокам без увелечения и я видел))

ну да, что не так с аргументом? zol не поддерживает модные/молодежные механизмы IO линукс ядра - это факт. будет ли поддерживать - не знаю. хорошо это или плохо - it depends..

для примера, в свое время пробовал играться с io sched рекомендуемыми для ssd под линукс - blk-mq - менял для дисков, на которых пул собирал - никакого эффекта..

Должно было быть + - одинаково)) поэтому и говорю, что в один поток и сам зфс работает норм

https://us-east.manta.joyent.com/Joyent_Dev/public/docs/2019-06-RAIDZ_on_small_blocks.pdf - вот тут кстати есть описание случая когда может быть удвоение или утроение объема на zvol (logical vs physical)

и пишут вот так - Each block of a ZVOL gets its own parity disks, and if you have physical media with logical block sizes of 4096B, 8192B, or so on, the parity needs to be stored in whole physical blocks, and this can drastically increase the space requirements of a ZVOL, requiring 2× or more physical storage capacity than the ZVOL's logical capacity. Setting the recordsize to 16k or 32k can help reduce this footprint drastically

https://github.com/openzfs/zfs/issues/1807 - тут тоже пишут про увеличение volblocksize.

это я пишу к вашим словам про то, что volblocksize, ashift и disk sector size не влияют на расход места на zvol

https://us-east.manta.joyent.com/Joyent_Dev/public/docs/2019-06-RAIDZ_on_small_blocks.pdf - вот тут кстати есть описание случая когда может быть удвоение или утроение объема на zvol (logical vs physical)

Спасибо, посмотрю

понятно что нужно помнить про баланс между перформансом и объемом - но это "вечная" проблема, причем не только для zfs)

@gmelikov привет, я помню в чате как то был рецепт подключения пула для чтения со старой TXG метки. Не подскажешь, это возможно?

шифровальщик зашифровал шару на старом Freenas, а админ настроил снимки на корневой датасет, вместо рабочего вложенного... Может получится что то вытащить

@gmelikov привет, я помню в чате как то был рецепт подключения пула для чтения со старой TXG метки. Не подскажешь, это возможно?

если та метка ещё жива - да

если та метка ещё жива - да

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

@gmelikov привет, я помню в чате как то был рецепт подключения пула для чтения со старой TXG метки. Не подскажешь, это возможно?

https://openzfs.github.io/openzfs-docs/man/8/zpool-import.8.html#T