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

может быть нигде. в конце концов, write cache на дисках включен (он у многих включен)

как бы ни старался md, часть данных может не записаться.

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

Тогда это тоже баг - либо в md, либо где-то уже ниже (вплоть до прошивки контроллера). По идее, write cache не должен мешать md, "if the programmers make the right call(s)" (тм).

barrier=1 (правда, md тоже должен их поддерживать, как и ФС, и LVM - если есть) должны исключить ситуацию с порчей данных ФС при резете из-за подобных вещей - но на это вроде не похоже.

Да, если бы вы исключили "манипуляции" с reiserfs непосредственно на дисках (загрузчик).

Гм. Ситуации бывают разные. Если я не хочу покупать адаптек за 60 тыс. рублей и в резерве держать еще один такой же - вполне понятно, почему. Кроме экономической целесообразности есть еще и другие факторы. Давайте оставим этот пустой разговор.

Дооо... Я почему-то считал, что RAID1 Это RAID1. Не больше и не меньше. но когда почему-то могут 1000 секторов различать на дисках - это не рейд. Я, к своему стыду, даже не могу сказать, какие это секторы. Ну у меня /boot отдельно. Как и /var и /tmp и /home. Странно, да?

Я оценивал активность работы со swap по mismatch_cnt? Пожалуйста. процитируйте, где. Я оцениваю интенсивность работы swap другими средствами, у меня за этим смотрит мониторинг.

В данном случае гарантировать время записи данных на диск можно, к примеру, используя PIO. Или писать данные с задержками, не полагаясь на электронику винта. Или считывать данные с винта сразу после записи для верификации.

Мдэ. А что, у меня данные на двух слабоиспользуемых винтах разные - ничего, да? Причем сразу же после ребилда массива. Это нормально, видимо, софт просто глючит и показывает мне бред, а на самом деле данные просто идентичны?

Как раз это мне и интересно. Винты в порядке. Записи почти нет.

Отваливаются оба. А вот синхронизация начинается с первого. man md.

Да? А вы рейд внутри виртуалок поднимаете? Или чего? Я вот свой сервер резетом выдергивал.

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

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

Ну и на засыпку. Чем объяснить то, что уже во время синхронизации намечается mismatch_cnt ?

из-за кеша записи на одном винте данные могут успеть записаться, а на втором могут не успеть.

хотя у меня не происходит пропадания питания - у меня внезапная перезагрузка.

я не представляю зачем grub legacy писать по диску. надо код смотреть.

писать файлы можно на устройство md с reiserfs, а загрузчик размещать в mbr /dev/sda и /dev/sdb. трогать файловые системы на sda и sdb вроде бы и не нужно.

Больше нет. Цена - основной критерий, определяющий риски и бюджет защиты.

Заявляется, что подобная ситуация возникает только в двух случаях:

1) кто-то трогает явно один из дисков, минуя рейд

2) приложение работает с сильно временными данными, в ситуации когда оно *в принципе* не собирается их позднее читать (mmap, swap и т.п.)

Обе в принципе, не позволяют утверждать наглость "это не рейд".

А вот это мне тоже не нравится. Не знаю, однако, может последние ядра дают администратору больше информации (например, в /sys/). Надо бы почитать...

Вроде только в тодо:

http://neil.brown.name/blog/20110216044002#12

Нет, конечно. Просто "большие" по абсолютной величине mismatch_cnt (~1k) - ровно ничего не говорят порой об интенсивности использования swap.

Это нормально в конкретной ситуации (использование swap и т.п.).

Начните с того, что отключите swap.

Это простой тест, забыли? kill -9 как раз приблизительно эквивалентен внезапному отключению питания. С физической железкой, конечно, лучше - но не думаю что есть принципиальная разница в данном случае.

Неуд.

На низком уровне _не может_ быть ахинеи, когда этот самый уровень (или уровни, к примеру если у вас между ФС и диском еще и LVM есть) барьеры поддерживает. Вы бы познакомились немного с предметом.

Поподробнее. Опишите свои действия.

Объяснение покуда штатное из man md "SCRUBBING AND MISMATCHES", в частности учтите то что пишет рейд в ответ на check/repair. Например, после repair c исправленными mismatch_cnt!=0 - показатель md/mismatch_cnt будет ненулевым! Судя по приведенному выводу команд - для вас это неожиданность.

Ну и плевать. ФС с барьерами просто не посчитает такую транзакцию.

да хоть savedefault?

Трогать определенно нужно, вопрос лишь в том - только ли на чтение.

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

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

Не запишется, учим матчасть.

Это *пример*.

Какую еще матчасть?

Есть два отдельных физических диска. Блины на них крутятся сами по себе. Одни и те же команды выполняются за разное время.

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

В моем случае еще не известно прерывает ли. Питание-то никуда не пропадает.

Для исключения этой проблемы железные контроллеры делают с памятью и батарейкой.

Тут, вообще-то, должна сработать метка грязности в dmraid, но из-за ncq не известно записалась ли она раньше или позже данных и записалась ли вообще. Пока мне не известно есть ли у dmraid какие-то собственные барьеры. Скорее всего нет, потому что это ухудшит производительность.

В принципе еще до появления ncq подобное поведение было у scsi-устройств и даже до появления барьеров в ядре как таковых. Так что dmraid должен бы учитывать эту ситуацию.

На показанном выше примере swap нет. swap находится на md3 (RAID0). Остальные массивы НЕ используются... Вот так вот всё просто.

Этот рейд-массив НЕ использовался ещё ни разу. Собственно, массив собирается в первый раз.

Есть, конечно. Их md и пользует.

Потому по-умолчанию все и выключено. Как минимум, для ext3/reiserfs. ext4 вроде уже включает по-умолчанию.

Как воспроизвести проблему? На уровне "для идиотов", пожалуйста: берем то-то, выполняем такие-то команды, делаем то-то, смотрим на вывод таких-то команд...

(Совсем хорошо, если получится без реальной железки, в qemu/kvm - железки трогать влом ;))