RAID 1 e array non sincronizzati
Carlo
Ho questo strano problema su un server (nuovo dell t105) debian lenny
con raid 1
L'errore ￜ abbastanza frequente (1 volta alla settimana) e i miei array
delle partizioni saltano e da completamente sincronizzati passano a uno
stato tipo questo:
Personalities : [raid1]
md6 : active raid1 sda10[0] sdb10[1]
393472 blocks [2/2] [UU]
md5 : active raid1 sda8[0] sdb8[1]
9767424 blocks [2/2] [UU]
md4 : active raid1 sda7[2](F) sdb7[1]
9767424 blocks [2/1] [_U]
md3 : active raid1 sda6[0]
29294400 blocks [2/1] [U_]
md2 : active raid1 sda5[2](F) sdb5[1]
68356416 blocks [2/1] [_U]
md1 : active raid1 sda2[2](F) sdb2[1]
5855616 blocks [2/1] [_U]
md0 : active raid1 sda1[0] sdb1[1]
586240 blocks [2/2] [UU]
Intanto posso dire che sono dischi SATA e quando succede questa cosa
praticamente uno dei due dischi diventa inaccessibile.
Nel caso sopra sembra essersi sganciato sda.
La partizione sda6 perￜ contiene la var che perￜ non risulta
inaccessibile anche perchￜ dopo questi errori il server funziona benissimo.
Ho ricontrollato i cablaggi diverse volte e tutti i connettori risultano
connessi correttamente e a fondo (problema molto comune dei dischi sata
che a un bel momento non diventano piￜ leggibili causa connettore
fissato male).
Con un reboot il disco che prima era inaccessibile torna a funzionare
magicamente, unica scocciatura mi tocca riaggiungere all'array
danneggiato le partizioni manualmente.
qualcuno ha avuto esperienze simili / idee al riguardo?
Saluti
Carlo
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-ital...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listm...@lists.debian.org
To UNSUBSCRIBE, email to debian-ital...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Shin Ice
Hash: SHA1
Carlo wrote:
> qualcuno ha avuto esperienze simili / idee al riguardo?
capitato e mi ricapiterￜ piￜ volte XD
kern.log che ti dice?
- --
Don't Trust if you don't want!
Don't Believe if you don't Touch!
--> Powered by Debian Testing <--
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkof7WEACgkQNzyKI2pL1/d9qQCdFtUFXHXtOSXHw64KExVWBez3
tPYAoMjE3c343MQLGYSj6x4afSM1Oz+0
=N/9a
-----END PGP SIGNATURE-----
Marco Bertorello
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Carlo wrote:
>> qualcuno ha avuto esperienze simili / idee al riguardo?
>
>
Idem, ogni tanto inspiegabilmente, succede anche a me su una oldstable
su server hp... però poi basta re-inserire il disco nell'array che si
risincronizza e funziona benone per $RANDOMTIME...
ciao,
--
Marco Bertorello
System Administrator
http://bertorello.ns0.it
Paolo Sala
> Ciao a tutti
>
> Ho questo strano problema su un server (nuovo dell t105) debian lenny
> con raid 1
>
> array delle partizioni saltano e da completamente sincronizzati
> passano a uno stato tipo questo:
>
> Personalities : [raid1] md6 : active raid1 sda10[0] sdb10[1]
> 393472 blocks [2/2] [UU]
> md5 : active raid1 sda8[0] sdb8[1]
> 9767424 blocks [2/2] [UU]
> md4 : active raid1 sda7[2](F) sdb7[1]
> 9767424 blocks [2/1] [_U]
> md3 : active raid1 sda6[0]
> 29294400 blocks [2/1] [U_]
> md2 : active raid1 sda5[2](F) sdb5[1]
> 68356416 blocks [2/1] [_U]
> md1 : active raid1 sda2[2](F) sdb2[1]
> 5855616 blocks [2/1] [_U]
> md0 : active raid1 sda1[0] sdb1[1]
> 586240 blocks [2/2] [UU]
Da quel che scrivi sembra che sda10, sda8 e sda1 non entrino in fault,
sda quindi è ancora accessibile e allora: perché fai il reboot invece di
un re-add?
I log non dicono niente?
Piviul
Carlo
Intanto grazie per le risposte!
Vedo che è un problema comune...
Paolo Sala ha scritto:
> Carlo scrisse in data 29/05/2009 15:05:
>
>> Ciao a tutti
>>
>> Ho questo strano problema su un server (nuovo dell t105) debian lenny
>> con raid 1
>>
>> L'errore è abbastanza frequente (1 volta alla settimana) e i miei
>> array delle partizioni saltano e da completamente sincronizzati
>> passano a uno stato tipo questo:
>>
>> Personalities : [raid1] md6 : active raid1 sda10[0] sdb10[1]
>> 393472 blocks [2/2] [UU]
>> md5 : active raid1 sda8[0] sdb8[1]
>> 9767424 blocks [2/2] [UU]
>> md4 : active raid1 sda7[2](F) sdb7[1]
>> 9767424 blocks [2/1] [_U]
>> md3 : active raid1 sda6[0]
>> 29294400 blocks [2/1] [U_]
>> md2 : active raid1 sda5[2](F) sdb5[1]
>> 68356416 blocks [2/1] [_U]
>> md1 : active raid1 sda2[2](F) sdb2[1]
>> 5855616 blocks [2/1] [_U]
>> md0 : active raid1 sda1[0] sdb1[1]
>> 586240 blocks [2/2] [UU]
>>
> Sei sicuro della configurazione di md3? I 2 hd, sda e sdb, sono uguali?
>
Si i dischi sono due WD RE da 160 gb quindi anche un hardware decente.
Dunque su md3 ha avuto qualche problemi e devo proprio riaddarlo (sdb6)
nell'array md3.
Non so come (forse mi son sbagliato io) ma era finito su md6 poi si è
piantanto nel senso che non si riusciva più a togliere da md6 perchè
dava sempre errore come partizione busy.
Oggi vado appunto sul posto smounto quello che sta sopra a md6 tolgo
sdb6 da md6 e lo e lo rimetto al posto giusto cioè md3. Spero che
smontando quello che ci sta sopra mi dia la possibilità di smontarlo e
spostarlo altrove.
La cosa strana è l'sda6 che rimane attiva nonostante sda il disco
praticamente rimanga inaccessibile mah. cercherò di capirci qualcosa con
il tempo.
> Da quel che scrivi sembra che sda10, sda8 e sda1 non entrino in fault,
> sda quindi è ancora accessibile e allora: perché fai il reboot invece di
> un re-add?
>
Eh si mi è capitato poi di andare a stuzzicare le partizioni che
sembravano ancora attive e lui si accorgeva che proprio tutto bene non
andava e me le metteva poi in fault.
Facendo il reboot tutto torna normale o almeno quasi... perchè alcune
partizioni devo riaddarle manualmente.
Lo faccio riavviare una volta a settimana in notturna proprio per
evitare questa cosa. ma se continua su questa strada lo farò tutte le
notti dopo il backup.
> I log non dicono niente?
>
kern.log che ti dice?
si mi avete chiesto kern.log che dice.
Ci ho guardato e non ho trovato nulla che mi potesse instradare a un
possibile sia problema sia soluzione.
Comunque guarderò meglio e vi faccio sapere visto che è un problema comune.
Avete idea di cosa cercare in specifico?
Grazie ancora per le risposte!
Carlo
Carlo
>> con raid 1
>>
>> L'errore è abbastanza frequente (1 volta alla settimana) e i miei
>> array delle partizioni saltano e da completamente sincronizzati
>> passano a uno stato tipo questo:
>>
>> Personalities : [raid1] md6 : active raid1 sda10[0] sdb10[1]
>> 393472 blocks [2/2] [UU]
>> md5 : active raid1 sda8[0] sdb8[1]
>> 9767424 blocks [2/2] [UU]
>> md4 : active raid1 sda7[2](F) sdb7[1]
>> 9767424 blocks [2/1] [_U]
>> md3 : active raid1 sda6[0]
>> 29294400 blocks [2/1] [U_]
>> md2 : active raid1 sda5[2](F) sdb5[1]
>> 68356416 blocks [2/1] [_U]
>> md1 : active raid1 sda2[2](F) sdb2[1]
>> 5855616 blocks [2/1] [_U]
>> md0 : active raid1 sda1[0] sdb1[1]
>> 586240 blocks [2/2] [UU]
>>
> Sei sicuro della configurazione di md3? I 2 hd, sda e sdb, sono uguali?
>
> Da quel che scrivi sembra che sda10, sda8 e sda1 non entrino in fault,
> sda quindi è ancora accessibile e allora: perché fai il reboot invece di
> un re-add?
>
> I log non dicono niente?
>
>
Ecco cosa dicono i log(è un piccolo estratto):
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: BMDMA stat 0x5
ata1.00: cmd c8/00:08:26:ac:1c/00:00:00:00:00/ed tag 0 dma 4096 in
res 51/40:08:26:ac:1c/00:00:00:00:00/ed Emask 0x9 (media error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { UNC }
ata1.00: configured for UDMA/133
ata1: EH complete
sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
0d 1c ac 26
sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate
failed
end_request: I/O error, dev sda, sector 219982886
raid1: sda7: rescheduling sector 11796488
ata1: EH complete
sd 0:0:0:0: [sda] 312500000 512-byte hardware sectors (160000 MB)
Write Protect is off
Mode Sense: 00 3a 00 00
Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
312500000 512-byte hardware sectors (160000 MB)
raid1:md4: read error corrected (8 sectors at 11796488 on sda7)
raid1: sdb7: redirecting sector 11796488 to another mirror
md: super_written gets error=-5, uptodate=0
raid1: Disk failure on sda5, disabling device.
raid1: Operation continuing on 1 devices.
ata1: EH complete
Dunque potrei dedurre che ho un problema fisico tipo cluster danneggiati
su un disco.
In realtà però basta fare il reboot e il readd e tutto torna come prima.
Ieri ho riaggiunto i dischi all'array vediamo per quanto dura.
Saluti
Carlo
Carlo
I Tentativi fatti per risolvere sono:
1)Reboot tutte le notti:
effettivamente con questo sistema il disco non si stacca completamente
dal sistema
diventando inaccessibile, cosa che succede se non riavvio.
l'array si corrompe ma posso riaggiungerlo avendo il disco accessibile
2)Hdparm:
Ho lavorato un po con hdpar per bloccare ogni modalità di risparmio
energetico e
controllo rumorosità.
Avevo per l'appunto letto in giro per forum proprio questo problema e
dicevano di cambiare
le impostazioni acpi del bios.
Peccato che la mia macchina nel bios non abbia le impostazioni acpi.
3)Cavi:
Ho cambiato sia i cavi sata che i cavi d'alimentazione sata.
(chi ha inventato i cavi sata poteva creare un attacco un po più solido)
Attualmente il problema permane gli array continuano a rompersi ogni 1/2
giorni
partendo dagli array più grossi. (non è possibile lavorare in queste
condizioni)
mi rimangono poche soluzioni.
o mi faccio uno script che mi riadda ogni 30 min tutti gli array
eventualmente rotti
o provo a cambiare i dischi (anche se credo che sia inutile)
voi avete altre idee?
i log sono quelli che ho scritto
qui sotto riporto cosa avevamo già detto.
Grazie Anticipatamente per ogni eventuale ulteriore risposta
Carlo ha scritto:
Carlo
Carlo ha scritto:
> Ho questo strano problema su un server (nuovo dell t105) debian lenny
>>>
>>> L'errore è abbastanza frequente (3 volte a settimana) e i miei
>>> array delle partizioni saltano e da completamente sincronizzati
>>> passano a uno stato tipo questo:
>>>
>>> Personalities : [raid1] md6 : active raid1 sda10[0] sdb10[1]
>>> 393472 blocks [2/2] [UU]
>>> md5 : active raid1 sda8[0] sdb8[1]
>>> 9767424 blocks [2/2] [UU]
>>> md4 : active raid1 sda7[2](F) sdb7[1]
>>> 9767424 blocks [2/1] [_U]
>>> md3 : active raid1 sda6[0]
>>> 29294400 blocks [2/1] [U_]
>>> md2 : active raid1 sda5[2](F) sdb5[1]
>>> 68356416 blocks [2/1] [_U]
>>> md1 : active raid1 sda2[2](F) sdb2[1]
>>> 5855616 blocks [2/1] [_U]
>>> md0 : active raid1 sda1[0] sdb1[1]
>>> 586240 blocks [2/2] [UU]
>>>
degli array software che si desicronizzavano di continuo.
La questione sta tutto nel SATA2 vs SATA1
Sostanzialmente nei log oltre a diversi altri errori
mi diceva qualcosa riguardo al link del disco che veniva resettato.
Bene tutto il problema sta qui per l'appunto. Il mio kernel non è
compatibile con
il sata 2 anche se l'ultimo stable aggiornato a disposizione.
Io avevo dei dischi Western digital RE che forzatamente sono SATA2
Sostituendoli con altri dischi (MAXTOR) che hanno il jumperino per
bloccarli a SATA1
il problema si è risolto magicamente e gli array dei dischi non si
rompono da diversi mesi.
Saluti
C.