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

netwind, А если питание пропадёт? Тогда как?

Raistlin, ну что вы как маленький - тогда ups с уведомлением сделайте.

netwind, Блок питания сгорит? Контроллер на мамке умрёт? И т.п.? А система рассчитана так, что диск выдергивается немедленно и втыкается в другой аналогичный аппарат. И дисков там в RAID1 аж 4 штуки стоят... И система эта используется совсем не для размещения сайтов. Долгий простой может и жизни стоить. Хватит давать глупые советы. Мне сейчас придётся пачку экспериментов поставить, только и всего.

Точно также, как может и до. Ребут - непричем.

Никак mismatch_cnt!=0 не устранить для raid1, если оба блока читаются. md при repair просто выберет один блок случайным образом.

Значит так пишет его.

Кстати, а почему вообще ребуты происходят - может память сбоит?

Если загрузилось - всегда? А если вообще перезагрузить штатно - точно все всегда взлетит?

А какая у вас вообще статистика, сколько ребутов?

Багзилла? - Бубунтоиды телепатически с мейнтейнерами общаются?

А почему все-таки не reiserfs? Добрые дяди вам привели примеры когда mismatch_cnt возникает в процессе "нормальной" работы. Почему вы походя грешите на Нейла, а убивец Ганс выглядит непогрешимым? 🍿

Самый интересный вопрос: почему "принципиальная проблема" - cофтрейд принципиально невозможен, или просто руки у линуксячих программистов принципиально кривые?

Случайным ли?

А как еще, если оба хорошо читаются?

// Разве, с write-mostly дисками может быть несколько иначе. Хотя, с чего вдруг?

поставьте нормальный raid с батарейкой.

В md так делать не надо. Нужно пометить диск как свободный. Потом подать команду на отключение в порт sata и уже потом выдергивать.

написано, что для raid1 выбирается первый For RAID1, this involves copying the contents of the first drive onto all other drives.

выглядит как бред.

Если штатно или по команде от ups, то все нормально.

допустим, около 15 раз за 3 года. Проблема с железом, но менять материнку накладно будет.

Скорее всего, сделан выбор в пользу производительности. Вместо того чтобы проконтролировать ответ от обоих дисков на команду записи метки и только потом писать данные, выбрали просто запись всех команд подряд чтобы ncq раскидал там уже.

еще можно любой примонтированный md считать грязным, тогда наверное это решит проблему 100%, но приведет к слишком частым проверкам.

при репэйр - с первого диска. а вообще вот вам ля размышлений. собсна картина с рейзером чуть яснее:

Suppose I memory-map a file and often modify the mapped memory.

The system will at some point decide to write that block of the file

to the device. It will send a request to raid1, which will send one

request each to two different devices. They will each DMA the data

out of that memory to the controller at different times so they could

quite possibly get different data (if I changed the mapped memory

between those two DMA request). So the data on the two drives in a

mirror can easily be different. If a ‘check’ happens at exactly this

time it will notice.

Normally that block will be written out again (as it is still ‘dirty’)

and again and again if necessary as long as I keep writing to the

memory. Once I stop writing to the memory (e.g. close the file,

unmount the filesystem) a final write will be made with the same data

going to both devices. During this time we will never read that block

from the filesystem, so the filesystem will never be able to see any

difference between the two devices in a raid1.

So: if you are actively writing to a file while ‘check’ is running on

a raid1, it could show up as a difference in mismatch_cnt. But you

have to get the timing just right (or wrong).

I think it is possible in the above scenario to truncate the file

while a write is underway but with new data in memory. If you do

this, the system might not write out that last ‘new’ data, so the last

write to the particular block on storage may have written different

data to the two different drives, and this difference will not be

corrected by the filesystem e.g on unmount. Note that the inconsistent

data will never be read by the filesystem (the file has been

truncated, remember) so there is no risk of data corruption.

In this case the difference could remain for some time until later

when a ‘check’ or ‘repair’ notices it.

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

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

Это не тот вариант. Не надежно по другим параметрам.

Вам читать до посинения раздел SCRUBBING AND MISMATCHES. Не путайте его с UNCLEAN SHUTDOWN ;)

Речь ведь у вас шла о "чистом" массиве, или уже забыли?

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

Можете просветить нас подробнее насчет "ясности". Можно даже по-буржуйски ;)

Почему "принципиальная проблема md" - не бред? Где вы исключили reiserfs?

Но не память?

Это выбор в пользу глупости, причем очевидной. Боюсь, если проблема все-таки в райд - это баг, причем не настолько примитивный.

Кстати, а ncq пробовали отключить (или получается слишком накладно)?

Каким образом "решит" - потерей данных случайным образом?

Отказала фантазия? 🍿

допустим, ваша трагедия понятна. ну а от меня то вы что хотите?