RAID 5 не будет монтироваться

У меня есть qnap NAS, на котором установлена ​​версия ubuntu, и я не получаю никакой помощи от их форума, поэтому я решил задать свой вопрос здесь.

У меня было 3 HD по 2 ТБ в конфигурации raid 5. Вернувшись из отпуска, я обнаружил, что объем рейда не увеличился. Я запустил утилиту SMART со страницы администратора QNAP, и она обнаружила ошибки чтения на Disk2, поэтому я купил еще один диск объемом 2 ТБ, сделал своп, и похоже, что он решит мою проблему:

[~] # cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]
md0 : active raid5 sdd3[3] sdc3[2] sda3[0]
      3903891200 blocks level 5, 64k chunk, algorithm 2 [3/2] [U_U]
      [========>............]  recovery = 41.1% (802441984/1951945600) finish=285.7min speed=67047K/sec

Я пошел на кровать и дайте ей закончить восстановление. На следующее утро я попытался создать массив, но он не удался:

[~] # mdadm -CfR --assume-clean /dev/md0 -l 5 -n 3 /dev/sdb3 /dev/sda3 /dev/sdc3
mdadm: /dev/sdb3 appears to contain an ext2fs file system
    size=-391076224K  mtime=Thu Jan  2 03:30:10 2014
mdadm: /dev/sdb3 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Tue Jan  7 10:01:03 2014
mdadm: /dev/sda3 appears to contain an ext2fs file system
    size=-403668988K  mtime=Sat Jan 15 17:45:38 2011
mdadm: /dev/sda3 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Tue Jan  7 10:01:03 2014
mdadm: /dev/sdc3 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Tue Jan  7 10:01:03 2014
mdadm: array /dev/md0 started.

[~] # mount /dev/md0 /share/MD0_DATA -t ext4
mount: wrong fs type, bad option, bad superblock on /dev/md0,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

[~] # dmesg | tail
[ 5474.498500] EXT4-fs (md0): ext4_check_descriptors: Block bitmap for group 1952 not in group (block 224078240)!
[ 5474.504503] EXT4-fs (md0): group descriptors corrupted!

Я запустил e2fsck, и он пожаловался на суперблок:

[~] # e2fsck -f /dev/md0
e2fsck 1.41.4 (27-Jan-2009)
e2fsck: Group descriptors look bad... trying backup blocks...
e2fsck: Filesystem revision too high while trying to open /dev/md0
The filesystem revision is apparently too high for this version of e2fsck.
(Or the filesystem superblock is corrupt)


The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Я попробовал альтернативные суперблоки:

[~] # dumpe2fs /dev/md0 | grep -i superblock
dumpe2fs 1.41.4 (27-Jan-2009)
  Primary superblock at 0, Group descriptors at 1-233
  Backup superblock at 32768, Group descriptors at 32769-33001
  Backup superblock at 98304, Group descriptors at 98305-98537
  Backup superblock at 163840, Group descriptors at 163841-164073
...

Когда я попробовал 2-е значение, оно выплевывает всевозможные ошибки, вот их фрагмент:

[~] # e2fsck -b 98304 /dev/md0
e2fsck 1.41.4 (27-Jan-2009)
Superblock has an invalid journal (inode 8).
answer=1
*** ext3 journal has been deleted - filesystem is now ext2 only ***

Block bitmap for group 1920 is not in group.  (block 223029632)
answer=1
Inode bitmap for group 1920 is not in group.  (block 971776033)
answer=1
Inode table for group 1920 is not in group.  (block 63045632)
WARNING: SEVERE DATA LOSS POSSIBLE.
answer=1
Group descriptor 1920 marked uninitialized without feature set.
answer=1
Block bitmap for group 1921 is not in group.  (block 62916993)
answer=1
Inode bitmap for group 1921 is not in group.  (block 62916994)
answer=1
Group descriptor 1921 marked uninitialized without feature set.
answer=1
Block bitmap for group 1922 is not in group.  (block 1236358788)
answer=1
Group descriptor 1922 marked uninitialized without feature set.
answer=1
Inode table for group 1923 is not in group.  (block 2996300427)
WARNING: SEVERE DATA LOSS POSSIBLE.
...
Resize inode not valid.  answer=1
/dev/md0 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Root inode is not a directory.  answer=1
Inode 241 has EXTENTS_FL flag set on filesystem without extents support.
answer=1
Inode 263, i_blocks is 139224, should be 139056.  answer=1
Inode 264 has illegal block(s).  answer=1
Illegal block #2060 (2770694604) in inode 264.  answer=1
CLEARED.
Illegal block #2061 (2431456604) in inode 264.  answer=1
CLEARED.
...
Too many illegal blocks in inode 264.
answer=1
Inodes that were part of a corrupted orphan linked list found.  answer=1
Inode 8433 was part of the orphaned inode list.  answer=1
FIXED.
Inode 8433 has imagic flag set.  answer=1
Inode 8433 has a extra size (48936) which is invalid
answer=1
Inode 8434 was part of the orphaned inode list.  answer=1
FIXED.
Inode 8434 has imagic flag set.  answer=1
Inode 8434 has a extra size (49000) which is invalid
...
Inode 16369 is in use, but has dtime set.  answer=1
Inode 16369 has a extra size (35995) which is invalid
answer=1
Inode 16370 is in use, but has dtime set.  answer=1
Inode 16370 has imagic flag set.  answer=1
Inode 16370 has a extra size (26087) which is invalid
answer=1
Inode 16371 is in use, but has dtime set.  answer=1
Inode 16371 has imagic flag set.  answer=1
Inode 16371 has a extra size (1476) which is invalid
answer=1
Inode 16372 has EXTENTS_FL flag set on filesystem without extents support.
...
Inode 16380 has EXTENTS_FL flag set on filesystem without extents support.
answer=1
Inode 16381 has EXTENTS_FL flag set on filesystem without extents support.
answer=1
Inode 16382 has EXTENTS_FL flag set on filesystem without extents support.
answer=1
Inode 16383 has EXTENTS_FL flag set on filesystem without extents support.
answer=1
Inode 16384 has EXTENTS_FL flag set on filesystem without extents support.
answer=1
Inode 16375 has compression flag set on filesystem without compression support.  answer=1
Inode 16375 has a bad extended attribute block 335544554.  answer=1
Inode 16375 has INDEX_FL flag set but is not a directory.
answer=1
Inode 16375, i_size is 4795354609508463505, should be 0.  answer=1
Inode 16375, i_blocks is 119976829646520, should be 0.  answer=1
Inode 16373 has compression flag set on filesystem without compression support.  answer=1
...
Inode 49141 is in use, but has dtime set.  answer=1
Inode 49141 has a extra size (53130) which is invalid
answer=1
Inode 49142 is in use, but has dtime set.  answer=1
Inode 49142 has a extra size (15011) which is invalid
answer=1
Inode 49143 has EXTENTS_FL flag set on filesystem without extents support.
answer=1
Inode 49144 has EXTENTS_FL flag set on filesystem without extents support.
...

Я, наконец, сделал Ctrl-C, чтобы остановить его, боясь, что это происходит вызвать больше проблем. Затем он выплюнул это:

^CRecreate journalanswer=1
Creating journal (32768 blocks): 

 Done.

*** journal has been re-created - filesystem is now ext3 again ***
/dev/md0: e2fsck canceled.

/dev/md0: ***** FILE SYSTEM WAS MODIFIED *****
[~] #

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

  1. что произойдет, если вы попытаетесь смонтировать их не по порядку, например
    mdadm -CfR --assume-clean / dev / md0 -l 5 -n 3 / dev / sda3 / dev / sdb3 / dev / sdc3
    вместо
    mdadm -CfR --assume-clean / dev / md0 -l 5 - n 3 / dev / sdb3 / dev / sda3 / dev / sdc3

  2. и почему, когда я запускаю команду mdadm, это мой новый диск "sdb3", единственный, показывающий сообщение: содержит файловую систему ext2fs ? Может ли это быть частью моей проблемы?

Спасибо, Роберт

1
задан 13 January 2014 в 18:33

1 ответ

Создание массива, как и форматирование раздела, разрушительно; вы не сделаете это там, где у вас уже есть, если только вы не хотите стереть это и начать все сначала.

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

0
ответ дан 13 January 2014 в 18:33
  • 1
    Может быть предпочтительно использовать SIGINT, который подобен нажатию Ctrl+C и все еще позволяет программе закончиться в надлежащем порядке. Я использую его при завершении использования выполнений оптимизации Gurobi: Это сразу останавливает программу, но лучшее найденное решение все еще записано в файл. – CGFoX 24 January 2017 в 11:29

Другие вопросы по тегам:

Похожие вопросы: