zfs set recsize=XXXk pool_name, но это будет работать на вновь создаваемые файлы. Или стоп PG, move-move (на другой датасет) и опять запустить

я имел ввиду это: "increasing PostgreSQL block size to 32k and WAL block size to 64k"

я имел ввиду это: "increasing PostgreSQL block size to 32k and WAL block size to 64k"

это не надо делать

я имел ввиду это: "increasing PostgreSQL block size to 32k and WAL block size to 64k"

оставить значения по умолчанию 8k

Хорошо )

Они архитектурно определены

А у кого трудятся диски SMR? Какой фидбек? Я понимаю, что они не самый лучшый выбор, но ограничен 2.5 дисками. Задача - домашняя файлопомойка.

Ресильверинг будет очень неприятен.

Или заливка большого объёма данных может принести сложности

Если есть возможность, рекомендую собрать и сурово протестировать сначала фио, потом ресильвером

А у кого трудятся диски SMR? Какой фидбек? Я понимаю, что они не самый лучшый выбор, но ограничен 2.5 дисками. Задача - домашняя файлопомойка.

я бы дождался когда в stable приедет rebuild, он даст зелёный свет считай для smr дисков

Ессесно потестить надо перед всем этим.

я бы дождался когда в stable приедет rebuild, он даст зелёный свет считай для smr дисков

А в какгой версии планируется?

https://github.com/openzfs/zfs/pull/10349

оно уже в альфе 2.0 https://github.com/openzfs/zfs/commit/9a49d3f3d3bfa26df4e5e54d574cb490f0ee284b

т.е. если ничего критичного не найдётся - приедет в следующем стейбле

Тогда надо брать диски)

оно уже в альфе 2.0 https://github.com/openzfs/zfs/commit/9a49d3f3d3bfa26df4e5e54d574cb490f0ee284b

Вроде в rc1 уже?

Вроде в rc1 уже?

ага, пол коммитом можно увидеть в какой тег входит

Тогда надо брать диски)

только я, если что, на smr дисках это не тестил) поделитесь потом опытом плиз

Сперва закупиться надо) Как только так сразу отпишусь

Сперва закупиться надо) Как только так сразу отпишусь

спс!

Сперва закупиться надо) Как только так сразу отпишусь

ИМХО не надо. Чуда не произойдет и они писать быстрее не смогут. Всего-то теперь будет по другому резильверится и не выпадать по таймауту. А тормоза записи будут ибо это smr

ИМХО не надо. Чуда не произойдет и они писать быстрее не смогут. Всего-то теперь будет по другому резильверится и не выпадать по таймауту. А тормоза записи будут ибо это smr

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

Ну или переубедите меня)

вот тредик с опытом smr дисков на стейбле https://zfsonlinux.topicbox.com/groups/zfs-discuss/T0c4e92b265b642c9-M5b0d7de80520c36448c70d25

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

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

Интересно, а trim улучшит ситуацию. По идее, если накопитель знает что данные стёрты то может не пытаться считать их перед перезаписью.

Интересно, а trim улучшит ситуацию. По идее, если накопитель знает что данные стёрты то может не пытаться считать их перед перезаписью.

Не могу сказать, так как не использовал smr нигде

Интересно, а trim улучшит ситуацию. По идее, если накопитель знает что данные стёрты то может не пытаться считать их перед перезаписью.

Нет.

@neurox

@neurox

Я тут

Видимо, бот справился

Вижу просто форвард, но вместо него - знак вопроса

Неуверенные в себе спам-боты - это что-то новенькое

Коллеги ,а кто нибудь пробовал, сколько реальных данных влезает на пул?

наткнулся с такой проблемкой есть пул 64Тб, том на нем 50Тб забил на 77% и все он встал🤷🏻‍♂️

свободное место на пуле 0

а пул из чего состоит?

mirror? RAIDZ?

mirror? RAIDZ?

Z2

ага)

Z2

https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz

Love RAIDZ

там табличка есть по накладным расходам

https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz

спс, сейчас ознакомлюсь

но уж овер дохрена на накладные

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

😂👍

но уж овер дохрена на накладные

ну там константные расходы на каждый блок, вы каким блоком пишете на пул? recordsize/volblocksize

ну там константные расходы на каждый блок, вы каким блоком пишете на пул? recordsize/volblocksize

льются бэкапы потоком

ну там константные расходы на каждый блок, вы каким блоком пишете на пул? recordsize/volblocksize

ну думаю что маленьким блоком

А что еще кто-то ведется на эту фигню отправь доллар а получишь два?

Подскажите какой размер special_small_blocks будет оптимальным для гипервизора

Подскажите какой размер special_small_blocks будет оптимальным для гипервизора

т.к. на гипервизоре обычно хранятся имаджи vm в том или ином виде, то у вас особо выбора нет и либо все имаджи поедут на special vdev, или ни одного. Т.е. логичным будет не выставлять special_small_blocks именно для этого кейса.

у имаджа будет всегда один размер блока просто

ага, спасибо большое.

допустим у меня пул на хдд с ashift=12, то и на special будет так же ? как производительней получится, с ashift=12 или лучше угодить ssd ashift=13 ?

допустим у меня пул на хдд с ashift=12, то и на special будет так же ? как производительней получится, с ashift=12 или лучше угодить ssd ashift=13 ?

выставление ashift точно не помню, а вот про обязательность ashift=13 не видел явных за, если будет сжатие - только повредить может

т.к. чем больше ashift, тем меньше эффективность сжатия (больше теряется места)

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

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

если сжатие использовать не будете, то для ссд и правда лучше 13

уж точно не хуже

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

что-то не очень понятно почему special филонит

вся нагрузка постоянно ложится на log

вся нагрузка постоянно ложится на log

значит синхронная запись прилетела

что-то не очень понятно почему special филонит

ну на записи крупным блоком одним потоком много метаданных писать не нужно особо

но в вм я тупо копирую большой файл.

средствами виндовс эксплорера

как понять что он филонит ?

и конечно просадка скорости копирования в 0 может напугать юзеров, сложно будет объяснить что это ок.

как понять что он филонит ?

я надеялся, что с ним всё аж залетает, а по сути получилось, что с ним, что без него - нет разницы.

сейчас это конечно тест курильщика.

и конечно просадка скорости копирования в 0 может напугать юзеров, сложно будет объяснить что это ок.

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

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

имеется ввиду на диске вм ?