Это рассинхронизация массива?

Ничего не понятно, покажи полный вывод /proc/mdstat

Вот. Всего у меня 3 массива. Один в полном порядке, два других – описанная ситуация.

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md125 : active (read-only) raid5 dm-16[0] dm-22[1]
      2147219456 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
      bitmap: 2/8 pages [8KB], 65536KB chunk

md126 : active (read-only) raid6 dm-19[1] dm-10[5] dm-15[4]
      6442186752 blocks super 1.2 level 6, 512k chunk, algorithm 2 [4/3] [_UUU]
      bitmap: 4/24 pages [16KB], 65536KB chunk

md127 : active raid1 dm-1[1] dm-0[0]
      249926976 blocks super 1.2 [2/2] [UU]
      bitmap: 1/2 pages [4KB], 65536KB chunk

unused devices: <none>

Что mdadm --examine пишет в строке Events: про диски в массиве и потерявшийся?

На рабочих диски пишет 64067, а на отвалившемся 53444.

Значит он отвалился уже давно и ты с тех пор успел на них поработать.

Можешь попробовать сделать это:

mdadm --manage /dev/md125 --re-add
mdadm --manage /dev/md126 --re-add

но скорее всего он не разрешит (можно после --re-add указать диск но по идее не обязательно).

Тогда так:

mdadm --manage /dev/md125 --add /dev/отвалившийся_диск
mdadm --manage /dev/md126 --add /dev/отвалившийся_диск

Если получится --re-add то лучше после этого проверку массива запустить.

Спасибо, добрый человек! Сделал –re-add, запустил echo 'check' >/sys/block/md125/md/sync_action. Сначала на менее важном массиве, если всё пройдёт хорошо, то и на втором сделаю.

Спасибо, добрый человек! Сделал –re-add, запустил echo ‘check’ >/sys/block/md125/md/sync_action. Сначала на менее важном массиве, если всё пройдёт хорошо, то и на втором сделаю.

Смелый Вы, я бы даже сказал - отчаянный…

А что, чревато? Я думал mdadm – старая и обкатанная технология… Да и raid6 массив у меня, и избыточность есть даже без отвалившегося диска…

Напугали вы меня :) теперь копирую данные на другой массив, благо, место ещё осталось.

А что плохого то? --re-add бы не сработал если бы данные слишком отличались, а так он по-быстрому заменит устаревшие куски на новые и всё.

А что плохого то?

Может и ничего, просто я не до конца понимаю как это может работать даже в теории.

–re-add бы не сработал если бы данные слишком отличались

А откуда он знает насколько именно они отличаются? Для этого нужен как минимум лог транзакций покрывающий разницу в sequence numbers между «выпавшим» диском и теми что продолжали использоваться, хотя бы в терминах «dirty zones». И уверенность в том что «выпавший» диск никто не трогал.

а так он по-быстрому заменит устаревшие куски на новые и всё.

Вот именно в том что он правильно найдёт «устаревшие» определённые сомнения у меня и имеются. И что именно произойдёт если машинка аварийно выключится / упадёт в процессе? Полному rebuild я бы доверял куда как больше. Хотя честно скажу - я больше по железячным рейдам и с софтварными дела почти не имел.

Напугали вы меня :) теперь копирую данные на другой массив

Может и зря я Вас так настращал :) Но, смотрите на позитивную сторону - зато теперь у Вас ещё один backup’чик имеется…

Там и есть подобие лога транзакций, bitmap называется. Замедляет все записи на +1 seek time. Работает так: на каждый блок по биту-флагу, в бите указано, была ли в этот блок запись в последние сколько-то там времени (или там количество записей считается, не знаю). Если с момента вылета диска прошло меньше чем длина этого цикла - то все блоки, которые могут отличаться, помечены единицами.

Если прошло больше времени, или если если bitmap-а нет и на диск после вылета была хоть одна запись - то re-add откажется делаться вроде.

В bitmap-е могут быть (и почти точно будут) лишние единицы (в т.ч. кажется из-за ненадёжного алгоритма их сбрасывания, не представляю как можно это точно делать в учётом ребутов), но ошибочных нулей там по идее быть не должно. А единиц даже в сумме с лишними всё равно сильно меньше чем весь объём диска.

Там и есть подобие лога транзакций, bitmap называется.

С ходу не удалось найти более-менее вразумительную документацию по тому как оно на самом деле устроено (on-the-disk format and in-memory data structures, high level algo description etc). Но не могу сказать что я много усилий приложил для поиска, да и с телефона не особо удобно. Но зато часть проблем с которой ребятам пришлось столкнуться довольно очевидна. Если это действительно bitmap, пусть и с granularity много больше блока (вроде как по дефолту bitmap chunk size 64Mb) - как его грамотно чистить без глобальных hiccups? Вряд ли Вы захотите делать flush на всех дисках, ждать завершения, подчищать bitmap, и только потом продолжать запись - слишком дорого и наверняка придумали что-то гораздо лучше. Но те варианты «лучше» что я вижу привносят довольно много сложности, что в свою очередь сильно сказывается на надёжности.

К чему я это всё: если «fast-rebuild» у ТС сработал и full-check после этого прошёл - это просто замечательно, я буду за него только рад (без тени сарказма). Но сам бы я (a) вряд ли бы эти bitmaps использовал потому как они (согласно тем статьям что я нашёл в инете) сильно небесплатны в штатном режиме, (b) зная себя делал бы full-rebuild anyway.

Вряд ли Вы захотите делать flush на всех дисках, ждать завершения, подчищать bitmap, и только потом продолжать запись

Там суть в том что ложные единицы в битмапе не страшны. То есть главное лишний ноль туда не вписать, а тянуть с обнулением бита можно сколько угодно, и можно даже вообще «забыть» про него и принять имеющуюся единицу за свежую (и пытаться её снова обнулить спустя ещё один цикл жизни «только что записанного» блока). А с таким подходом никакие лишние блокировки (по крайней мере долгие) не требуются. Но вообще я тоже в деталях не знаю.

зная себя делал бы full-rebuild anyway.

Так у автора тема изначально была о том, можно ли как-то обойтись без full и восстановить диск, учитывая что он уже был в массиве.

Блин, вот читаю и поражаюсь, откуда у вас берётся столько знаяний? гуглёж, stackoverfow и superuser не покрывают и 10% всего этого. Откуда? списки рассылки? исходники? спец. литература?

Если получится –re-add то лучше после этого проверку массива запустить.

Кстати, после –re-add’а ресинхронизация включилась сама:

[==========>..........]  resync = 52.9% (1706357664/3221093376) finish=260.3min speed=96974K/sec

Видимо слишком долго диск был отключён.

Там суть в том что ложные единицы в битмапе не страшны.

Очевидно.

а тянуть с обнулением бита можно сколько угодно

Позволю себе не согласиться - за конечное время после последней записи в зону он должен таки обнулиться. Проблема в том что либо возникают глобальные барьеры и блокировки, или всё становится сильно сложнее. Грубо говоря - отсчёт новых грязных зон Вам придётся начинать с flush на одном из дисков, а подчищать Вы их сможете только на flush completion на последнем который произошёл после того как первый начался (причём потерять хоть что-то что после первого произошло - смерти подобно). А дальше мы накладываем flush’ы которые тригернулись до того как первый закончился (их может быть больше одного), глюки HDD firmware итд. Отслеживать грязные зоны - это очень непростая задача (по крайней мере если пытаться это делать эффективно). И основная мысль которую я пытаюсь донести - я (к сожалению) терял данные в довольно штатных ситуациях (выход диска из строя) на железе которое, в принципе, считается industry standard. И с тех пор - я очень консервативен, мягко говоря.

Ничего не сложнее, я ж пишу - сбрасывать можно лениво, когда получится, только убедившись что

1) последний flush с этим блоком закончился не меньше некоторого количества записей назад

2) новых записей в этот блок с тех пор не стартовало

и первое и второе - точечные события, чтоб их зафиксировать скорее всего хватит даже безблокировочного атомика, ну максимум спинлока. В памяти конечно придётся хранить не биты а таймстампы (номера записей) для каждого блока битмапа.

Ничего не сложнее, я ж пишу

Что первое, что второе - гораздо легче сказать чем сделать. И ни в одном глазу это не точечные события - они разные для каждого винта в массиве.

Так и битмапы (те, что на диск записаны) разные. На общее состояние массива смотреть не нужно.

На общее состояние массива смотреть не нужно.

Да конечно нужно: нас интересуют исключительно недавние записи на данный диск которые потенциально ещё не «виделись» другими дисками массива, и ничего более. Другой вопрос что эффективно отслеживать «latest transaction sequence number» после которого были гарантированные flush’ы на всех дисках массива не так сложно. Сильно подозреваю - они это и делают.

Мы составляем просто список последних записей, индивидуальный у каждого диска и ничего не знающий про массив. Этого полностью достаточно, чтобы пересинхронизировать блоки, который могут отличаться. Можно было хранить ещё и серийные номера этих записей (чтобы их тоже сравнивать и не синхронизировать то что одинаковое, впрочем там уже придётся учитывать flush-ы по дискам, но думаю это легко достигается принятием последнего вроде бы синхронизированного гигабайта тоже грязным), но видимо посчитали что и битов достаточно. Ведь задачи свести пересинхронизацию к минимуму не стояло, стояла задача только избежать полного переписывания всего диска.

Другой вопрос что эффективно отслеживать «latest transaction sequence number» после которого были гарантированные flush’ы на всех дисках массива не так сложно. Сильно подозреваю - они это и делают.

Думаю да, там же поле events есть. Только, повторю, flush-ы на всех дисках не важны, нужно знать про конкретный.

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

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

Как Вы в принципе bitmap’чик чистить собрались? Или Вы предалагаете их 2 держать - inactive and active, в каждом накапливать N последних транзакций и unconditionally вычищать «новый target» при переключении? На диск сбрасывать union? Да, так будет работать, но time-span of dirty bitmap будет «плавать» покрывая N..2N последних транзакций. Наверное это даже приемлемо.