Проблема в том, что "цитата" не сводится к простому упоминанию "вумного слова". Дело вовсе не в DMA, а в том как система работает в подобном сценарии.
С метаданными fs такого, по идее, случиться не должно.
Вам читать до посинения раздел SCRUBBING AND MISMATCHES. Не путайте его с UNCLEAN SHUTDOWN ;)
Речь ведь у вас шла о "чистом" массиве, или уже забыли?
Для меня - она от цитаты из багзиллы центоса яснее не стала. Я уже упоминал, что не исключаю подобный вариант и в коде файловой системы. Но для этого, ее потроха надо хорошо знать.
Можете просветить нас подробнее насчет "ясности". Можно даже по-буржуйски ;)
Почему "принципиальная проблема md" - не бред? Где вы исключили reiserfs?
Но не память?
Это выбор в пользу глупости, причем очевидной. Боюсь, если проблема все-таки в райд - это баг, причем не настолько примитивный.
Кстати, а ncq пробовали отключить (или получается слишком накладно)?
Каким образом "решит" - потерей данных случайным образом?
Отказала фантазия? 🍿
А как еще, если оба хорошо читаются?
// Разве, с write-mostly дисками может быть несколько иначе. Хотя, с чего вдруг?
т.е. ты не знаешь?
Возьми с полки пирожок, троллюшко.
Точно также, как может и до. Ребут - непричем.
Никак mismatch_cnt!=0 не устранить для raid1, если оба блока читаются. md при repair просто выберет один блок случайным образом.
Значит так пишет его.
Кстати, а почему вообще ребуты происходят - может память сбоит?
Если загрузилось - всегда? А если вообще перезагрузить штатно - точно все всегда взлетит?
А какая у вас вообще статистика, сколько ребутов?
Багзилла? - Бубунтоиды телепатически с мейнтейнерами общаются?
А почему все-таки не reiserfs? Добрые дяди вам привели примеры когда mismatch_cnt возникает в процессе "нормальной" работы. Почему вы походя грешите на Нейла, а убивец Ганс выглядит непогрешимым? 🍿
Самый интересный вопрос: почему "принципиальная проблема" - cофтрейд принципиально невозможен, или просто руки у линуксячих программистов принципиально кривые?
Как андрейка. "Знаю/имею, но не скажу/покажу" - на поверку знаний и умений пшик. Т.е. конкретного рецепта нет. Так и напишите.
"Рассинхронизированность" возникает постоянно в raid1, при самой обычной работе, в разных сценариях (swap, mmap, etc). Вы совершенно произвольно связали ее с перезагрузкой. "По идее" - ничего плохого от этого не должно быть.
Возможно, ваш сценарий - обычный крах fs, не использующей барьеров (коммит записался вперед журнала). Включите - на новых ядрах должно помочь (правда "цена" может не понравиться).
То, но "все немножко не так" (с) - обсудили выше.
Забавно, что после синхронизации он у вас все чинит всегда. Я правильно понял?
Ну тогда в чем проблема - обновляйте. Если это приведет к потере халявного администрирования - ищите другие варианты обновления, я вам предлагал.
Было бы полезно, если о таких вещах вы бы упомянули с самого начала.
Один - не написал что он делал кроме безумного изменения расписания. Другой - просто продолжает тупить.
Например?
Почему вы так уверены, что нет иных причин? Нагрузка достаточно специфичная.
Вот это, кстати, полезно что напомнили. Сам ionice не ругается, даже если шедулер не поддерживает приоритизацию.
В суперблок пишется, насколько я понимаю.
Это была бы русская рулетка (при письме!), а мы таки о райд говорим ;) Слишком наивная точка зрения - не думаю что все настолько плохо.
Ман, к сожалению, мягко говоря - не идеален. На самом деле dirty помечается массив только пока данные туда актуально не записаны. Ничего не пишем - все вновь чисто.
Вам все уже объяснили. Источник проблемы - чтение рассинхронизированного массива, а во-вторых - конкретная fs. Так она контролирует целостность журнала и данных.
Я не телепат, в отличие от. Зависит от нагрузки, ее типа, расписания бекапа и проверок...
А теперь посоветуйте что-то практически. Как вы это замечание собираетесь реализовать для произвольного приложения "скрипт бекапа"?
