kernel: errore di I / O di commit del journal


9

Sto riscontrando alcuni problemi con un server Dell 1950. Sto installando RHEL 4.6 insieme a Oracle e altri software qui.

Ricevo casualmente un messaggio di errore che diceva "kernel: errore di I / O di commit del journal" sulla mia sessione ssh e sul monitor Ho collegato al server vedo scorrere un errore che dice "Errore EXT3-fs (dispositivo sda5) in start_transaction: il diario è stato interrotto. "

È successo più volte ma mai allo stesso punto durante l'installazione. In realtà, quest'ultima volta il sistema era attivo e funzionante e stavo solo cercando di importare un database in Oracle.

Questo è successo su diversi dischi rigidi, quindi sono abbastanza sicuro che non sia questo il problema. Questo mi fa pensare che il controller raid stia andando male.

Che cosa ne pensate?

** AGGIORNARE **

Abbastanza sicuro che fosse un disco rigido difettoso. Ho gettato un'altra unità nel server ed è stato in esecuzione per circa 48 ore senza problemi.

Risposte:


9

Ho visto quegli errori prima, ma non durante il processo di installazione.

Significa che l'unità ha avuto abbastanza errori che il sistema operativo ha portato in modalità di sola lettura. Se riuscissi a trovare i registri completi, probabilmente ci sarebbero alcuni errori I / O che hanno riprovato e funzionato prima degli errori di errore completi che hai visto. Qualcosa con blocchi reali menzionati.

È un errore del sistema di archiviazione. È sicuramente la scheda RAID, le unità nell'array RAID, i cavi dalla scheda alle unità, il backplane a cui si collegano le unità, lo slot a cui è collegata la scheda raid, l'alimentatore per i dischi rigidi o qualcos'altro in tra la CPU e i blocchi di memoria effettivi.


2

Mi vengono in mente tre possibilità:

  1. Ci sono problemi di memoria (spesso causano arresti anomali "casuali"). Se hai RAM ECC lì dentro, ovviamente è meno probabile.

  2. C'è qualche problema con il bus. Qualche anno fa ho avuto lo stesso problema con un controller APIC rotto su una scheda madre dual Opteron Tyan. C'erano altre voci di registro che lo suggerivano, ma la maggior parte dei sintomi era corruzione casuale su unità disco con rimontaggi automatici di sola lettura. Nel mio caso sapevo che non era legato al disco perché era un box RAID FC esterno ed andava bene.

  3. Il controller RAID è a castello.

Questo è nell'ordine in cui prenderei in considerazione i problemi.


Probabilmente non problemi di memoria; quelli avrebbero maggiori probabilità di causare segfault e errori più casuali, non limitati alla sola memorizzazione.
Freiheit,

Vero. Ma in una situazione di installazione o avvio anticipato, la maggior parte dell'utilizzo della memoria è la cache del buffer, quindi i problemi tendono ad apparire prima lì. Una volta che la macchina ha eseguito un certo carico per un po 'il processo dell'utente domina l'I / O di memoria e quindi la prevalenza del segfault. Detto questo, un PE1950 dovrebbe avere processori Xeon e RAM ECC, quindi la RAM dovrebbe essere in grado di rilevarlo e segnalarlo a Linux.
Alexandre Carmel-Veilleux,

2

Potrebbe essere il controller RAID che va male come hai detto (prova uno di riserva se ne hai uno.) Potrebbe essere il driver per il controller (controlla se sono disponibili driver alternativi, anche se le prestazioni sono peggiori, è bene avere un punto di riferimento .) Potrebbe essere il kernel (meno probabile anche se in RHEL, è abbastanza ben testato.) Potrebbe essere una cattiva RAM che rovina la cache dei blocchi.

Un problema hardware è la causa più probabile, tuttavia, basata sul comportamento apparentemente casuale dell'errore.


2

Verifica che il disco non sia pieno, in particolare la partizione di root. Utilizzare df per visualizzare l'utilizzo del disco del file system:

df -h

Cerca partizioni vicine o uguali al 100% di utilizzo


-5

provare:

spegnimento -rF ora

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.