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