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

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

---------- Добавлено в 00:29 ---------- Предыдущее сообщение было в 00:28 ----------

netwind, да ничего я от вас не хочу. Нужны вы мне. Можете спать идти.

вы там написали "md при repair просто выберет один блок случайным образом".

я думал уже другую ситуацию обсуждаете.

в тот момент когда вынул один из дисков в одном случае и запустил синхронизацию насильно в другом.

согласно mcelog, вроде нет, хотя мне не удалось добиться от вендора ответа и я плюнул. к тому же по полгода работает без проблем. Память правда не ECC.

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

вы предлагаете держать тонну контроллеров и запчасти к ним? Или что делать с этим барахлом, когда через 5 лет выйдет из строя контроллер? закупать еще 2 новых? та не вопрос. Прошу понять, что под надежностью понимается не только вероятность выхода из строя детальки, но так же вероятность проблем любых.

Проблема в том, что "цитата" не сводится к простому упоминанию "вумного слова". Дело вовсе не в DMA, а в том как система работает в подобном сценарии.

С метаданными fs такого, по идее, случиться не должно.

нет. Об этом написано в мане. нет.

какая разница? Метаданные - те же часто меняющиеся данные. И не важно, файл это или нет.

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

Ну, в этом случае также получится случайно. Мы же не всегда записали нужные блок на "первый диск"?

fs никуда не делась. Статистика у вас не ахти большая - так что увы.

Нет, объясняли же. Рейд считается "грязным" (грубо говоря) пока на него что-то пишет. Есть немалая вероятность "попасть" в момент, когда все чисто. Особенно, если система нагружена слабо.

Гарантия. Бекап. Цена контроллера << стоимости данных.

Важно. Система с метаданными fs, с ее журналом - должна работать иначе. Ее драйвер явно будет интересовать в нужных местах: что данные записаны.

Так что увы, пока незачет. Только словечки знакомые углядели - перевод не осилили ;)

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

Должен. Программы люди пишут, а не олимпийские боги.

"Вы мне запрещаете?" // mysql

там написано слово "будет" - это предложение как избежать подобной проблемы разработчикам.

Так почему именно синхронизация массива приводит к тому, что reiserfschk начинает работать нормально, а не останавливается как до синхронизации?

меня не устраивает ответ "значит так пишет". это нелогично. файловая система не может ничего знать о нижележащем уровне абстракции и что там вообще в md творится.

хотя я и не проверял другую fs, но выбор fs не должен влиять на md.

я уже объяснял вам, что это "предложение" - создать другую проблему, похлеще?

Спрашивайте reiserfschk, а точнее reiserfs.

Интересно, а как вы объясняете то, что синхронизация массива вам всегда помогает?

Если в работе fs нет ошибок.

а по-моему очень глобально и надежно. просто проверять придется чаще.

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

делаем нормальный массив и reiserfschk нормально работает.