gjournal+mirror

[Eugene Grosbein]

Если использовать gjournal с gmirror и завысить kern.geom.journal.cache.limit так, чтобы kern.geom.journal.cache.alloc_failures оставался нулевым
и при этом не увеличить KVA с kmem и kmem внезапно кончится, то система легко падает в панику в момент интенсивной нагрузки.
У меня это привело к тому, что после ребута журнал оказался битым и переинициализировался, fsck посчитал систему clean, несмотря на то,
то она внутри была серьезно повреждена. После чего система хотя и не паниковала, но эффекты при запуске приложений были весьма занятными,
geom жутко ругался в логи об ошибка чтения шестого терабайта на разделе в сто гигов, fs лочилась, вынуждая жать power и далее всё
повторялось. Полечилось запуском fsck -y из single user, который всё прибрал, засовав приличную пачку файлов в lost+found.

Хорошо, это был тестовый десктоп и можно было просто переустановить поврежденные библиотеки из портов (поломалась /usr/local),
а нужные данные были на /home и сохранились.

[Andrey Ostanovsky]

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

[Eugene Grosbein]

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

Это всё актуально для i386. Hа системе с двумя гигами памяти цифры уже практически канонические options KVA_PAGES=512 в ядре даёт ядру
2G виртуального адресного пространства из полных четырех гигов i386, в /boot/loader.conf:

vm.kmem_size_max=1024M
vm.kmem_size=1024M

Это даёт один из этих двух гигов под kmem (пул динамической памяти ядра). В итоге собственный лимит gjournal может оказаться слишком большим
(он масштабируется), ограничиваю его через /etc/sysctl.conf
kern.geom.journal.cache.limit=201326592

Это будет 192Mb. Можно до 200, тоже работает стабильно.

[Alex Korchmar]

Если использовать gjournal с gmirror и завысить kern.geom.journal.cache.limit так, чтобы kern.geom.journal.cache.alloc_failures оставался нулевым
и при этом не увеличить KVA с kmem и kmem внезапно кончится, то система легко падает в панику в момент интенсивной нагрузки.
У меня это привело к тому, что после ребута журнал оказался битым и переинициализировался, fsck посчитал систему clean, несмотря на то,
то она внутри была серьезно повреждена. После чего система хотя и не паниковала, но эффекты при запуске приложений были весьма занятными,
geom жутко ругался в логи об ошибка чтения шестого терабайта на разделе в сто гигов, fs лочилась, вынуждая жать power и далее всё
повторялось. Полечилось запуском fsck -y из single user, который всё прибрал, засовав приличную пачку файлов в lost+found.

Хорошо, это был тестовый десктоп и можно было просто переустановить поврежденные библиотеки из портов (поломалась /usr/local),
а нужные данные были на /home и сохранились.

а где тут - влияние gmirror?

[Eugene Grosbein]

Без понятия, рассказал как было Hе исключено, что из-за kernel panic рассинхронизировалось и зеркало, а из-за наличия журнала синхронизация
была отключена. Да, забыл сказать что при лечении на всякий случай разбирал зеркало, потом собирал обратно.

[Alex Korchmar]

а-а-а, я забыл об этой чудо-фиче.