Intereting Posts
Переустановите grub на другой диск? Как распечатать (часть) справочную страницу? Использование ключевого файла в качестве пароля с OpenSSL Что делать после создания LUNS как узнать ip ssh HostName Как сделать конференц-связь Skype и совместное использование экрана в Linux Настройка Powerline в vim grep трубопроводы в sed, заменяя inline; но я хочу, чтобы sed печатал имя файла и менял строку. Является ли это возможным? Копирование файлов из командной строки в буфер обмена Как создать список и подсчитать ключевые слова LaTeX в исходном файле? Как сделать ручку изменения часового пояса Ubuntu? получить часть строки и добавить к этой же строке Почему Linux utils не использует системный вызов для получения текущего времени? «Завершение работы выполняется для LVM PV …» при завершении работы Есть ли способ синхронизировать уведомления между рабочим столом Linux и iOS?

mdadm RAID – перезагрузка во время Grow (Shrink) переформатируется – не работает (застревает)

У меня есть линейка Raid6 для Linux (mdadm). Я выращивал его с 6x4TB дисков (16 ТБ для использования) до 7x4TB (20 ТБ для использования). Изменение было прекрасным, но когда я сделал resize2fs, я получил довольно хорошо известную проблему ограничения файловой системы EXT4 16TB. Я проверил и файловая система НЕ имеет флаг 64 бит. Поэтому, чтобы восстановить дополнительный диск, который я только что добавил в массив, я сделал следующее:

johnny@debian:~$ sudo resize2fs /dev/md0 16000G johnny@debian:~$ sudo mdadm --grow /dev/md0 --array-size=16000G johnny@debian:~$ sudo mdadm --grow /dev/md0 --raid-devices=6 --backup-file=/tmp/backup 

Обратите внимание на расположение файла резервной копии. Это будет важно через минуту, потому что я на Debian.

Так что все шло хорошо, медленно, но работало. Прогресс достиг 3,7%, и он замедлился до ползания. Я предполагал, что это произошло потому, что в это же время я перестраивал несколько других массивов. Когда эти другие задания закончились, и этот не ускорился, я действительно волновался. Поскольку он сказал, что потребуется несколько лет, я решил, что должен перезапустить и посмотреть, будет ли это ускоряться, поэтому я перезапустил систему.

Это когда начинаются плохие вещи …

Я нахожусь в Debian, и я понимаю, что папка / tmp уничтожается, когда система появляется, поэтому мой резервный файл с изменением формы был потерян. Кроме того, поскольку файл / etc / fstab пытался монтировать md0, который не собирался сейчас, система не смогла подняться несколько раз. Я начал с live cd и исправил файл fstab и получил систему для резервного копирования.

После того, как я разобрал это, система поднялась, и я впервые увидел, что md0 не просто собрался и продолжал перестраиваться. Паника установлена ​​в …

У меня нет вывода следующих команд, но мне удалось найти команды, которые я набрал. Краткое объяснение того, что произошло после …

 johnny@debian:~$ sudo mdadm --assemble /dev/md0 johnny@debian:~$ sudo mdadm --assemble --force /dev/md0 johnny@debian:~$ sudo mdadm --assemble --force /dev/md0 --backup-file=/tmp/backup 

Первая команда не удалась, поэтому я попробовал параметр -force, который также потерпел неудачу, но сообщение об ошибке показало мне, что сбой был вызван тем, что ему нужна опция -backup-file, поэтому я выполнил третью команду. Я ожидал, что файл резервной копии все еще существует, но это произошло не потому, что он был в папке / tmp и был удален. Это, похоже, не вызывало никаких проблем, потому что массив собран.

Вот как выглядит md0 сейчас. Обратите внимание на диск, помеченный как «удаленный». Я подозреваю, что это диск, который был удален, sdj1.

 johnny@debian:~$ sudo mdadm --detail /dev/md0 /dev/md0: Version : 1.2 Creation Time : Fri Jan 11 09:59:42 2013 Raid Level : raid6 Array Size : 15627548672 (14903.59 GiB 16002.61 GB) Used Dev Size : 3906887168 (3725.90 GiB 4000.65 GB) Raid Devices : 6 Total Devices : 6 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Sat Mar 5 20:45:56 2016 State : clean, degraded, reshaping Active Devices : 6 Working Devices : 6 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 512K Reshape Status : 3% complete Delta Devices : -1, (7->6) Name : BigRaid6 UUID : 45747bdc:ba5a85fe:ead35e14:24c2c7b2 Events : 4339739 Number Major Minor RaidDevice State 11 8 224 0 active sync /dev/sdo 2 0 0 2 removed 6 8 80 2 active sync /dev/sdf 7 8 176 3 active sync /dev/sdl 12 8 16 4 active sync /dev/sdb 8 8 32 5 active sync /dev/sdc 9 8 128 6 active sync /dev/sdi 

И вот текущий ход изменения. Обратите внимание, что он полностью застрял в 0K / sec.

 johnny@debian:~$ cat /proc/mdstat Personalities : [raid1] [raid6] [raid5] [raid4] md0 : active raid6 sdo[11] sdi[9] sdc[8] sdb[12] sdl[7] sdf[6] 15627548672 blocks super 1.2 level 6, 512k chunk, algorithm 2 [6/5] [U_UUUU] [>....................] reshape = 3.7% (145572864/3906887168) finish=284022328345.0min speed=0K/sec bitmap: 5/30 pages [20KB], 65536KB chunk unused devices: <none> 

Вот отдельные диски, все еще находящиеся в массиве.

 johnny@debian:~$ sudo mdadm --examine /dev/sd[oflbci] /dev/sdb: Magic : a92b4efc Version : 1.2 Feature Map : 0x5 Array UUID : 45747bdc:ba5a85fe:ead35e14:24c2c7b2 Name : BigRaid6 Creation Time : Fri Jan 11 09:59:42 2013 Raid Level : raid6 Raid Devices : 6 Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB) Array Size : 15627548672 (14903.59 GiB 16002.61 GB) Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB) Data Offset : 262144 sectors Super Offset : 8 sectors Unused Space : before=262064 sectors, after=688 sectors State : clean Device UUID : 99b0fbcc:46d619bb:9ae96eaf:840e21a4 Internal Bitmap : 8 sectors from superblock Reshape pos'n : 15045257216 (14348.28 GiB 15406.34 GB) Delta Devices : -1 (7->6) Update Time : Sat Mar 5 20:45:56 2016 Checksum : fca445bd - correct Events : 4339739 Layout : left-symmetric Chunk Size : 512K Device Role : Active device 4 Array State : A.AAAAA ('A' == active, '.' == missing, 'R' == replacing) /dev/sdc: Magic : a92b4efc Version : 1.2 Feature Map : 0x5 Array UUID : 45747bdc:ba5a85fe:ead35e14:24c2c7b2 Name : BigRaid6 Creation Time : Fri Jan 11 09:59:42 2013 Raid Level : raid6 Raid Devices : 6 Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB) Array Size : 15627548672 (14903.59 GiB 16002.61 GB) Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB) Data Offset : 262144 sectors Super Offset : 8 sectors Unused Space : before=262064 sectors, after=688 sectors State : clean Device UUID : b8d49170:06614f82:ad9a38a4:e9e06da5 Internal Bitmap : 8 sectors from superblock Reshape pos'n : 15045257216 (14348.28 GiB 15406.34 GB) Delta Devices : -1 (7->6) Update Time : Sat Mar 5 20:45:56 2016 Checksum : 5d867810 - correct Events : 4339739 Layout : left-symmetric Chunk Size : 512K Device Role : Active device 5 Array State : A.AAAAA ('A' == active, '.' == missing, 'R' == replacing) /dev/sdf: Magic : a92b4efc Version : 1.2 Feature Map : 0x5 Array UUID : 45747bdc:ba5a85fe:ead35e14:24c2c7b2 Name : BigRaid6 Creation Time : Fri Jan 11 09:59:42 2013 Raid Level : raid6 Raid Devices : 6 Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB) Array Size : 15627548672 (14903.59 GiB 16002.61 GB) Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB) Data Offset : 262144 sectors Super Offset : 8 sectors Unused Space : before=262064 sectors, after=688 sectors State : clean Device UUID : dd56062c:4b55bf16:6a468024:3ca6bfd0 Internal Bitmap : 8 sectors from superblock Reshape pos'n : 15045257216 (14348.28 GiB 15406.34 GB) Delta Devices : -1 (7->6) Update Time : Sat Mar 5 20:45:56 2016 Checksum : 59045f87 - correct Events : 4339739 Layout : left-symmetric Chunk Size : 512K Device Role : Active device 2 Array State : A.AAAAA ('A' == active, '.' == missing, 'R' == replacing) /dev/sdi: Magic : a92b4efc Version : 1.2 Feature Map : 0x5 Array UUID : 45747bdc:ba5a85fe:ead35e14:24c2c7b2 Name : BigRaid6 Creation Time : Fri Jan 11 09:59:42 2013 Raid Level : raid6 Raid Devices : 6 Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB) Array Size : 15627548672 (14903.59 GiB 16002.61 GB) Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB) Data Offset : 262144 sectors Super Offset : 8 sectors Unused Space : before=262064 sectors, after=688 sectors State : clean Device UUID : 92831abe:86de117c:710c368e:8badcef3 Internal Bitmap : 8 sectors from superblock Reshape pos'n : 15045257216 (14348.28 GiB 15406.34 GB) Delta Devices : -1 (7->6) Update Time : Sat Mar 5 20:45:56 2016 Checksum : dd2fe2d1 - correct Events : 4339739 Layout : left-symmetric Chunk Size : 512K Device Role : Active device 6 Array State : A.AAAAA ('A' == active, '.' == missing, 'R' == replacing) /dev/sdl: Magic : a92b4efc Version : 1.2 Feature Map : 0x5 Array UUID : 45747bdc:ba5a85fe:ead35e14:24c2c7b2 Name : BigRaid6 Creation Time : Fri Jan 11 09:59:42 2013 Raid Level : raid6 Raid Devices : 6 Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB) Array Size : 15627548672 (14903.59 GiB 16002.61 GB) Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB) Data Offset : 262144 sectors Super Offset : 8 sectors Unused Space : before=262064 sectors, after=688 sectors State : clean Device UUID : 8404647a:b1922fed:acf71f64:18dfd448 Internal Bitmap : 8 sectors from superblock Reshape pos'n : 15045257216 (14348.28 GiB 15406.34 GB) Delta Devices : -1 (7->6) Update Time : Sat Mar 5 20:45:56 2016 Checksum : 358734b4 - correct Events : 4339739 Layout : left-symmetric Chunk Size : 512K Device Role : Active device 3 Array State : A.AAAAA ('A' == active, '.' == missing, 'R' == replacing) /dev/sdo: Magic : a92b4efc Version : 1.2 Feature Map : 0x5 Array UUID : 45747bdc:ba5a85fe:ead35e14:24c2c7b2 Name : BigRaid6 Creation Time : Fri Jan 11 09:59:42 2013 Raid Level : raid6 Raid Devices : 6 Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB) Array Size : 15627548672 (14903.59 GiB 16002.61 GB) Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB) Data Offset : 262144 sectors Super Offset : 8 sectors Unused Space : before=262064 sectors, after=688 sectors State : clean Device UUID : d7e84765:86fb751a:466ab0de:c26afc43 Internal Bitmap : 8 sectors from superblock Reshape pos'n : 15045257216 (14348.28 GiB 15406.34 GB) Delta Devices : -1 (7->6) Update Time : Sat Mar 5 20:45:56 2016 Checksum : c3698023 - correct Events : 4339739 Layout : left-symmetric Chunk Size : 512K Device Role : Active device 0 Array State : A.AAAAA ('A' == active, '.' == missing, 'R' == replacing 

Здесь / dev / sdj1, который раньше был единственным членом массива, который не был членом «всего диска». Это был тот, который был удален из массива во время изменения. Я подозреваю, что он по-прежнему необходим для завершения изменения, хотя в настоящее время он не является членом массива, потому что он имеет данные на нем до изменения.

 johnny@debian:~$ sudo mdadm --examine /dev/sdj1 mdadm: No md superblock detected on /dev/sdj1. 

Итак, вот мои проблемы …
1. Я не могу закончить форматирование.
2. Я не могу установить массив. Когда я пытаюсь, я получаю это.

 johnny@debian:~$ sudo mount /dev/md0 /media/BigRaid6 mount: wrong fs type, bad option, bad superblock on /dev/md0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. johnny@debian:~$ sudo dmesg | tail [42446.268089] sd 15:0:0:0: [sdk] [42446.268091] Add. Sense: Unrecovered read error - auto reallocate failed [42446.268092] sd 15:0:0:0: [sdk] CDB: [42446.268093] Read(10): 28 00 89 10 bb 00 00 04 00 00 [42446.268099] end_request: I/O error, dev sdk, sector 2299575040 [42446.268131] ata16: EH complete [61123.788170] md: md1: data-check done. [77423.597923] EXT4-fs (md0): bad geometry: block count 4194304000 exceeds size of device (3906887168 blocks) [77839.250590] EXT4-fs (md0): bad geometry: block count 4194304000 exceeds size of device (3906887168 blocks) [78525.085343] EXT4-fs (md0): bad geometry: block count 4194304000 exceeds size of device (3906887168 blocks) 

Я уверен, что установка будет успешной, если бы изменение было закончено, так что, вероятно, это самое важное. Просто FYI, данные в этом массиве слишком велики для резервного копирования, поэтому, если я его потеряю, данные исчезнут. Пожалуйста помоги!

ИЗМЕНИТЬ 1:

Я мог бы выложить $ 1000 (или больше) и получить достаточно дисков для копирования всего, но мне нужно было бы смонтировать массив для этого.

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

 [146181.331566] EXT4-fs (md0): bad geometry: block count 4194304000 exceeds size of device (3906887168 blocks) 

Размер устройства, 3906887168, составляет ровно 1/4 от размера массива md0, 15627548672. Из «mdadm -detail / dev / md0»

 Array Size : 15627548672 (14903.59 GiB 16002.61 GB) 

Я не знаю, откуда приходит номер 4194304000 … но разве это не означает, что массив имеет правильный размер, чтобы вписаться в эти диски? Или эти размеры не учитывают метаданные mdadm? Возможно ли 4194304000, включая метаданные?

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

Ваша ошибка уже в первой команде, 16000GiB просто не то, что у вас на дисках 6x4TB, даже 16000GB может быть растянуто, так как вы теряете некоторое пространство для метаданных mdadm и т. Д. Последнее сообщение об ошибке очень напоминает эту ситуацию ( bad geometry , файловая система полагает, что она больше того, что предлагает устройство, и файловые системы абсолютно ненавидят это).

Итак, вы смотрите на множество проблем прямо сейчас:

  • ваша файловая система слишком большая
  • ваша усадка застряла на полпути
  • по крайней мере один из ваших дисков не удалось ( /dev/sdk )
  • ваш файл резервной копии был потерян
  • возможные несоответствия файловой системы (очевидно)

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

В этой ситуации я бы

  • остановите RAID и убедитесь, что ничто другое не запускает его (отключить udev правила автоматической сборки и такие вещи)
  • сделать жесткие диски доступными только для чтения с использованием файла наложения (требуется дополнительный запасной диск для временного хранения)
  • попытку воссоздать RAID с помощью указанных наложений

Повторное создание RAID – это действительно очень плохая идея в целом, поскольку она почти всегда идет не так. Однако я думаю, что в вашем случае это может привести к меньшему ущербу, чем попытка отменить процесс усадки любым другим способом. В 7-дисковый RAID 6 область 16GiB все еще может быть не затронута … если файловая система была бездействующей, а RAID уменьшалась. В противном случае вы смотрите на еще больше несогласованности файловой системы.

При повторном создании RAID вы должны получить все переменные вправо: версия метаданных, смещение данных, уровень рейда, макет рейда, размер блока, порядок дисков, … и вам нужно предотвратить повторные синхронизации, оставив диски избыточности отсутствующими.

Это может быть как таковое:

 mdadm --create /dev/md0 --assume-clean \ --metadata=1.2 --data-offset=128M --level=6 --layout=ls --chunk=512 \ --raid-devices=7 missing missing /dev/mapper/overlay-{sdf,sdl,sdb,sdc,sdi} 

Никакой гарантии, я, очевидно, не пробовал это сам.


После того как вы подтвердите, что он работает, вы можете зафиксировать изменения на диске (примените шаги, которые проверены для работы без наложения). Затем на этот раз resize2fs файловая система правильно ( 14G должна работать), затем сжимайте RAID и надейтесь, что он не застрянет снова. Файл резервной копии может не понадобиться для mdadm --grow , если вы используете один, убедитесь, что он не потерял его.