Vorige week had ik een server die opeens onverklaarbaar was gecrashed. In het datacenter bleek het een fatale hd error te zijn, en na een reboot was het opgelost (+ na wat MySQL reparaties die erdoor nodig waren). Google gaf niet bijster veel info (buiten mensen met hetzelfde probleem, zonder oplossing) en ook de webhost had het nog niet gezien.
Allemaal ok leek me, als het maar één keer voorvalt. Nu nog geen week later is het er echter opnieuw (nog niet bevestigd dat het dat is, maar ik kan het al wel raden).
De server is een al wat oudere 1U Supermicro server met P4SCi moederbord, 3Ghz P4, 2,5GB geheugen (niet-ECC) en twee nieuwe SATAII 80GB schijven (Maxtor Diamondmax 10, jumpers in SATA (I) modus).
Er staat CentOS 4.5 op, met de laatste nieuwe kernel en updates. De harde schijven draaien in softRAID 1 (hardware RAID met de onboard ondersteuning van het mobo faalde in combinatie met Linux). De server loads zitten altijd erg goed, en ik als het RAID1 is moet de processor toch geen pariteitsgegevens berekenen? Zou hij er dan toch onder door gaan omdat het softwarematig is en dat te veel vraagt op een drukke server?
De configuratie heeft nochtans zo met softRAID al meer dan een maand wél goed gedraaid onder ongeveer dezelfde belasting (ervoor was het zonder RAID). Anderzijds lijkt kernel 2.6.9-55 me misschien ook de boosdoener (om alles open te houden), want die is er nog maar vrij recent.
De error (eerste keer) die op het scherm kwam:
In /var/log/messages is niets te vinden ervan uiteraard (schijferror) en ook anderen soortgelijke errors staan er niet in. Ook is de softRAID nog in prima conditie volgens /proc/mdstat.
Via Google vond ik tal van mailinglist berichten en enkele forumberichten. Sommige zeggen er om de kernel te updaten, andere zeggen dat het aan een striktere nieuwe kernel ligt, ... Ook wordt gezegd met de combined_mode=libata parameter op te starten via de Grub menu.lst configuratie, maar daar wordt dan weer op gereageerd dat het probleem er ook niet door wordt opgelost.
Zelfs op de CentOS bugtracker staat een melding ervan, enkele reacties van mensen die het ook hebben, maar de bug report staat al even open. Ook onder andere distro's bestaat het probleem wel.
Allemaal ok leek me, als het maar één keer voorvalt. Nu nog geen week later is het er echter opnieuw (nog niet bevestigd dat het dat is, maar ik kan het al wel raden).
De server is een al wat oudere 1U Supermicro server met P4SCi moederbord, 3Ghz P4, 2,5GB geheugen (niet-ECC) en twee nieuwe SATAII 80GB schijven (Maxtor Diamondmax 10, jumpers in SATA (I) modus).
Er staat CentOS 4.5 op, met de laatste nieuwe kernel en updates. De harde schijven draaien in softRAID 1 (hardware RAID met de onboard ondersteuning van het mobo faalde in combinatie met Linux). De server loads zitten altijd erg goed, en ik als het RAID1 is moet de processor toch geen pariteitsgegevens berekenen? Zou hij er dan toch onder door gaan omdat het softwarematig is en dat te veel vraagt op een drukke server?
De configuratie heeft nochtans zo met softRAID al meer dan een maand wél goed gedraaid onder ongeveer dezelfde belasting (ervoor was het zonder RAID). Anderzijds lijkt kernel 2.6.9-55 me misschien ook de boosdoener (om alles open te houden), want die is er nog maar vrij recent.
De error (eerste keer) die op het scherm kwam:
code:
1
2
3
4
5
6
7
8
| CentOS release 4.5 (Final)
Kernel 2.6.9-55.ELsmp on an i686
<computernaam> login: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd ca/00:08:57:46:a2/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 out
res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2: port is slow to respond, please be patient (Status 0xd0)
ata2: port failed to respond (30 secs, Status 0xd0) |
In /var/log/messages is niets te vinden ervan uiteraard (schijferror) en ook anderen soortgelijke errors staan er niet in. Ook is de softRAID nog in prima conditie volgens /proc/mdstat.
Via Google vond ik tal van mailinglist berichten en enkele forumberichten. Sommige zeggen er om de kernel te updaten, andere zeggen dat het aan een striktere nieuwe kernel ligt, ... Ook wordt gezegd met de combined_mode=libata parameter op te starten via de Grub menu.lst configuratie, maar daar wordt dan weer op gereageerd dat het probleem er ook niet door wordt opgelost.
Zelfs op de CentOS bugtracker staat een melding ervan, enkele reacties van mensen die het ook hebben, maar de bug report staat al even open. Ook onder andere distro's bestaat het probleem wel.
[ Voor 8% gewijzigd door RS_Jelle op 19-06-2007 12:32 ]
/u/16790/dirkjan-got.JPG?f=community)
.
:strip_exif()/u/85127/Iron-Man-Avatar_small.gif?f=community){kind=avatar}