Come ripristinare un array mdadm su Synology NAS con unità nello stato "E"?


12

Synology ha una versione personalizzata del driver md e dei set di strumenti mdadm che aggiunge un flag 'DriveError' alla struttura dei flag rdev-> nel kernel.

Effetto netto - se si è abbastanza sfortunati da ottenere un errore dell'array (prima unità), combinato con un errore su una seconda unità - l'array entra nello stato di non consentire di riparare / ricostruire l'array anche se le letture dall'unità funzionano bene.

A questo punto, non sono davvero preoccupato per questa domanda dal punto di vista di QUESTO array, dal momento che ho già tirato fuori il contenuto e ho intenzione di ricostruirlo, ma più dal voler avere un percorso di risoluzione per questo in futuro , poiché è la seconda volta che ci provo e so di aver visto altri fare domande simili nei forum.

Il supporto di Synology è stato poco utile (e per lo più non reattivo), e non condividerà TUTTE le informazioni su come gestire i raidet sulla scatola.

Contenuti di / proc / mdstat:

ds1512-ent> cat /proc/mdstat 
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 
md2 : active raid5 sdb5[1] sda5[5](S) sde5[4](E) sdd5[3] sdc5[2]
      11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/4] [_UUUE]

md1 : active raid1 sdb2[1] sdd2[3] sdc2[2] sde2[4] sda2[0]
      2097088 blocks [5/5] [UUUUU]

md0 : active raid1 sdb1[1] sdd1[3] sdc1[2] sde1[4] sda1[0]
      2490176 blocks [5/5] [UUUUU]

unused devices: <none>

Stato da un mdadm --detail / dev / md2:

/dev/md2:
        Version : 1.2
  Creation Time : Tue Aug  7 18:51:30 2012
     Raid Level : raid5
     Array Size : 11702126592 (11160.02 GiB 11982.98 GB)
  Used Dev Size : 2925531648 (2790.00 GiB 2995.74 GB)
   Raid Devices : 5
  Total Devices : 5
    Persistence : Superblock is persistent

    Update Time : Fri Jan 17 20:48:12 2014
          State : clean, degraded
 Active Devices : 4
Working Devices : 5
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 64K

           Name : MyStorage:2
           UUID : cbfdc4d8:3b78a6dd:49991e1a:2c2dc81f
         Events : 427234

    Number   Major   Minor   RaidDevice State
       0       0        0        0      removed
       1       8       21        1      active sync   /dev/sdb5
       2       8       37        2      active sync   /dev/sdc5
       3       8       53        3      active sync   /dev/sdd5
       4       8       69        4      active sync   /dev/sde5

       5       8        5        -      spare   /dev/sda5

Come puoi vedere - / dev / sda5 è stato nuovamente aggiunto all'array. (È stato il disco a fallire del tutto) - ma anche se md vede il disco come ricambio, non lo ricostruirà. / dev / sde5 in questo caso è l'unità problematica con lo stato (E) DiskError.

Ho provato ad arrestare il dispositivo md, eseguendo la riassemblaggio della forza, rimuovendo / leggendo sda5 dal dispositivo / ecc. Nessun cambiamento nel comportamento.

Sono stato in grado di ricreare completamente l'array con il seguente comando:

mdadm --stop /dev/md2
mdadm --verbose \
   --create /dev/md2 --chunk=64 --level=5 \
   --raid-devices=5 missing /dev/sdb5 /dev/sdc5 /dev/sdd5 /dev/sde5

che ha riportato l'array in questo stato:

md2 : active raid5 sde5[4] sdd5[3] sdc5[2] sdb5[1]
      11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/4] [_UUUU]

Ho quindi aggiunto nuovamente / dev / sda5:

mdadm --manage /dev/md2 --add /dev/sda5

dopo di che ha iniziato una ricostruzione:

md2 : active raid5 sda5[5] sde5[4] sdd5[3] sdc5[2] sdb5[1]
      11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/4] [_UUUU]
      [>....................]  recovery =  0.1% (4569508/2925531648) finish=908.3min speed=53595K/sec

Notare la posizione dell'unità "mancante" corrispondente alla posizione esatta dello slot mancante.

Una volta finito, penso che probabilmente tirerò il disco discutibile e lo farò ricostruire di nuovo.

Sto cercando qualche suggerimento se esiste un modo "meno spaventoso" per fare questa riparazione - o se qualcuno ha vissuto questa esperienza con un array Synology e sa come costringerlo a ricostruire oltre a portare offline il dispositivo md e ricreare l'array da zero.


Mi trovo in una situazione simile. Hai risolto questo problema con successo?
Dvorak,

Sì, sono stato in grado di ricostruire l'array seguendo i passaggi precedenti. L'ho seguito con la cancellazione e il passaggio da R5 a R6, perché a questo punto, sono seriamente insoddisfatto del comportamento "tank the array completo" di Synology che volevo assicurarmi di tollerare più di un drive "in errore ". Nel nostro caso, la seconda unità con l'errore "glitch" ha superato test intelligenti estesi senza nemmeno un singolo problema.
Nathan Neulinger,

Grazie per la guida utile. Non sono troppo sicuro di armeggiare con tutto questo, non sono uno specialista delle incursioni. Ora sto affrontando lo stesso problema, ma nel mio caso, ho un array RAID 1 a disco singolo (/ dev / md3) con / dev / sde3 contrassegnato con il temuto [E]. Presumo che dovrebbe essere possibile per me seguire gli stessi passaggi che hai fatto tu, ma dato che si tratta del singolo disco dell'array, non so che cosa farà ;-). Ad ogni modo il comando mdadm --stop / dev / md3 ha esito negativo (Dispositivo o risorsa occupata). Immagino che Google un po 'più a lungo .. =)
dSebastien,

Se non riesci a fermare l'array, sembra che qualcosa lo stia usando, ovvero sia montato o ci sia qualche altra attività in esecuzione su quel dispositivo.
Nathan Neulinger,

2
Fortunatamente per me Synology mi ha aiutato a risolvere il problema. Sono stati così gentili da fornirmi i comandi che hanno eseguito. Ho messo le informazioni sul mio blog nel caso in cui qualcun altro incontri
dSebastien

Risposte:


3

Solo un'aggiunta alla soluzione che ho trovato dopo aver riscontrato lo stesso problema. Ho seguito il post sul blog di dSebastien su come ricreare l'array:

Ho scoperto che quel metodo per ricreare l'array ha funzionato meglio di questo metodo sopra. Tuttavia, dopo aver ricreato l'array, il volume non veniva ancora visualizzato sull'interfaccia Web. Nessuno dei miei LUN stava mostrando. Fondamentalmente mostrando un nuovo array senza nulla di configurato. Ho contattato il supporto Synology e mi sono ricontattato per risolvere il problema. Sfortunatamente, hanno remotato mentre ero lontano dalla console. Sono riuscito comunque a catturare la sessione e ho guardato attraverso quello che hanno fatto. Durante il tentativo di recuperare alcuni dei miei dati, l'unità si è arrestata nuovamente in modo anomalo ed ero di nuovo nella stessa situazione. Ho ricreato l'array come nel blog di dSebastien e poi ho guardato attraverso la sessione di sinologia per eseguire il loro aggiornamento. Dopo aver eseguito i comandi seguenti, il mio array e i LUN sono apparsi sull'interfaccia Web e sono stato in grado di lavorare con loro. Ho praticamente zero esperienza in Linux, ma questi erano i comandi che ho eseguito nella mia situazione. Spero che questo possa aiutare qualcun altro, ma per favore usa questo a tuo rischio. Sarebbe meglio contattare l'assistenza Synology e chiedere loro di risolvere questo problema per te, poiché questa situazione potrebbe essere diversa dalla tua

DiskStation> synocheckiscsitrg
synocheckiscsitrg: Pass 

DiskStation> synocheckshare
synocheckshare: Pass SYNOICheckShare()
synocheckshare: Pass SYNOICheckShareExt()
synocheckshare: Pass SYNOICheckServiceLink()
synocheckshare: Pass SYNOICheckAutoDecrypt()
synocheckshare: Pass SYNOIServiceShareEnableDefaultDS()

DiskStation> spacetool --synoblock-enum
****** Syno-Block of /dev/sda ******
//I've removed the output. This should display info about each disk in your array

DiskStation> vgchange -ay
  # logical volume(s) in volume group "vg1" now active

DiskStation> dd if=/dev/vg1/syno_vg_reserved_area of=/root/reserved_area.img
24576+0 records in
24576+0 records out

DiskStation> synospace --map_file -d
Success to dump space info into '/etc/space,/tmp/space'

DiskStation> synocheckshare
synocheckshare: Pass SYNOICheckShare()
synocheckshare: Pass SYNOICheckShareExt()
synocheckshare: Pass SYNOICheckServiceLink()
synocheckshare: Pass SYNOICheckAutoDecrypt()
synocheckshare: Pass SYNOIServiceShareEnableDefaultDS()

DiskStation> synocheckiscsitrg
synocheckiscsitrg: Not Pass, # conflict 

DiskStation> synocheckiscsitrg
synocheckiscsitrg: Pass 

1

Un'altra aggiunta: ho riscontrato un problema molto simile con il mio dispositivo di livello 0 a un disco / RAID.

Il supporto Synology è stato molto utile e ha ripristinato il mio dispositivo. Ecco cosa è successo, spero che questo aiuti gli altri:

Il mio disco aveva errori di lettura su un blocco particolare, i messaggi nel registro di sistema ( dmesg) erano:

[4421039.097278] ata1.00: read unc at 105370360
[4421039.101579] lba 105370360 start 9437184 end 5860528064
[4421039.106917] sda3 auto_remap 0
[4421039.110097] ata1.00: exception Emask 0x0 SAct 0x2 SErr 0x0 action 0x6
[4421039.116744] ata1.00: edma_err_cause=00000084 pp_flags=00000003, dev error, EDMA self-disable
[4421039.125410] ata1.00: failed command: READ FPDMA QUEUED
[4421039.130767] ata1.00: cmd 60/00:08:b8:d2:47/02:00:06:00:00/40 tag 1 ncq 262144 in
[4421039.130772]          res 41/40:00:f8:d2:47/00:00:06:00:00/40 Emask 0x409 (media error) <F>
[4421039.146855] ata1.00: status: { DRDY ERR }
[4421039.151064] ata1.00: error: { UNC }
[4421039.154758] ata1: hard resetting link
[4421039.667234] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
[4421039.887286] ata1.00: configured for UDMA/133
[4421039.891777] ata1: UNC RTF LBA Restored
[4421039.895745] ata1: EH complete

Pochi secondi dopo ho ricevuto la terribile Volume 1 has crashedposta dal mio dispositivo.

- Dichiarazione di non responsabilità: assicurarsi di sostituire il nome del dispositivo con il proprio e non semplicemente copiare e incollare questi comandi, poiché ciò potrebbe peggiorare le cose! -

Dopo aver interrotto smb sono stato in grado di reinstallare la partizione in sola lettura ed eseguire e2fsk con badblocks check ( -c):

umount /dev/md2
e2fsck -C 0 -v -f -c /dev/md2

(si potrebbe anche usare e2fsck -C 0 -p -v -f -c /dev/md2per eseguire il più incustodito possibile, anche se questo non ha funzionato nel mio caso, perché gli errori dovevano essere riparati manualmente. Quindi ho dovuto riavviare e2fsck. Conclusio: -p non ha molto senso in caso di errore del disco)

Sebbene e2fsck fosse in grado di correggere gli errori e smartctl non mostrasse più alcun aumento in Raw_Read_Error_Rate, il volume non sarebbe stato montato in modalità lettura-scrittura dal dispositivo. DSM mostrava ancora "volume bloccato"

Quindi ho aperto un ticket con il supporto. Ci è voluto un po 'di tempo prima che le cose iniziassero, ma alla fine l'hanno risolto ricostruendo l'array RAID con:

synospace --stop-all-spaces
syno_poweroff_task -d 
mdadm -Sf /dev/md2
mdadm -AfR /dev/md2 /dev/sda3

Assicurati di controllare i nomi dei tuoi dispositivi ( /dev/mdXe /dev/sdaX) prima di fare qualsiasi cosa. cat /proc/mdstatmostrerà le informazioni pertinenti.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.