myhand, Спасибо :). На день прошедший энергетика лучше - я в электричестве тружусь, переотмечал. Выше мной ахинея написана...
Конкретно всё заработает: 4-5 января. Тогда же будет увеличен и штат сотрудников.---------- Добавлено в 23:06 ---------- Предыдущее сообщение было в 23:03 ----------P.S. Это не значит, что оно завтра упадёт снова.
Нет. Бекап - это уже старые данные. Дело было не в нём, из бекапа поднялись.
ETA около 30 минут.
Вообще по определению mismatch_cnt не равно нулю. Не видел я нулевых значений. много систем посмотрел. И, я так подозреваю, это суперблок, что правильно. Число различных секторов пропорционально размеру массива.
Наш "супер-кластер" всё-таки расыпался. Погасил я намеренно всё, чтобы данные не потерялись. Сейчас заканчивается восстановление, работы еще очень много. Безвовзвратно потеряли 8 мегабайт данных, слава богу, что всего 8. Ошибки учли, постараемся, чтобы больше такого небыло.
В общем-то кроме самопиара вы ничего не можете. Ни одного слова по делу сказать.
На показанном выше примере swap нет. swap находится на md3 (RAID0). Остальные массивы НЕ используются... Вот так вот всё просто.
Этот рейд-массив НЕ использовался ещё ни разу. Собственно, массив собирается в первый раз.
А в каком месте это проблема? PayPal примет и с долларовой и с рублевой и с гривны сконвертирует всё по курсу.
Гм. Ситуации бывают разные. Если я не хочу покупать адаптек за 60 тыс. рублей и в резерве держать еще один такой же - вполне понятно, почему. Кроме экономической целесообразности есть еще и другие факторы. Давайте оставим этот пустой разговор.
Дооо... Я почему-то считал, что RAID1 Это RAID1. Не больше и не меньше. но когда почему-то могут 1000 секторов различать на дисках - это не рейд. Я, к своему стыду, даже не могу сказать, какие это секторы. Ну у меня /boot отдельно. Как и /var и /tmp и /home. Странно, да?
Я оценивал активность работы со swap по mismatch_cnt? Пожалуйста. процитируйте, где. Я оцениваю интенсивность работы swap другими средствами, у меня за этим смотрит мониторинг.
В данном случае гарантировать время записи данных на диск можно, к примеру, используя PIO. Или писать данные с задержками, не полагаясь на электронику винта. Или считывать данные с винта сразу после записи для верификации.
Мдэ. А что, у меня данные на двух слабоиспользуемых винтах разные - ничего, да? Причем сразу же после ребилда массива. Это нормально, видимо, софт просто глючит и показывает мне бред, а на самом деле данные просто идентичны?
Как раз это мне и интересно. Винты в порядке. Записи почти нет.
Отваливаются оба. А вот синхронизация начинается с первого. man md.
Да? А вы рейд внутри виртуалок поднимаете? Или чего? Я вот свой сервер резетом выдергивал.
Гм. Журнал ФС бесполезен, если повреждено целевое устройство. Он защищает только от пропадания питания. Собственно говоря, журнал существует для того, что в него записываются изменения в ФС, которые можно откатить в случае проблем.
Как они помогут, эти барьеры, если на низком уровне ахинея? Т.е. как они помогут, когда, к примеру, винт при работе записывает в файл логическую единицу и отдает логическую единицу, а после резета отдает логический ноль? Вот как?
Ну и на засыпку. Чем объяснить то, что уже во время синхронизации намечается mismatch_cnt ?
Та ну? Правда, чтоли? Естественно, отказоустойчивость ниже. Но как, простите, ФС может перепутать файловые дескрипторы - это мне уже не понятно.---------- Добавлено в 14:57 ---------- Предыдущее сообщение было в 14:56 ----------
Гм. Ну, пишут они нормально, не очень уж и активно, если нет дефицита памяти. Если диски пишут с максимально возможной скоростью - что-то на веб-сервере не так...
