Meu problema aconteceu quando tentei instalar o Windows 7 em seu próprio SSD. O sistema operacional Linux que usei, que tem conhecimento do sistema RAID de software, está em um SSD que eu desconectei antes da instalação. Isso foi feito para que as janelas (ou eu) não o estragassem inadvertidamente.
No entanto, e em retrospectiva, tolamente, deixei os discos RAID conectados, pensando que as janelas não seriam tão ridículas a ponto de mexer em um disco rígido que ele vê como apenas espaço não alocado.
Garoto eu estava errado! Depois de copiar os arquivos de instalação para o SSD (conforme esperado e desejado), ele também criou uma partição ntfs
em um dos discos RAID. Ambos inesperados e totalmente indesejáveis! .
EumudeioSSD
snovamente,einicializeinolinux.mdadm
nãopareceternenhumproblemaemmontaroarraycomoantes,masseeutenteimontaroarray,recebiamensagemdeerro:
mount:wrongfstype,badoption,badsuperblockon/dev/md0,missingcodepageorhelperprogram,orothererrorInsomecasesusefulinfoisfoundinsyslog-trydmesg|tailorso
dmesg
:
EXT4-fs(md0):ext4_check_descriptors:Blockbitmapforgroup0notingroup(block1318081259)!EXT4-fs(md0):groupdescriptorscorrupted!
Emseguida,useiqparted
paraexcluirapartiçãontfs
recém-criadaem/dev/sdd
paraquecorrespondesseaosoutrostrês/dev/sd{b,c,e}
esoliciteiumanovasincronizaçãodeminhamatrizcomechorepair>/sys/block/md0/md/sync_action
Issolevoucercadequatrohorase,apósaconclusão,dmesg
relatórios:
md:md0:requested-resyncdone.
Umpoucobrevedepoisdeumatarefade4horas,emboraeunãotenhacertezadeondeexistemoutrosarquivosdelog(parecequeeutambémestragueiaconfiguraçãodomeusendmail).Emqualquercaso:Nenhumamudançarelatadadeacordocommdadm
,tudoéverificado.mdadm-D/dev/md0
aindarelata:
Version:1.2CreationTime:WedMay2322:18:452012RaidLevel:raid6ArraySize:3907026848(3726.03GiB4000.80GB)UsedDevSize:1953513424(1863.02GiB2000.40GB)RaidDevices:4TotalDevices:4Persistence:SuperblockispersistentUpdateTime:MonMay2612:41:582014State:cleanActiveDevices:4WorkingDevices:4FailedDevices:0SpareDevices:0Layout:left-symmetricChunkSize:4KName:okamilinkun:0UUID:0c97ebf3:098864d8:126f44e3:e4337102Events:423NumberMajorMinorRaidDeviceState08160activesync/dev/sdb18321activesync/dev/sdc28482activesync/dev/sdd38643activesync/dev/sde
Tentandomontá-loaindarelata:
mount:wrongfstype,badoption,badsuperblockon/dev/md0,missingcodepageorhelperprogram,orothererrorInsomecasesusefulinfoisfoundinsyslog-trydmesg|tailorso
edmesg
:
EXT4-fs(md0):ext4_check_descriptors:Blockbitmapforgroup0notingroup(block1318081259)!EXT4-fs(md0):groupdescriptorscorrupted!
Nãoseibemporondecontinuar,etentarcoisas"para ver se funciona" é um pouco arriscado demais para mim. Isto é o que eu sugiro que eu tente fazer:
Diga a mdadm
que /dev/sdd
(aquele em que o Windows escreveu) não é mais confiável, finja que ele foi reintroduzido novamente na matriz e reconstrua seu conteúdo com base nas outras três unidades.
Eu também poderia estar totalmente errado em minhas suposições, que a criação da partição ntfs
em /dev/sdd
e a exclusão subseqüente mudou algo que não pode ser corrigido dessa maneira.
Minha pergunta: Ajuda, o que devo fazer? Se eu deveria fazer o que eu sugeri, como faço isso? De ler documentação, etc, eu acho que talvez:
mdadm --manage /dev/md0 --set-faulty /dev/sdd
mdadm --manage /dev/md0 --remove /dev/sdd
mdadm --manage /dev/md0 --re-add /dev/sdd
No entanto, os exemplos de documentação sugerem /dev/sdd1
, o que parece estranho para mim, pois não há nenhuma partição lá no que diz respeito ao Linux, apenas espaço não alocado. Talvez esses comandos não funcionem sem.
Talvez faça sentido espelhar a tabela de partições de um dos outros dispositivos de ataque que não foram tocados, antes de --re-add
. Algo como:
sfdisk -d /dev/sdb | sfdisk /dev/sdd
Pergunta bônus: Por que a instalação do Windows 7 faria algo tão perigoso ... potencialmente perigoso?
Atualizar
Segui em frente e marquei /dev/sdd
como defeituoso e removi-o (não fisicamente) da matriz:
# mdadm --manage /dev/md0 --set-faulty /dev/sdd
# mdadm --manage /dev/md0 --remove /dev/sdd
No entanto, a tentativa de --re-add não foi permitida:
# mdadm --manage /dev/md0 --re-add /dev/sdd
mdadm: --re-add for /dev/sdd to /dev/md0 is not possible
--add
, estava bem.
# mdadm --manage /dev/md0 --add /dev/sdd
mdadm -D /dev/md0
agora relata o estado como clean, degraded, recovering
e /dev/sdd
como spare rebuilding
.
/proc/mdstat
mostra o progresso da recuperação:
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
também mostra a saída esperada:
│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|> ||
Parece bom até agora. Cruzando meus dedos por mais cinco horas +):
Atualização 2
A recuperação de /dev/sdd
terminou, com dmesg
output:
[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
Tentativa de mount /dev/md0
relatórios:
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
E em 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!
Não sei o que fazer agora. Sugestões?
Saída de 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