/etc/cron.weekly/99-raid-check: WARNING: mismatch_cnt is not 0 on /dev/md0

myhand, как мы уже выясняли, raid1 читает поочередно с разных блоков. reiserfs ожидает видеть согласованные данные от хранилища нижнего уровня, а не разные. да и любая другая файловая система может быть подвержена тем же проблемам. просто у меня довольно часто перегружался сервер именно с reiserfs. там игнорирование mismatch_cnt гарантированно приводило к проблемам.

Ребята, спасибо. Но аптайм сервера 200 дней, ребутов даже до этого не делал по пару раз подряд.

У вас raid1?

Все чуть сложнее, вам объясняли как-то.

В общем, наверное этот сценарий имеет смысл в принципе. С другой стороны, соглассованность данных гарантируется ведением журнала.

Пока все-же больше похоже на проблемы конкретно reiserfs.

Какого рода проблемам, можно подробнее?

Они полностью прекращаются после внеочередной синхронизаций массива. Я давно эту конфигурацию наблюдаю и знаю о чем говорю. В случае рассинхронизации не работает даже reiserfschk, что означает полную фигню на диске. После синхронизации все нормально становится.

например так выглядит

[102486.375622] REISERFS error (device md1): vs-2100 add_save_link: search_by_key ([-1 1802542 0x1001 DIRECT]) returned 1

[102486.381161] REISERFS (device md1): Remounting filesystem read-only

[104091.351195] REISERFS warning (device md1): clm-6006 reiserfs_dirty_inode: writing inode 1676038 on readonly FS

На мой взгляд лучше два свора на разных дисках чем один в рейде

Так как если ситуация что своп недоступен приходит реже чем проблемы с фс на том же диске

Andreyka, это все с какой целью было сказано? своп равномерно распределяется по обоим дискам и в случае полного отказа одного из них с большей вероятностью получите произвольную проблему в редкозапускаемой программе.

Полного и удовлетворительного решения описываемой проблемы нет. Остается искать компромиссы и у каждого они свои. Например, полностью отключить своп для снижения вероятности появления mismatch_cnt. Он в основном не нужен на современных серверах.

Повторяю, не факт что проблема не связана конкретно с reiserfs.

В смысле, reiserfschk работает? Я бы не сказал что это "нормально".

Может имеет смысл заменить эту файловую систему?

[102486.375622] REISERFS error (device md1): vs-2100 add_save_link: search_by_key ([-1 1802542 0x1001 DIRECT]) returned 1

[102486.381161] REISERFS (device md1): Remounting filesystem read-only

[104091.351195] REISERFS warning (device md1): clm-6006 reiserfs_dirty_inode: writing inode 1676038 on readonly FS

Выглядит не как проблема с журналом. Что, по-идее - весьма странно.

Если Ганса упекли за решетку, продукт выданный ранее его командой не стал хуже. Код работает и без него. Все остальное - админские суеверия.

нет, в некоторых случаях reiserfschk не работает на рассихнронизированном raid1. Совсем ничего не чинит и останавливается. Если синхронизировать, то все работает.

Это вполне нормально и объяснимо. Файловые системы не пишутся из расчета на то, что данные раздела будут случайным образом меняться при считывании.

myhand

Да, raid1.

Тогда "просто забить", увы.

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

Файловая система в ядре - значит кто-то ее сопровождает. Я даже знаю как узнать кто ;)

Все это, однако, не гарантирует безошибочность ее работы и отсутствие багов в самой FS или утилитах.

Ага. А не потеряли-ли вы в процессе этого счастья какие-то данные?

А данные и не должны так меняться, если FS их правильно записала. Операция либо доведена до конца - либо все связанные с ней "данные" просто невалидны. В этом смысл журналирования.