Newsgroup: it.comp.os.linux.sys
Titolo: Problemi con raid degraded

Salve a tutti.
Controllando il log di logwatch sono saltato sulla sedia.
Ho trovato questo:
1 Time(s): EXT3 FS on md0, internal journal
1 Time(s): EXT3 FS on md1, internal journal
1 Time(s): EXT3 FS on md2, internal journal
1 Time(s): EXT3 FS on md3, internal journal
1 Time(s): EXT3 FS on md4, internal journal
1 Time(s): EXT3 FS on md5, internal journal
1 Time(s): EXT3 FS on sda1, internal journal
1 Time(s): EXT3 FS on sda12, internal journal
1 Time(s): EXT3 FS on sda6, internal journal
1 Time(s): EXT3-fs: INFO: recovery required on readonly filesystem.
1 Time(s): EXT3-fs: md0: 4 orphan inodes deleted
1 Time(s): EXT3-fs: md0: orphan cleanup on readonly fs
9 Time(s): EXT3-fs: mounted filesystem with ordered data mode.
1 Time(s): EXT3-fs: recovery complete.
1 Time(s): EXT3-fs: write access will be enabled during recovery.
1 Time(s): ata1.00: ATA-7, max UDMA/133, 625142448 sectors: LBA48 NCQ
(depth 1)
1 Time(s): ata1.00: ata1: dev 0 multi count 16
1 Time(s): ata1.00: configured for UDMA/133
1 Time(s): ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
1 Time(s): ata1: SATA max UDMA/133 cmd 0xF8832100 ctl 0x0 bmdma 0x0
irq 217
1 Time(s): ata2.00: ATA-7, max UDMA/133, 586114704 sectors: LBA48 NCQ
(depth 31/32)
1 Time(s): ata2.00: ata2: dev 0 multi count 16
1 Time(s): ata2.00: configured for UDMA/133
1 Time(s): ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
1 Time(s): ata2: SATA max UDMA/133 cmd 0xF8832180 ctl 0x0 bmdma 0x0
irq 217
1 Time(s): ata3: SATA link down (SStatus 0 SControl 300)
1 Time(s): ata3: SATA max UDMA/133 cmd 0xF8832200 ctl 0x0 bmdma 0x0
irq 217
1 Time(s): ata4: SATA link down (SStatus 0 SControl 300)
1 Time(s): ata4: SATA max UDMA/133 cmd 0xF8832280 ctl 0x0 bmdma 0x0
irq 217
1 Time(s): md:  adding sda10 ...
1 Time(s): md:  adding sda11 ...
7 Time(s): md:  adding sda2 ...
7 Time(s): md:  adding sda7 ...
7 Time(s): md:  adding sda8 ...
7 Time(s): md:  adding sda9 ...
1 Time(s): md:  adding sdb1 ...
1 Time(s): md:  adding sdb2 ...
1 Time(s): md:  adding sdb3 ...
1 Time(s): md:  adding sdb5 ...
1 Time(s): md:  adding sdb6 ...
1 Time(s): md:  adding sdb7 ...
7 Time(s): md: ... autorun DONE.
7 Time(s): md: Autodetecting RAID arrays.
7 Time(s): md: autorun ...
1 Time(s): md: bind<sda10>
1 Time(s): md: bind<sda11>
1 Time(s): md: bind<sda2>
1 Time(s): md: bind<sda7>
1 Time(s): md: bind<sda8>
1 Time(s): md: bind<sda9>
1 Time(s): md: bind<sdb1>
1 Time(s): md: bind<sdb2>
1 Time(s): md: bind<sdb3>
1 Time(s): md: bind<sdb5>
1 Time(s): md: bind<sdb6>
1 Time(s): md: bind<sdb7>
6 Time(s): md: considering sda2 ...
6 Time(s): md: considering sda7 ...
6 Time(s): md: considering sda8 ...
6 Time(s): md: considering sda9 ...
1 Time(s): md: considering sdb1 ...
1 Time(s): md: considering sdb2 ...
1 Time(s): md: considering sdb3 ...
1 Time(s): md: considering sdb5 ...
1 Time(s): md: considering sdb6 ...
1 Time(s): md: considering sdb7 ...
1 Time(s): md: created md0
1 Time(s): md: created md1
1 Time(s): md: created md2
1 Time(s): md: created md3
1 Time(s): md: created md4
1 Time(s): md: created md5
7 Time(s): md: export_rdev(sda2)
7 Time(s): md: export_rdev(sda7)
7 Time(s): md: export_rdev(sda8)
7 Time(s): md: export_rdev(sda9)
1 Time(s): md: kicking non-fresh sda2 from array!
1 Time(s): md: kicking non-fresh sda7 from array!
1 Time(s): md: kicking non-fresh sda8 from array!
1 Time(s): md: kicking non-fresh sda9 from array!
1 Time(s): md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
6 Time(s): md: md0 already running, cannot run sda2
6 Time(s): md: md1 already running, cannot run sda7
6 Time(s): md: md2 already running, cannot run sda8
6 Time(s): md: md3 already running, cannot run sda9
1 Time(s): md: md4: raid array is not clean -- starting background
reconstruction
1 Time(s): md: md4: sync done.
1 Time(s): md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/
disc.
1 Time(s): md: raid1 personality registered as nr 3
1 Time(s): md: running: <sdb1><sda2>
1 Time(s): md: running: <sdb2><sda7>
1 Time(s): md: running: <sdb3><sda8>
1 Time(s): md: running: <sdb5><sda9>
1 Time(s): md: running: <sdb6><sda10>
1 Time(s): md: running: <sdb7><sda11>
1 Time(s): md: sda10 has different UUID to sdb7
3 Time(s): md: sda2 has different UUID to sda7
3 Time(s): md: sda2 has different UUID to sda8
3 Time(s): md: sda2 has different UUID to sda9
1 Time(s): md: sda2 has different UUID to sdb2
1 Time(s): md: sda2 has different UUID to sdb3
1 Time(s): md: sda2 has different UUID to sdb5
1 Time(s): md: sda2 has different UUID to sdb6
1 Time(s): md: sda2 has different UUID to sdb7
3 Time(s): md: sda7 has different UUID to sda2
3 Time(s): md: sda7 has different UUID to sda8
3 Time(s): md: sda7 has different UUID to sda9
1 Time(s): md: sda7 has different UUID to sdb3
1 Time(s): md: sda7 has different UUID to sdb5
1 Time(s): md: sda7 has different UUID to sdb6
1 Time(s): md: sda7 has different UUID to sdb7
3 Time(s): md: sda8 has different UUID to sda2
3 Time(s): md: sda8 has different UUID to sda7
3 Time(s): md: sda8 has different UUID to sda9
1 Time(s): md: sda8 has different UUID to sdb5
1 Time(s): md: sda8 has different UUID to sdb6
1 Time(s): md: sda8 has different UUID to sdb7
3 Time(s): md: sda9 has different UUID to sda2
3 Time(s): md: sda9 has different UUID to sda7
3 Time(s): md: sda9 has different UUID to sda8
1 Time(s): md: sda9 has different UUID to sdb6
1 Time(s): md: sda9 has different UUID to sdb7
1 Time(s): md: sdb1 has different UUID to sdb2
1 Time(s): md: sdb1 has different UUID to sdb3
1 Time(s): md: sdb1 has different UUID to sdb5
1 Time(s): md: sdb1 has different UUID to sdb6
1 Time(s): md: sdb1 has different UUID to sdb7
1 Time(s): md: sdb2 has different UUID to sdb3
1 Time(s): md: sdb2 has different UUID to sdb5
1 Time(s): md: sdb2 has different UUID to sdb6
1 Time(s): md: sdb2 has different UUID to sdb7
1 Time(s): md: sdb3 has different UUID to sdb5
1 Time(s): md: sdb3 has different UUID to sdb6
1 Time(s): md: sdb3 has different UUID to sdb7
1 Time(s): md: sdb5 has different UUID to sdb6
1 Time(s): md: sdb5 has different UUID to sdb7
1 Time(s): md: sdb6 has different UUID to sdb7
1 Time(s): md: syncing RAID array md4
1 Time(s): md: unbind<sda2>
1 Time(s): md: unbind<sda7>
1 Time(s): md: unbind<sda8>
1 Time(s): md: unbind<sda9>
1 Time(s): md: using 128k window, over a total of 48829440 blocks.
1 Time(s): md: using maximum available idle IO bandwith (but not more
than 200000 KB/sec) for reconstruction.
1 Time(s): raid1: raid set md0 active with 1 out of 2 mirrors
1 Time(s): raid1: raid set md1 active with 1 out of 2 mirrors
1 Time(s): raid1: raid set md2 active with 1 out of 2 mirrors
1 Time(s): raid1: raid set md3 active with 1 out of 2 mirrors
1 Time(s): raid1: raid set md4 active with 2 out of 2 mirrors
1 Time(s): raid1: raid set md5 active with 2 out of 2 mirrors
anche se poi alla fine ...
------------------ Disk Space --------------------
/dev/md0               19G  6.7G   11G  39% /
/dev/sda1              92M   34M   54M  39% /boot
/dev/md1              138G   16G  115G  12% /home
/dev/sda6             1.9G   35M  1.8G   2% /opt
/dev/sda12             13G   65M   13G   1% /usr/local
/dev/md2              4.6G  471M  3.9G  11% /var
/dev/md3              5.5G  145M  5.1G   3% /var/log
/dev/md4               46G   15G   30G  33% /var/spool/mail
Da quello che ho capito per md1, 2 e 3 non funziona il mirroring
perchè il secondo disco non viene mirrorato.
Io non ho una grande esperienza nel RAID. Avreste qualche consiglio da
darmi ?
Grazie !

 darmi ?
Vedi cosa dice /proc/mdstat.
-- 
Per rispondermi, sostituisci a nomecognome il mio nome e cognome
To reply me, substitute nomecognome with my real name and surname

 Da quello che ho capito per md1, 2 e 3 non funziona il mirroring
anche md0, dovrebbe bastare togliere e riaggiungere la partizioni,
se non si e` incasinato altro perche' hai uno schema un po' strano
se tutto corrisponde (lo sai tu, perche' dal log non si vede), dai
/sbin/mdadm /dev/mdX --fail /dev/sdaY --remove /dev/sdaY
/sbin/mdadm /dev/mdX --add /dev/sdaY
per le varie partizioni saltate in corrispondenza degli array

 /sbin/mdadm /dev/mdX --add /dev/sdaY
Se il raid è saltato con tutta probabilità il disco sta andando.
Riaggiungerlo brutalmente non è cosa buona e giusta perché può comportare
problemi.
*Prima* è meglio capire perché il mirror è saltato, 
p.es
. iniziando con smartctl
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 *Prima* è meglio capire perché il mirror è saltato, 
p.es
. iniziando con smartctl
io proporrei PRIMA di tutto di backuppare (se non e' gia' stato
fatto).
Ciao Jack

Diciamo che mentre stavo forzando uno spool di mail (sendmail) mi è
arrivato questo messaggio su root:
-> A DegradedArray event had been detected on md device /dev/md0 <-
e poi via di seguito per gli altri device
Sospetto (ma è solo un sospetto) che durante lo "spurgo" della coda ci
sia stato un attimo in cui il server non sia riuscito a sincronizzare
i dati in RAID. Per prevenire danni ha sganciato le unità in mirror.
md4 è riuscito a riagganciarlo ed a ricostruirlo al riavvio. Gli altri
no.
Penso pure io di fare un controllo preventivo con smartctl.
In questo caso devo monitorare con smartctl le singole unità sda, non
gli md ... giusto ?
smartctl -l error /dev/sd.... per vedere gli errori
smartctl -l selftest /dev/sd.... per il Self Test Error Log
In ogni caso, se il problema non è negli hd ma è solo un problema di
sync dell'array come scoprire l'accoppiamento delle unità fisiche (ad
es.: sda1 + sdb1) ? Basta digitare mdadm --detail --scan ?
E poi ... dato ad esempio:
ARRAY /dev/md2 level=raid1 num-devices=2 UUID=85c9e2d5:b6f422bd:
002eb213:c4ccebe9 devices=/dev/sda1,/dev/sdb1
e dato per esempio che sdb1 è fuori sync dell'array ... come riunire
sdb1 a sda1 all'interno dell'array md2 ?

 *Prima* è meglio capire perché il mirror è saltato, 
p.es
. iniziando con smartctl
nulla da dire, pero` se mi finisci con smartctl...
quantomeno sui sata, non vale una cippa

 quantomeno sui sata, non vale una cippa
Perche'?
-- 
Cybertoldo
Per rispondermi via email, sostituisci moc.liamg con 
gmail.com

 quantomeno sui sata, non vale una cippa
Argomenta, please.



In pratica vedendo le statistiche dello SMART sulle decine di migliaia
di dischi fissi che utilizzano internamente hanno notato che:
nel 56% dei casi i dischi sono defunti senza alcun preavviso dallo SMART;
le rotture non hanno correlazione con le temperature di esercizio dei
dischi;
ci sono ben precise correlazioni fra marche e modelli di dischi e
rotture precoci.
Purtroppo non hanno specificato marche e modelli, però come dice
Andreotti "a pensare maxtor si fa peccato, ma spesso ci si azzecca"... ;)
Tobe

 dischi;
In un altro articolo si vede invece una correlazione negativa, ovvero piu'
fa caldo e piu' i dischi durano. Questo viene spiegato con il fatto che i
produttori non possono testare gli hd per anni prima di rilasciarli sul
mercato, quindi ne simulano l'usura facendoli lavorare a temperature piu'
elevate, con il risultato che in quell'intervallo durano di piu'.


 nel 56% dei casi i dischi sono defunti senza alcun preavviso dallo SMART;
Il che significa che nel 44% dei casi l'uso di SMART ha dato preavviso,
ovvero circa nella metà dei casi. Raddoppiare l'affidabilità dello storage
di un'infrastruttura non mi sembra un risultato trascurabile.
Tralasciando questo mi piacerebbe sapere da Jack perché ha specificato che
sui SATA non vale una cippa. Sono intimamente convinto che l'affermazione
derivi dall'omissione di "--device=ata" (e non lettura del man), dato che è
l'*unica* differenza riscontrabile nell'uso di SMART su dischi SATA in
raffronto agli ATA. Cercavo solo conferma alle mie teorie (a giudicare dal
silenzio) o un'argomentazione a supporto della tesi.


 di un'infrastruttura non mi sembra un risultato trascurabile.
Non mi e' chiaro perche' l'affidabilita' sia raddoppiata.


 Non mi e' chiaro perche' l'affidabilita' sia raddoppiata.
In realtà non è propriamente corretto riferirsi all'affidabilità. :-)
Il senso della frase è che se previeni la rottura del disco nella metà dei
casi hai i seguenti benefici
*) dimezzi la possibilità di perdere dati se non usi raid, in quanto puoi
subito cambiare il disco salvandoti il salvabile
*) puoi pianificare l'intervento di sostituzione in modo tale da avere un
minore impatto sulle performance del servizio (
p.es
. di sera)
*) riduci il pericolo di corruzione dei dati che può avvenire al momento
della rottura, eseguendo una sostituzione programmata
L'impatto è sulla *disponibilità* dei servizi.


 casi hai i seguenti benefici
Bisognerebbe mettere nel conto anche il fatto che usare SMART puo' darti un
falso senso di sicurezza...tu ricorreresti ad un esame medico che nel 50%
dei casi da' una diagnosi sbagliata?


 Andreotti "a pensare maxtor si fa peccato, ma spesso ci si azzecca"... ;)
Tra le varie marche mi sono capitati anche diversi Maxtor vecchio 
modello (ora li produce Seagate, sono identici ai Barracuda ma con meno 
cache).
E' vero: i Maxtor mi sono sempre durati poco rispetto alla media... 
pero' tutti quelli che ho avuto sono sempre stati onesti con i valori 
dello SMART: se ne hai qualcuno con uno dei tre attributi critici sopra 
citati superiore allo zero, ti consiglio di sostituirlo al piu' presto :)
Inoltre, se puo' essere ormai d'interesse, ho notato che i vecchi Maxtor 
erano discretamente piu' affidabili (si fa per dire) se tenuti ventilati 
a basse temperature; e qui la mia esperienza personale sembrerebbe in 
contrasto con i test di google - ma, come dici anche tu, bisognerebbe 
vedere quelle statistiche per marca/modello...


 dei casi da' una diagnosi sbagliata?
...ma no! SMART, nella maggiorparte dei casi, non ti da' nessuna 
diagnosi. Di norma ti dice solo che i rischi aumentano. Come spesso 
avviene anche con gli esami o le analisi mediche (per tornare alla tua 
analogia).


 elevate, con il risultato che in quell'intervallo durano di piu'.
Se e' per questo ho visto HD volare in terra da 1 metro di altezza e una
volta montati sono partiti come se nulla fosse. Peccato abbiamo funzionato
6 mesi o poco piu'.
IMO uno studio realistico dovrebbe tenere conto degli effetti
causati dal calore rispetto all'eta' della periferica.
Ciao Giuseppe

 causati dal calore rispetto all'eta' della periferica.
Che e' esattamente quello che quello studio ha fatto, sono i produttori di
hard disk che lavorano su archi temporali di settimane o mesi.
