ну то есть такое в целом реально?

SSD - 1.92Tb Samsung PM963 порезан на 1.6Тб, на нем 32Гб SLOG и остатки - L2ARC

а зачем доавляли ? без него было хуже ?

Всем привет! Даже когда на zfs нет нагрузки в /proc/spl/kstat/zfs/dmu_tx dmu_tx_assigned постоянно увеличивается каждую секунду. Откуда эти транзакции. TxG по дефолту должна отрабатывать каждые 5 сек (zfs_txg_timeout)

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

ага, только если в коде баг, штатно потеря l2arc не критична, на нём нет ничего важного для пула, только кеш

сравнили iostat

занятно. А сколько ОЗУ на сервере ?

@gmelikov Можно спросить по special vdev. Примерно 1,2 -1,3% от размера пула. Ну допустим. Но читал что (не могу найти только где:( ) что допустим при слишком маленьком recordsize а сильно увеличивается фрагментация и (!) количество метадаты. С фрагментацией вроде, если система оперирует большим размером, от сюда и фрагментация. А вот про метадату это правда ? Количество метадаты которую может породить пул не константная величина ? От чего её кол-во зависит ? Спасибо!

- zfs_txg_timeout это МАКС таймаут, есть другие лимиты для сброса txg на диск раньше - единомоментно существует минимум iirc 3 txg, одна уже закрыта и сбрасывается на диск, одна в процессе закрытия, одна открытая для наполнения, т.е. чтобы раз в 5 секунд она появлялась - должно повезти

разве так бывает, когда нет абсолютно никакой нагрузки ?

Иван, в проде - нет ))) но я сейчас тестирую сигейтовские 16ТБ диски, а они себя очень странно ведут под zfs.

они не черепичные случаем?)

Николай, не черепичные. И если диск использовать, как стандартное устройство нормально работает. Но вот под zfs, да еще при записи блоком 4К время отработки транзакции выходит за 200 сек и zfs ложиться... И это устойчиво воспроизводимый эффект

а что за модель?

Николай, не черепичные. И если диск использовать, как стандартное устройство нормально работает. Но вот под zfs, да еще при записи блоком 4К время отработки транзакции выходит за 200 сек и zfs ложиться... И это устойчиво воспроизводимый эффект

Николай, не черепичные. И если диск использовать, как стандартное устройство нормально работает. Но вот под zfs, да еще при записи блоком 4К время отработки транзакции выходит за 200 сек и zfs ложиться... И это устойчиво воспроизводимый эффект

ST16000NM002G Exos X16

fio на отдельном диске пробовали запускать ?

Интересный эффект. Он как то зависит от конфигурации пула и/или vdev?

Я больше люблю vdbench. Нагружал и в хвост и в гриву, работают норм, без нареканий. И с включенным и выключенным кэшом записи

Да, эффект наблюдается, если ashift=9. Raidsz2. Группа ложиться прям за пару минут при записи 4К блоком

SSD - 1.92Tb Samsung PM963 порезан на 1.6Тб, на нем 32Гб SLOG и остатки - L2ARC

он же 512е/4kn

а какой у вас размер основного пула? 14Tbx4? Или всего 14Тб из 4х дисков?

там другой пул. Там 12*6Tb

тогда l2arc имеет смысл)

Сергей, если ashift=12 при записи блоком 4К дикий перерасход места - по логике raidz2 под 4к блок уйдет 12К

там же эмуляция 512. Пишется же все равно в блок 4к? или я не прав?

Они могут смержиться, конечно - но кто знает

это на уровне зфс или NO_MERGE опция на диске?

там же эмуляция 512. Пишется же все равно в блок 4к? или я не прав?

то есть 4к блок бьётся на 8 блоков по 512к, + несколько копий меты в другие сектора ещё писаться будут?

Сергей, если ashift=12 при записи блоком 4К дикий перерасход места - по логике raidz2 под 4к блок уйдет 12К

а сразу захлёбывается или есть какой-то порог насыщения?

Серег, мне казалось что ashift=9 , это для совсем старых дисков актуально. а расход места будет зависеть в первую очередь от recordsize или volblocksize ну и от компрессии еще..

оверхед же большой при размере блока датасета в 4к

т. е. если ты точно знаешь что будешь писать блоками по 4к, то выбираем recordsize=4k, а ashift для пула ставим =12

может с wce=0 попробовать?

наверное, исходя из ТТХ диска)

Коля, прикинь, прилетает блок 8К, raidz2 аллоцирует количество блоков, кратное 3-м. Т.е. 4+4 (8К) да еще 2 блока четности и еще впустую расходуются 2 блока чтобы получилось 6. Это при ashift12. А при ahift9 все более-менее гуманно с точки зрения пространства. Добавлю, что такая фигня с зависанием zfs только на этой модели, то же самое пробовал на других вендорах, все норм

Георгий, спасибо за ответ. С 3-мя TxG все понятно, насколько я понимаю, отработка TxG срабатывает по достижении порога грязных буферов или по таймауту. Если у хоста 32Гб памяти, по дефолту порог срабатывания около 2ГБ, и если нагрузка на запись меньше (я имею в виду запись в файл или zvol) то раз в 5 секунд и появляется новая закрытая транзакция. Частенько это наблюдал в /proc/spl/kstat/zfs/<>/txgs. А вопрос я задавал про полное отсутствие к-либо нагрузки.... Есть ли возможность посмотреть, что вызвало отработку TxG?

мне посоветовали 12 на диски с 512б (((

Георгий, спасибо за ответ. С 3-мя TxG все понятно, насколько я понимаю, отработка TxG срабатывает по достижении порога грязных буферов или по таймауту. Если у хоста 32Гб памяти, по дефолту порог срабатывания около 2ГБ, и если нагрузка на запись меньше (я имею в виду запись в файл или zvol) то раз в 5 секунд и появляется новая закрытая транзакция. Частенько это наблюдал в /proc/spl/kstat/zfs/<>/txgs. А вопрос я задавал про полное отсутствие к-либо нагрузки.... Есть ли возможность посмотреть, что вызвало отработку TxG?

Вообще правильно посоветовали. Даже на 512 дисках расход будет маленький, пользы больше

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