mdadm: O Win7-install criou uma partição de inicialização em uma das minhas unidades RAID6. Como reconstruir?

6

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!     .

EumudeioSSDsnovamente,einicializeinolinux.mdadmnã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,useiqpartedparaexcluirapartiçãontfsrecém-criadaem/dev/sddparaquecorrespondesseaosoutrostrês/dev/sd{b,c,e}esoliciteiumanovasincronizaçãodeminhamatrizcomechorepair>/sys/block/md0/md/sync_action

Issolevoucercadequatrohorase,apósaconclusão,dmesgrelatórios:

md:md0:requested-resyncdone.

Umpoucobrevedepoisdeumatarefade4horas,emboraeunãotenhacertezadeondeexistemoutrosarquivosdelog(parecequeeutambémestragueiaconfiguraçãodomeusendmail).Emqualquercaso:Nenhumamudançarelatadadeacordocommdadm,tudoéverificado.mdadm-D/dev/md0aindarelata:

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
    
por swalog 26.05.2014 / 12:55

1 resposta

0

Estou um pouco surpreso que mdadm tenha montado o array usando esse disco em primeiro lugar, mas isso é outra história. Infelizmente, sua matriz provavelmente não está mais em um estado recuperável.

A invasão do software Linux supõe que a matriz esteja íntegra (limpa), a menos que um erro de leitura ou gravação seja sinalizado pelo controlador de disco, conforme explicado no Linux raid wiki . O driver assume que, porque há muitos dados redundantes armazenados no disco e o link entre o disco rígido e o controlador também usa detecção de erros.

Então, a sua situação é quatro (no modo RAID6) os blocos de paridade não são nem lidos.

Sobrescrever um de seu disco foi (no ponto de vista do disco) uma requisição perfeitamente válida e foi completada pelo seu disco sem erro.

Agora, quando você solicitou uma reconstrução de matriz usando um disco com dados corrompidos, você apenas espalhou dados corrompidos por toda a matriz.

O correto é deixar a unidade com defeito e adicioná-la novamente à matriz. A matriz teria sido reconstruída em um estado seguro.

    
por 23.08.2017 / 14:47