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

Для этого не нужно знать "творимое в md" - нужно просто сделать в приложении (fs в данном случае) некорректные в общем случае допущения. Может и один диск у вас отвалится - просто с парой в рейд такое случается чаще, а статистика невелика.

К примеру выше с mmap - программист неправ, если подразумевает, что предыдущие данные уже записаны, к моменту когда он затеял записать в mmap-ный файл новые.

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

Это невозможно сделать в приложении. Старательно построенные программистами абстракции тщательно скрывают такие тонкости. Они всплывают только случайно, как в описываемом случае.

мне достаточно того, что вы перестанете гнать хулу на рейзерфс и признаете свои доводы неверными.

Данные будете терять + лишнии синхронизации.

Ну и зачем вам такой "райд"?

И это единственное предположение - запись ему вообще не интересна?

А не должен - там же каша. Один блок такой - другой сякой, если уж у вас были mismatch_cnt.

не единственное.

---------- Добавлено в 22:43 ---------- Предыдущее сообщение было в 22:41 ----------

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

Руки кривые у всех людей

И программисты вполне могут допустить ошибку

Ну так найди ее и исправь. Мы знаем, ты можешь

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

Так по вашему же предположению - на диске записано местами черти-что. "Этот блок хороший, годный - а вон тот оказался на другом блине". Выходит, вам всегда везет - или поясните?

Не обязан, т.к. проблема может быть связана с ней. Воспроизведите хоть проблему (qemu вам в помощь), лучше - с другой fs. Вот тогда будет очевидно, что мое предположение неверно.

Кстати, /boot у вас случайно не на том же md+reiserfs?

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

---------- Добавлено в 23:05 ---------- Предыдущее сообщение было в 23:05 ----------

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

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

Я правильно понимаю, что ваше предположение подразумевает, что reiserfs "сам себя рушит" и в следствии ошибок в коде записывает на разные диски md разную информацию?

Получая данные из астрала? :)

Это "многое объясняет". Загрузчик может напрямую ковыряться с диском, не обращая внимание на то, что он в райд.

Подобная причина "рассинхронизации" тоже обсуждалась в багах redhat/debian по поводу mismatch_cnt & raid1. Вынесите /boot отдельно (как делает любой нормальный дистрибутив, если "аптимизаторы" не бъют его по рукам).

Спросил вроде нормально всего несколько часов назад, а тут 5 страниц споров, перечитал и однозначного ответа я не услышал :) На счёт ionice, работает он нормально, иначе бы и бекапы не смог делать безболезнено, но если добавить синхронизацию к бекапам, то возникает взаимный тормаз, система просто на пределе. Я не говорю что всё так плохо что приходится ждать открытия сайтов до минуты, но секунд 5-10 уже гарантировано. И как бы тут не нужно говорить что что-то настроить я должен, тут ничего не настроить, всё и так оптимизированно, просто исчерпан лимит дисковый, нужно либо расселять крупные сайты либо добавлять диски. (отдельно под бекапы, базу, кеш.. и т.д.)

Очень смутил ответ что при полугодовой проверке у меня уже давно не раид. С чего это вдруг не раид, если раид, я проверяю систему на ошибки - их нет, да и жалоб о пропаже файлов за последние пол-года не было (первые полгода уже прошли), да и база там же, всё вроде отлично, /proc/mdstat также говорит что всё ок. Причём на одном из серверов как то умирал первый диск, пришлось помучиться, так как на втором почему то не было mtr записи от груба и запуск с него не шёл. Но это связано скорее с тем что на втором диске раздел /boot в любом случае не через raid. Сами же данные пока "вроде" не были потеряны.

Мне не понятно с чего вдруг должны быть расхождения на дисках, система работает себе и работает, сихронизирует и синхронизирует. Я не говорю о внезапных ресетах, это дело понятное, что черевато проблемали. Наверное если в дебиане по умолчанию рекомендуемое месяц, то это достаточно надёжно, а если я увеличил эту норму всего в 6 раз, ещё не означает что всё пойдёт в пух и прах, для меня это не показатель 🍿

И не судите строго, сисадминство не мой профиль, но приходится и в этой сфере разбираться. ;)

Персонально вам ответили.

Что все "зааптимизированно", я и не сомневаюсь. Тем не менее, нормально настроить - надо. Кстати, возможно имеет смысл и ограничить утилизацию диска проверкой рейда - обычными крутилками sync_speed_max/min. Это помимо приоритетов и вообще, того что написали вам ранее.

Диски ломаются, беды появляются.

Ну, непонятно - и ладно. Кто хотел и в состоянии понять - давно осилил хоть man md прочитать.