Вообще по определению mismatch_cnt не равно нулю. Не видел я нулевых значений. много систем посмотрел. И, я так подозреваю, это суперблок, что правильно. Число различных секторов пропорционально размеру массива.
Наш "супер-кластер" всё-таки расыпался. Погасил я намеренно всё, чтобы данные не потерялись. Сейчас заканчивается восстановление, работы еще очень много. Безвовзвратно потеряли 8 мегабайт данных, слава богу, что всего 8. Ошибки учли, постараемся, чтобы больше такого небыло.
myhand: Это нормально в конкретной ситуации (использование swap и т.п.).
На показанном выше примере swap нет. swap находится на md3 (RAID0). Остальные массивы НЕ используются... Вот так вот всё просто.
myhand: Поподробнее. Опишите свои действия.
Объяснение покуда штатное из man md "SCRUBBING AND MISMATCHES", в частности учтите то что пишет рейд в ответ на check/repair. Например, после repair c исправленными mismatch_cnt!=0 - показатель md/mismatch_cnt будет ненулевым! Судя по приведенному выводу команд - для вас это неожиданность.
Этот рейд-массив НЕ использовался ещё ни разу. Собственно, массив собирается в первый раз.
myhand: А вы хотите офигенную отказоустойчивость бесплатно? Если "не много" по сравнению с контроллером - может и не стоит заморачиваться? - защита явно экономически малооправданна.
Гм. Ситуации бывают разные. Если я не хочу покупать адаптек за 60 тыс. рублей и в резерве держать еще один такой же - вполне понятно, почему. Кроме экономической целесообразности есть еще и другие факторы. Давайте оставим этот пустой разговор.
myhand: А что, теперь известно? Можно пример?
Дооо... Я почему-то считал, что RAID1 Это RAID1. Не больше и не меньше. но когда почему-то могут 1000 секторов различать на дисках - это не рейд. Я, к своему стыду, даже не могу сказать, какие это секторы. Ну у меня /boot отдельно. Как и /var и /tmp и /home. Странно, да?
myhand: Допустим, у меня mismatch_cnt = 1000 за месяц. Товарищ телепат, вам это что-то сказало об "активности использования" swap?
Я оценивал активность работы со swap по mismatch_cnt? Пожалуйста. процитируйте, где. Я оцениваю интенсивность работы swap другими средствами, у меня за этим смотрит мониторинг.
myhand: Поясните почему, пожалуйста.
В данном случае гарантировать время записи данных на диск можно, к примеру, используя PIO. Или писать данные с задержками, не полагаясь на электронику винта. Или считывать данные с винта сразу после записи для верификации.
myhand: А что, теперь известно? Можно пример?
Мдэ. А что, у меня данные на двух слабоиспользуемых винтах разные - ничего, да? Причем сразу же после ребилда массива. Это нормально, видимо, софт просто глючит и показывает мне бред, а на самом деле данные просто идентичны?
myhand: По какой причине - выяснили?
Как раз это мне и интересно. Винты в порядке. Записи почти нет.
myhand: Странно, что у вас отваливается только второй диск. Мягко говоря.
Отваливаются оба. А вот синхронизация начинается с первого. man md.
myhand: killall -s 9 kvm (в случае нагрузки - может поломаться, а для пустой виртуалки у меня получилось только что 3 из 3 взлетело нормально)
Да? А вы рейд внутри виртуалок поднимаете? Или чего? Я вот свой сервер резетом выдергивал.
myhand: А зачем у ФС журнал - вам понятно? Не затруднит изложить это понимание здесь?
Гм. Журнал ФС бесполезен, если повреждено целевое устройство. Он защищает только от пропадания питания. Собственно говоря, журнал существует для того, что в него записываются изменения в ФС, которые можно откатить в случае проблем.
myhand: Вот только почему-то в reiserfs есть механизмы для обеспечения целостности данных+метаданных, аналогичные ext3, например барьеры. Может перечислите эти самые дополнительные "предположения", требуемые от аппаратной части?
Как они помогут, эти барьеры, если на низком уровне ахинея? Т.е. как они помогут, когда, к примеру, винт при работе записывает в файл логическую единицу и отдает логическую единицу, а после резета отдает логический ноль? Вот как?
Ну и на засыпку. Чем объяснить то, что уже во время синхронизации намечается mismatch_cnt ?
netwind: разумеется нежурнализируемая ext2 разрушается на отлично при резете. тут и думать нечего.
Та ну? Правда, чтоли? Естественно, отказоустойчивость ниже. Но как, простите, ФС может перепутать файловые дескрипторы - это мне уже не понятно.
---------- Добавлено в 14:57 ---------- Предыдущее сообщение было в 14:56 ----------
netwind: читать просто нечего - новая записанная информация тоже попадает в кеш.
Гм. Ну, пишут они нормально, не очень уж и активно, если нет дефицита памяти. Если диски пишут с максимально возможной скоростью - что-то на веб-сервере не так...
myhand, Спасибо :). На день прошедший энергетика лучше - я в электричестве тружусь, переотмечал. Выше мной ахинея написана...
Конкретно всё заработает: 4-5 января. Тогда же будет увеличен и штат сотрудников.
---------- Добавлено в 23:06 ---------- Предыдущее сообщение было в 23:03 ----------
P.S. Это не значит, что оно завтра упадёт снова.
Не успел пройти бекап?
Нет. Бекап - это уже старые данные. Дело было не в нём, из бекапа поднялись.
Когда хостинг будет работать примерно?
ETA около 30 минут.
Вообще по определению mismatch_cnt не равно нулю. Не видел я нулевых значений. много систем посмотрел. И, я так подозреваю, это суперблок, что правильно. Число различных секторов пропорционально размеру массива.
Наш "супер-кластер" всё-таки расыпался. Погасил я намеренно всё, чтобы данные не потерялись. Сейчас заканчивается восстановление, работы еще очень много. Безвовзвратно потеряли 8 мегабайт данных, слава богу, что всего 8. Ошибки учли, постараемся, чтобы больше такого небыло.
В общем то я не просто технический специалист
В общем-то кроме самопиара вы ничего не можете. Ни одного слова по делу сказать.
Это нормально в конкретной ситуации (использование swap и т.п.).
На показанном выше примере swap нет. swap находится на md3 (RAID0). Остальные массивы НЕ используются... Вот так вот всё просто.
Поподробнее. Опишите свои действия.
Объяснение покуда штатное из man md "SCRUBBING AND MISMATCHES", в частности учтите то что пишет рейд в ответ на check/repair. Например, после repair c исправленными mismatch_cnt!=0 - показатель md/mismatch_cnt будет ненулевым! Судя по приведенному выводу команд - для вас это неожиданность.
Этот рейд-массив НЕ использовался ещё ни разу. Собственно, массив собирается в первый раз.
у меня нет долларовой карточки.
А в каком месте это проблема? PayPal примет и с долларовой и с рублевой и с гривны сконвертирует всё по курсу.
А вы хотите офигенную отказоустойчивость бесплатно? Если "не много" по сравнению с контроллером - может и не стоит заморачиваться? - защита явно экономически малооправданна.
Гм. Ситуации бывают разные. Если я не хочу покупать адаптек за 60 тыс. рублей и в резерве держать еще один такой же - вполне понятно, почему. Кроме экономической целесообразности есть еще и другие факторы. Давайте оставим этот пустой разговор.
А что, теперь известно? Можно пример?
Дооо... Я почему-то считал, что RAID1 Это RAID1. Не больше и не меньше. но когда почему-то могут 1000 секторов различать на дисках - это не рейд. Я, к своему стыду, даже не могу сказать, какие это секторы. Ну у меня /boot отдельно. Как и /var и /tmp и /home. Странно, да?
Допустим, у меня mismatch_cnt = 1000 за месяц. Товарищ телепат, вам это что-то сказало об "активности использования" swap?
Я оценивал активность работы со swap по mismatch_cnt? Пожалуйста. процитируйте, где. Я оцениваю интенсивность работы swap другими средствами, у меня за этим смотрит мониторинг.
Поясните почему, пожалуйста.
В данном случае гарантировать время записи данных на диск можно, к примеру, используя PIO. Или писать данные с задержками, не полагаясь на электронику винта. Или считывать данные с винта сразу после записи для верификации.
А что, теперь известно? Можно пример?
Мдэ. А что, у меня данные на двух слабоиспользуемых винтах разные - ничего, да? Причем сразу же после ребилда массива. Это нормально, видимо, софт просто глючит и показывает мне бред, а на самом деле данные просто идентичны?
По какой причине - выяснили?
Как раз это мне и интересно. Винты в порядке. Записи почти нет.
Странно, что у вас отваливается только второй диск. Мягко говоря.
Отваливаются оба. А вот синхронизация начинается с первого. man md.
killall -s 9 kvm
(в случае нагрузки - может поломаться, а для пустой виртуалки у меня получилось только что 3 из 3 взлетело нормально)
Да? А вы рейд внутри виртуалок поднимаете? Или чего? Я вот свой сервер резетом выдергивал.
А зачем у ФС журнал - вам понятно? Не затруднит изложить это понимание здесь?
Гм. Журнал ФС бесполезен, если повреждено целевое устройство. Он защищает только от пропадания питания. Собственно говоря, журнал существует для того, что в него записываются изменения в ФС, которые можно откатить в случае проблем.
Вот только почему-то в reiserfs есть механизмы для обеспечения целостности данных+метаданных, аналогичные ext3, например барьеры. Может перечислите эти самые дополнительные "предположения", требуемые от аппаратной части?
Как они помогут, эти барьеры, если на низком уровне ахинея? Т.е. как они помогут, когда, к примеру, винт при работе записывает в файл логическую единицу и отдает логическую единицу, а после резета отдает логический ноль? Вот как?
Ну и на засыпку. Чем объяснить то, что уже во время синхронизации намечается mismatch_cnt ?
Personalities : [raid1] [raid0]
md4 : active raid1 sdc[0] sdd[1]
976762496 blocks [2/2] [UU]
md0 : active raid1 sdb1[1] sda1[0]
521984 blocks [2/2] [UU]
md2 : active raid0 sdb3[1] sda3[0]
20964352 blocks 256k chunks
md3 : active raid1 sda5[2] sdb5[1]
923809664 blocks [2/1] [_U]
[============>........] recovery = 64.0% (592067648/923809664) finish=684.8min speed=8072K/sec
md1 : active raid1 sdb2[1] sda2[0]
41945600 blocks [2/2] [UU]
unused devices: <none>
[root@nemo ~]# cat /sys/block/md3/md/mismatch_cnt
1280
разумеется нежурнализируемая ext2 разрушается на отлично при резете. тут и думать нечего.
Та ну? Правда, чтоли? Естественно, отказоустойчивость ниже. Но как, простите, ФС может перепутать файловые дескрипторы - это мне уже не понятно.
---------- Добавлено в 14:57 ---------- Предыдущее сообщение было в 14:56 ----------
читать просто нечего - новая записанная информация тоже попадает в кеш.
Гм. Ну, пишут они нормально, не очень уж и активно, если нет дефицита памяти. Если диски пишут с максимально возможной скоростью - что-то на веб-сервере не так...