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

Ладно, суть понял, что нужно уменьшить интервал как он был до месяца чтобы не рисковать) Ограничивать скорость не хочется по той причине что и так пару дней синхронизируется, ну да ладно, попробую. А вообще конечно надо не запускать сервера до такой нагрузки, но что уж теперь говорить.

Ну, значит ничего не поняли :(

Запускайте "понемножку", инкрементами. Я упоминал и этот вариант.

Данные в данном случае стоят не много. Здесь другая ситуация. Сам по себе контроллер - дополнительные грабли при восстановлении, случись что с аппаратной начинкой. Система построена так, что нужно её быстро запустить и она не должна вызывать коллизий. До текущего момента мне было не известно о проблемах рассинхронизации md. Придётся пересматривать этот момент.

Но не ReiserFS. Она работает несколько быстрее, как раз и за счет того, что пологается на аппаратную начинку. Здесь даже не от ФС зависит. Несколько странно было бы после каждой записи делать Verify.

В штатном случае своп использоваться НЕ должен. Если он настолько активно используется - это значит, что системе не хватает ресурсов и их НАДО добавить. Т.е. использование свопа сигнализирует о проблеме.

В данном случае - даже MySQL не пишет несколько раз в секунду на диск данные в один и тот же сектор в течении продолжительного времени. Специфика MySQL такова, что он в основном производит много чтений, которые как раз забиваются в кеш ОС. А отложенной записи опять же на правильно настроенной системе нет.

Софт-рейд в данном случае убьет производительность к чертям. Собственно, поэтому и не делает. Я так понимаю, этот момент там организован хуже даже чем в Fake-RAID.

---------- Добавлено в 09:08 ---------- Предыдущее сообщение было в 08:26 ----------

Итак, на вполне работающем массиве наблюдается mismatch. При перезагрузке данные разные на дисках, но всё же синхронизируется у меня с первого рейда. Я так и не смог симулировать ситуацию, когда рейд будет запущен после резета в синхронизированном состоянии. А вот замечательный фэйл: виртуальная машина после резета на ext2 полностью разрушила свою ФС. не смотря ни на какие рейды... 70% данных находятся в lost+found. Очень занимательная ситуация... Активно скриптом вставлялись данные в MySQL, ФС была примонтирована с Defaults. Много думаю...

myhand, кажется, пропустили :

надо же определиться в чем конкретно вы подозреваете reiserfs.

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

разумеется нежурнализируемая ext2 разрушается на отлично при резете. тут и думать нечего.

Та ну? Правда, чтоли? Естественно, отказоустойчивость ниже. Но как, простите, ФС может перепутать файловые дескрипторы - это мне уже не понятно.

---------- Добавлено в 14:57 ---------- Предыдущее сообщение было в 14:56 ----------

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

Я не пропустил, просто не посчитал нужным отвечать. С учетом последних "откровений" - у вас больше похоже на то, что источником проблемы является загрузчик:

Есть что сказать по этому поводу - или данный вариант отмели?

c ext3/reiserfs также есть такая вероятность, см. зачем опции barrier у mount.

А вы хотите офигенную отказоустойчивость бесплатно? Если "не много" по сравнению с контроллером - может и не стоит заморачиваться? - защита явно экономически малооправданна.

А что, теперь известно? Можно пример?

Вы выглядите как "знаток" файловых систем. Вот только почему-то в reiserfs есть механизмы для обеспечения целостности данных+метаданных, аналогичные ext3, например барьеры. Может перечислите эти самые дополнительные "предположения", требуемые от аппаратной части?

Допустим, у меня mismatch_cnt = 1000 за месяц. Товарищ телепат, вам это что-то сказало об "активности использования" swap?

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

Поясните почему, пожалуйста.

По какой причине - выяснили?

Странно, что у вас отваливается только второй диск. Мягко говоря.

killall -s 9 kvm

(в случае нагрузки - может поломаться, а для пустой виртуалки у меня получилось только что 3 из 3 взлетело нормально).

А зачем у ФС журнал - вам понятно? Не затруднит изложить это понимание здесь?

ни grub, ни grub2, ни lilo не умеют грузиться с md raid отличного от raid1.

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

кроме того, я приводил сообщения из dmesg, которые возникли уже спустя часы после загрузки.

Сейчас умеют (grub2), но это неважно. Кроме того, даже если "умеют" - должны быть сконфигурированы соответственно.

Добрый дядя из RH говорит обратное, но мы знаем лучше - верно?

Нельзя телепатически определить как сконфигурирован загрузчик, так что считаю данный источник проблемы вполне вероятным.

файловая система всегда проверяется fsck при внезапной перезагрузке?

не очень давно пробовал поставить убунту на raid10 одним разделом чисто поржать - спокойно поставилась, но не загрузилась. grub2 там и был. как надо было его настроить ?

ну давайте ссылку. я что-то не очень понимаю о чем речь. считаю, что проблемы с загрузкой с raid и есть та причина, по которой дистрибутивы при разбивке /boot выносят в отдельный раздел.

нет, зачем ? обычно достаточно проиграть лог. по крайней мере на одном диске или надежном raid должно быть достаточно.

Вcех с днем рождения Ганса Рейзера, кстати.

Смотрите документацию для grub соответствующей версии.

https://bugzilla.redhat.com/show_bug.cgi?id=566828

В баге дебиана тоже упоминали, лень искать.

Райд не обязан быть надежным, если администратор настроил систему так, что она молча ковыряет один из его дисков.

А день рождения Чикатилло вы тоже отмечаете? 🍿