Я запускаю Ubuntu 22.04 на машине с тремя программными RAID-массивами разного размера и геометрии, два из которых (они называются md5и md6) очень большие. Диски разделены между этими массивами по определенным причинам.
Каждый месяц cronавтоматически запускает повторную проверку программных RAID-массивов. Из-за общих дисков только одна из трех проверок RAID может быть запущена в определенное время, остальные автоматически приостанавливаются. Более того, повторная проверка выполняется только в течение шести часов каждый день, хотя я не знаю, как определяется начало этого шестичасового временного окна.
Файловая система, смонтированная из md6зависла, когда повторная проверка была прервана md6на второй день. Все процессы и потоки с чтением и записью в эту файловую систему застряли в "непрерываемом сне". Принудительное размонтирование или принудительная разборка массива также невозможны, поэтому мне пришлось перезагрузиться, чтобы снова получить доступ к своим данным. За исключением эффективного DOS, никакие данные, похоже, не были потеряны.
Из журнала я вижу, что происходит следующее: в первый день проверка всех трех массивов начинается одновременно. Наименьший массив, md1, выигрывает гонку за то, кто будет проверен первым, в то время как md5и md6должны ждать. md1завершается менее чем за десять минут и затем md6продолжается до конца первого дня.
На второй день md5(не уже начавшийся md6!) выигрывает гонку за то, кого проверят. Через шесть часов проверка md5прерывается на день. md6, который, по-видимому, получил команду «бежать» на несколько миллисекунд позже, начинает бежать, только чтобы получить 6-часовую остановку все еще в ту же секунду, в которую он начал.
После этого супербыстрого старта-остановки проверки на md6, md6зависает. Первым признаком этого в журнале является предупреждение о том, что попытка записи в журнал файловой системы заблокирована более двух минут:
Вот соответствующие части журнала («М» — название машины):
Sep 4 08:23:59 M root: mdcheck start checking /dev/md1
Sep 4 08:23:59 M kernel: [1682166.084604] md: data-check of RAID array md1
Sep 4 08:24:00 M root: mdcheck start checking /dev/md5
Sep 4 08:24:00 M kernel: [1682167.725977] md: delaying data-check of md5 until md1 has finished (they share one or more physical units)
Sep 4 08:24:00 M root: mdcheck start checking /dev/md6
Sep 4 08:24:00 M kernel: [1682167.758063] md: delaying data-check of md6 until md5 has finished (they share one or more physical units)
Sep 4 08:33:23 M kernel: [1682730.686726] md: md1: data-check done.
Sep 4 08:33:23 M kernel: [1682730.697864] md: data-check of RAID array md6
Sep 4 08:33:23 M kernel: [1682730.697864] md: delaying data-check of md5 until md6 has finished (they share one or more physical units)
Sep 4 08:34:01 M root: mdcheck finished checking /dev/md1
Sep 4 14:24:02 M root: pause checking /dev/md5 at 0
Sep 4 14:24:03 M kernel: [1703770.476375] md: md6: data-check interrupted.
Sep 4 14:24:03 M root: pause checking /dev/md6 at 5702160936
Sep 4 14:24:03 M systemd[1]: mdcheck_start.service: Deactivated successfully.
Sep 4 14:24:03 M systemd[1]: mdcheck_start.service: Consumed 1.957s CPU time.
Sep 4 20:03:05 M systemd[1]: mdmonitor-oneshot.service: Deactivated successfully.
Sep 5 07:02:14 M root: mdcheck continue checking /dev/md5 from 0
Sep 5 07:02:14 M kernel: [1763663.944043] md: data-check of RAID array md5
Sep 5 07:02:14 M root: mdcheck continue checking /dev/md6 from 5702160936
Sep 5 07:02:14 M kernel: [1763663.980271] md: delaying data-check of md6 until md5 has finished (they share one or more physical units)
Sep 5 13:02:26 M kernel: [1785276.510597] md: md5: data-check interrupted.
Sep 5 13:02:27 M kernel: [1785276.786479] md: data-check of RAID array md6
Sep 5 13:02:27 M root: pause checking /dev/md5 at 5824508144
Sep 5 13:02:27 M kernel: [1785276.795438] md: md6: data-check interrupted.
Sep 5 13:05:31 M kernel: [1785461.181277] INFO: task jbd2/md6-8:2495 blocked for more than 120 seconds.
Sep 5 13:05:31 M kernel: [1785461.181441] task:jbd2/md6-8 state:D stack: 0 pid: 2495 ppid: 2 flags:0x00004000
Sep 5 13:05:31 M kernel: [1785461.181742] md_write_start.part.0+0x174/0x220
Sep 5 13:05:31 M kernel: [1785461.181753] md_write_start+0x14/0x30
Sep 5 13:05:31 M kernel: [1785461.181781] md_handle_request+0x12d/0x1b0
Sep 5 13:05:31 M kernel: [1785461.181792] md_submit_bio+0x71/0xc0
Sep 5 14:44:14 M systemd[1]: mdmonitor-oneshot.service: Deactivated successfully.
Поскольку /файловые /homeсистемы находятся на незатронутых RAID-массивах, я все равно смог войти в систему после этой заморозки md6. cat /proc/mdstatвыдал следующую информацию:
Personalities : [raid1] [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid10]
md5 : active raid5 sdd4[1] sdk4[2] sdh4[0] sdl4[4]
11415389184 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
bitmap: 0/29 pages [0KB], 65536KB chunk
md1 : active raid1 sdd3[0] sdk3[1] sdh3[3] sdl3[2]
100596736 blocks super 1.2 [4/4] [UUUU]
md6 : active raid6 sdd2[10] sdk2[9] sdh2[11] sdl2[8] sdg[5] sdf[4] sdb[1] sdc[2] sdi[6] sde[3] sdj[7] sda[0]
117186867200 blocks super 1.2 level 6, 512k chunk, algorithm 2 [12/12] [UUUUUUUUUUUU]
[====>................] check = 24.3% (2851080676/11718686720) finish=95845361544.0min speed=0K/sec
bitmap: 0/88 pages [0KB], 65536KB chunk
Обратите внимание, что это, /proc/mdstatпохоже, возвращает позицию повторной проверки в блоках по 1 кБ с 2851080676, равными 5702161352 секторам, что всего на 416 секторов (меньше одного куска!) дальше от 5702160936, вошедших в систему, syslogпоскольку позиция была достигнута днем ранее. Поэтому я предполагаю тупик в начатой и затем немедленно остановленной повторной проверке.
До сих пор моим решением было отключить автоматическую повторную проверку MD RAID.
решение1
Возможно, вы столкнулись с этой ошибкой:https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.11/+bug/1942935. Это ошибка ядра в основной ветке разработки, исправления которой появятся в Linux v5.19.
Откомментарий 10, вы можете попробовать этот обходной путь (сначала переключитесь md1на md5/ md6/etc.):
echo active | sudo tee /sys/block/md1/md/array_state