6

Моя проблема произошла, когда я попытался установить Windows 7 на свой собственный SSD. Используемая мной операционная система Linux, обладающая знаниями о программной системе RAID, находится на SSD, который я отключил перед установкой. Это было так, чтобы окна (или я) не могли случайно испортить это.

Однако, оглядываясь назад, я по глупости оставил подключенные диски RAID, думая, что окна не будут настолько нелепыми, чтобы портить жесткий диск, который он считает просто нераспределенным пространством.

Мальчик был я не прав! После копирования установочных файлов на твердотельный накопитель (как и ожидалось), он также создал раздел ntfs на одном из дисков RAID. И неожиданно, и совершенно нежелательно! снимок экрана с разделом ntfs на диске raid ,

Я снова сменил SSD и загрузился в Linux. mdadm , похоже, не было проблем с сборкой массива, как раньше, но если я попытался смонтировать массив, я получил сообщение об ошибке:

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

dmesg:

EXT4-fs (md0): ext4_check_descriptors: Block bitmap for group 0 not in group (block 1318081259)!
EXT4-fs (md0): group descriptors corrupted!

Затем я использовал qparted чтобы удалить только что созданный раздел ntfs в /dev/sdd чтобы он соответствовал другим трем /dev/sd{b,c,e} , и запросил повторную синхронизацию моего массива с помощью echo repair > /sys/block/md0/md/sync_action

Это заняло около 4 часов, и после завершения dmesg сообщает:

md: md0: requested-resync done.

Немного коротко после 4-часовой задачи, хотя я не уверен относительно того, где существуют другие файлы журналов (я также, кажется, испортил мою конфигурацию sendmail). В любом случае: никаких изменений не сообщается в соответствии с mdadm , все проверяется. mdadm -D /dev/md0 прежнему сообщает:

        Version : 1.2
  Creation Time : Wed May 23 22:18:45 2012
     Raid Level : raid6
     Array Size : 3907026848 (3726.03 GiB 4000.80 GB)
  Used Dev Size : 1953513424 (1863.02 GiB 2000.40 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Mon May 26 12:41:58 2014
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 4K

           Name : okamilinkun:0
           UUID : 0c97ebf3:098864d8:126f44e3:e4337102
         Events : 423

    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      active sync   /dev/sdc
       2       8       48        2      active sync   /dev/sdd
       3       8       64        3      active sync   /dev/sde

Попытка смонтировать его все еще сообщает:

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

и dmesg:

EXT4-fs (md0): ext4_check_descriptors: Block bitmap for group 0 not in group (block 1318081259)!
EXT4-fs (md0): group descriptors corrupted!

Я немного не уверен, куда идти дальше, и пытаться «посмотреть, сработает» ли это, слишком рискованно для меня. Вот что я предлагаю сделать:

Скажите mdadm что /dev/sdd (тот, в который Windows записала) больше не является надежным, представьте, что он заново введен в массив, и восстановите его содержимое на основе трех других дисков.

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


Мой вопрос: Помогите, что мне делать?Если я должен сделать то, что я предложил, как мне это сделать? Прочитав документацию и т.д., Я бы подумал:

mdadm --manage /dev/md0 --set-faulty /dev/sdd
mdadm --manage /dev/md0 --remove /dev/sdd
mdadm --manage /dev/md0 --re-add /dev/sdd

Тем не менее, примеры документации предлагают /dev/sdd1 , что мне кажется странным, так как там нет раздела с точки зрения linux, только нераспределенное пространство. Может быть, эти команды не будут работать без.

Возможно, имеет смысл отразить таблицу разделов одного из других raid-устройств, которые не были затронуты до - --re-add . Что-то вроде:

sfdisk -d /dev/sdb | sfdisk /dev/sdd

Дополнительный вопрос: почему установка Windows 7 делает что-то настолько ... потенциально опасным?


Обновить

Я пошел дальше и отметил /dev/sdd как неисправный и удалил его (не физически) из массива:

# mdadm --manage /dev/md0 --set-faulty /dev/sdd
# mdadm --manage /dev/md0 --remove /dev/sdd

Однако попытка --re-add была запрещена:

# mdadm --manage /dev/md0 --re-add /dev/sdd
mdadm: --re-add for /dev/sdd to /dev/md0 is not possible

--add , было хорошо.

# mdadm --manage /dev/md0 --add /dev/sdd

mdadm -D /dev/md0 теперь сообщает о состоянии как clean, degraded, recovering и /dev/sdd как spare rebuilding .

/proc/mdstat показывает ход восстановления:

md0 : active raid6 sdd[4] sdc[1] sde[3] sdb[0]
      3907026848 blocks super 1.2 level 6, 4k chunk, algorithm 2 [4/3] [UU_U]
      [>....................]  recovery =  2.1% (42887780/1953513424) finish=348.7min speed=91297K/sec

nmon также показывает ожидаемый результат:

│sdb        0%   87.3    0.0|  >                                              |│
│sdc       71%  109.1    0.0|RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR           > |│
│sdd       40%    0.0   87.3|WWWWWWWWWWWWWWWWWWWW           >                 |│
│sde        0%   87.3    0.0|>                                                ||

Пока все выглядит хорошо. Скрестим пальцы еще на пять с лишним часов :)


Обновление 2

Восстановление /dev/sdd завершено, с выводом dmesg :

[44972.599552] md: md0: recovery done.
[44972.682811] RAID conf printout:
[44972.682815]  --- level:6 rd:4 wd:4
[44972.682817]  disk 0, o:1, dev:sdb
[44972.682819]  disk 1, o:1, dev:sdc
[44972.682820]  disk 2, o:1, dev:sdd
[44972.682821]  disk 3, o:1, dev:sde

Попытка mount /dev/md0 сообщает:

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

И на dmesg:

[44984.159908] EXT4-fs (md0): ext4_check_descriptors: Block bitmap for group 0 not in group (block 1318081259)!
[44984.159912] EXT4-fs (md0): group descriptors corrupted!

Я не уверен, что делать сейчас. Предложения?


Вывод dumpe2fs /dev/md0:

dumpe2fs 1.42.8 (20-Jun-2013)
Filesystem volume name:   Atlas
Last mounted on:          /mnt/atlas
Filesystem UUID:          e7bfb6a4-c907-4aa0-9b55-9528817bfd70
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              244195328
Block count:              976756712
Reserved block count:     48837835
Free blocks:              92000180
Free inodes:              243414877
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      791
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
RAID stripe width:        2
Flex block group size:    16
Filesystem created:       Thu May 24 07:22:41 2012
Last mount time:          Sun May 25 23:44:38 2014
Last write time:          Sun May 25 23:46:42 2014
Mount count:              341
Maximum mount count:      -1
Last checked:             Thu May 24 07:22:41 2012
Check interval:           0 (<none>)
Lifetime writes:          4357 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      e177a374-0b90-4eaa-b78f-d734aae13051
Journal backup:           inode blocks
dumpe2fs: Corrupt extent header while reading journal super block

1 ответ1

0

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

Рейд программного обеспечения Linux предполагает, что массив исправен (чист), если только контроллер чтения диска не сообщит об ошибке чтения или записи, как описано в вики Linux raid. Драйвер предполагает, что, поскольку на диске хранится много избыточных данных, а связь между жестким диском и контроллером также использует обнаружение ошибок.

Таким образом, в вашей ситуации (в режиме RAID6) блоки четности даже не читаются.

RAID6

Перезапись одного из ваших дисков была (с точки зрения диска) совершенно корректным запросом и была выполнена вашим диском без ошибок.

Теперь, когда вы запрашиваете перестройку массива с использованием диска с поврежденными данными, вы просто распространяете поврежденные данные по всему массиву.

Правильно было подумать о том, чтобы установить неисправный диск, а затем добавить его обратно в массив. Массив был бы перестроен в безопасном состоянии.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .