Сейчас умеют (grub2), но это неважно. Кроме того, даже если "умеют" - должны быть сконфигурированы соответственно.
Добрый дядя из RH говорит обратное, но мы знаем лучше - верно?
Нельзя телепатически определить как сконфигурирован загрузчик, так что считаю данный источник проблемы вполне вероятным.
файловая система всегда проверяется fsck при внезапной перезагрузке?
Я не пропустил, просто не посчитал нужным отвечать. С учетом последних "откровений" - у вас больше похоже на то, что источником проблемы является загрузчик:
Есть что сказать по этому поводу - или данный вариант отмели?
c ext3/reiserfs также есть такая вероятность, см. зачем опции barrier у mount.
А вы хотите офигенную отказоустойчивость бесплатно? Если "не много" по сравнению с контроллером - может и не стоит заморачиваться? - защита явно экономически малооправданна.
А что, теперь известно? Можно пример?
Вы выглядите как "знаток" файловых систем. Вот только почему-то в reiserfs есть механизмы для обеспечения целостности данных+метаданных, аналогичные ext3, например барьеры. Может перечислите эти самые дополнительные "предположения", требуемые от аппаратной части?
Допустим, у меня mismatch_cnt = 1000 за месяц. Товарищ телепат, вам это что-то сказало об "активности использования" swap?
Пишет в файл, т.к. MySQL о секторах не знает. Пишет часто. Вы назвали конкретную цифирь - я привел пример обычного для нее приложения.
Поясните почему, пожалуйста.
По какой причине - выяснили?
Странно, что у вас отваливается только второй диск. Мягко говоря.
killall -s 9 kvm
(в случае нагрузки - может поломаться, а для пустой виртуалки у меня получилось только что 3 из 3 взлетело нормально).
А зачем у ФС журнал - вам понятно? Не затруднит изложить это понимание здесь?
Ну, значит ничего не поняли :(
Запускайте "понемножку", инкрементами. Я упоминал и этот вариант.
Персонально вам ответили.
Что все "зааптимизированно", я и не сомневаюсь. Тем не менее, нормально настроить - надо. Кстати, возможно имеет смысл и ограничить утилизацию диска проверкой рейда - обычными крутилками sync_speed_max/min. Это помимо приоритетов и вообще, того что написали вам ранее.
Диски ломаются, беды появляются.
Ну, непонятно - и ладно. Кто хотел и в состоянии понять - давно осилил хоть man md прочитать.
Получая данные из астрала? :)
Это "многое объясняет". Загрузчик может напрямую ковыряться с диском, не обращая внимание на то, что он в райд.
Подобная причина "рассинхронизации" тоже обсуждалась в багах redhat/debian по поводу mismatch_cnt & raid1. Вынесите /boot отдельно (как делает любой нормальный дистрибутив, если "аптимизаторы" не бъют его по рукам).
И вполне возможно - md только повод для того, чтобы проблема стала очевидной.
Так по вашему же предположению - на диске записано местами черти-что. "Этот блок хороший, годный - а вон тот оказался на другом блине". Выходит, вам всегда везет - или поясните?
Не обязан, т.к. проблема может быть связана с ней. Воспроизведите хоть проблему (qemu вам в помощь), лучше - с другой fs. Вот тогда будет очевидно, что мое предположение неверно.
Кстати, /boot у вас случайно не на том же md+reiserfs?
Данные будете терять + лишнии синхронизации.
Ну и зачем вам такой "райд"?
И это единственное предположение - запись ему вообще не интересна?
А не должен - там же каша. Один блок такой - другой сякой, если уж у вас были mismatch_cnt.
Для этого не нужно знать "творимое в md" - нужно просто сделать в приложении (fs в данном случае) некорректные в общем случае допущения. Может и один диск у вас отвалится - просто с парой в рейд такое случается чаще, а статистика невелика.
К примеру выше с mmap - программист неправ, если подразумевает, что предыдущие данные уже записаны, к моменту когда он затеял записать в mmap-ный файл новые.
Бага нет. О проблеме никому, кроме вас не известно. Ну и напрасно ждете, что добрый дядя будет бесплатно ковыряться.
я уже объяснял вам, что это "предложение" - создать другую проблему, похлеще?
Спрашивайте reiserfschk, а точнее reiserfs.
Интересно, а как вы объясняете то, что синхронизация массива вам всегда помогает?
Если в работе fs нет ошибок.
Ну, в этом случае также получится случайно. Мы же не всегда записали нужные блок на "первый диск"?
fs никуда не делась. Статистика у вас не ахти большая - так что увы.
Нет, объясняли же. Рейд считается "грязным" (грубо говоря) пока на него что-то пишет. Есть немалая вероятность "попасть" в момент, когда все чисто. Особенно, если система нагружена слабо.
Гарантия. Бекап. Цена контроллера << стоимости данных.
Важно. Система с метаданными fs, с ее журналом - должна работать иначе. Ее драйвер явно будет интересовать в нужных местах: что данные записаны.
Так что увы, пока незачет. Только словечки знакомые углядели - перевод не осилили ;)
Вообще-то - должен. В том смысле, что хоть не должен допускать скрытой рассинхронизации массива.
Должен. Программы люди пишут, а не олимпийские боги.
"Вы мне запрещаете?" // mysql
