Vinyó timoutolgatás == halál?

Linux-haladó

Helló!

A lentebbi logokból látszik, hogy az egyik vinyó elkezdett rendetlenkedni egy amúgy pöpec desktop intel alaplapon, és se ping se semmire nem válaszolt a gép, resetelni kellett a szervertermes kollégával (ip konzol foglalt volt, bah). Totál megfeküldt az egész linux, nem is értem. Ráadásul ez a vinyó nem is magát a linuxot, csak egy postgres adatbázis bizonyos tábláit és a pxlogot vitte, tehát más processek nem is kellett volna, hogy meghaljanak.

A kérdésem végülis az lenne, hogy softraidben volt a vinyó egy másikkal. Mit konfigoljak máshogy, hogy ez legközelebb a raidből való kiesést váltsa ki, ne pedig a rendszer megfektetését?

Köszi előre is az ötleteket!

  • 1592 megtekintés

( szundi | 2008. 08. 27., sze – 10:52 )

Linux nova 2.6.23.9 #2 SMP Fri Nov 30 18:13:23 CET 2007 x86_64 GNU/Linux
Ubuntu gutsyról van szó amúgy.

( szundi | 2008. 08. 27., sze – 10:53 )

A log pedig:

Aug 27 09:46:33 nova kernel: [4366350.305447] res 40/00:e8:57:7f:47/00:00:01:00:00/40 Emask 0x4 (timeout)
Aug 27 09:46:33 nova kernel: [4366350.305526] res 40/00:e8:57:7f:47/00:00:01:00:00/40 Emask 0x4 (timeout)
Aug 27 09:46:33 nova kernel: [4366350.305605] res 40/00:e8:57:7f:47/00:00:01:00:00/40 Emask 0x4 (timeout)
Aug 27 09:46:33 nova kernel: [4366350.305684] res 40/00:e8:57:7f:47/00:00:01:00:00/40 Emask 0x4 (timeout)
Aug 27 09:46:33 nova kernel: [4366350.305764] res 40/00:e8:57:7f:47/00:00:01:00:00/40 Emask 0x4 (timeout)
Aug 27 09:46:33 nova kernel: [4366350.305843] res 40/00:e8:57:7f:47/00:00:01:00:00/40 Emask 0x4 (timeout)
Aug 27 09:46:33 nova kernel: [4366350.305922] res 40/00:e8:57:7f:47/00:00:01:00:00/40 Emask 0x4 (timeout)
Aug 27 09:46:33 nova kernel: [4366350.306001] res 40/00:e8:57:7f:47/00:00:01:00:00/40 Emask 0x4 (timeout)
Aug 27 09:46:33 nova kernel: [4366350.306080] res 40/00:e8:57:7f:47/00:00:01:00:00/40 Emask 0x4 (timeout)
Aug 27 09:46:33 nova kernel: [4366350.306159] res 40/00:e8:57:7f:47/00:00:01:00:00/40 Emask 0x4 (timeout)
Aug 27 09:46:33 nova kernel: [4366350.306239] res 40/00:e8:57:7f:47/00:00:01:00:00/40 Emask 0x4 (timeout)
Aug 27 09:46:33 nova kernel: [4366350.306318] res 40/00:e8:57:7f:47/00:00:01:00:00/40 Emask 0x4 (timeout)
Aug 27 09:46:33 nova kernel: [4366350.306397] res 40/00:e8:57:7f:47/00:00:01:00:00/40 Emask 0x4 (timeout)
Aug 27 09:46:33 nova kernel: [4366350.306476] res 40/00:e8:57:7f:47/00:00:01:00:00/40 Emask 0x4 (timeout)
Aug 27 09:46:33 nova kernel: [4366350.306555] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Aug 27 09:46:33 nova kernel: [4366350.635741] ata3: soft resetting port
Aug 27 09:46:39 nova kernel: [4366355.868143] ata3: port is slow to respond, please be patient (Status 0xc0)
Aug 27 09:46:42 nova kernel: [4366359.291423] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Aug 27 09:46:42 nova kernel: [4366359.295989] ata3.00: configured for UDMA/133
Aug 27 09:46:42 nova kernel: [4366359.296028] sd 2:0:0:0: [sdc] Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT,SUGGEST_OK
Aug 27 09:46:42 nova kernel: [4366359.296034] end_request: I/O error, dev sdc, sector 19154167
Aug 27 09:46:42 nova kernel: [4366359.296123] ata3: EH complete
Aug 27 09:46:42 nova kernel: [4366359.297177] sd 2:0:0:0: [sdc] 293046768 512-byte hardware sectors (150040 MB)
Aug 27 09:46:42 nova kernel: [4366359.303955] sd 2:0:0:0: [sdc] Write Protect is off
Aug 27 09:46:42 nova kernel: [4366359.304137] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Aug 27 09:51:44 nova kernel: [4366660.382602] res 40/00:58:ff:80:de/18:00:08:00:00/40 Emask 0x4 (timeout)
Aug 27 09:51:44 nova kernel: [4366660.713501] ata3: soft resetting port
Aug 27 09:51:44 nova kernel: [4366660.893946] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Aug 27 09:51:44 nova kernel: [4366660.898595] ata3.00: configured for UDMA/133
Aug 27 09:51:44 nova kernel: [4366660.898611] ata3: EH complete
Aug 27 09:51:44 nova kernel: [4366660.898661] sd 2:0:0:0: [sdc] 293046768 512-byte hardware sectors (150040 MB)
Aug 27 09:51:44 nova kernel: [4366660.898680] sd 2:0:0:0: [sdc] Write Protect is off
Aug 27 09:51:44 nova kernel: [4366660.898709] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Aug 27 09:52:24 nova kernel: [4366700.753191] res 41/40:10:8d:70:19/18:00:09:00:00/40 Emask 0x409 (media error)
Aug 27 09:52:24 nova kernel: [4366700.757595] ata3.00: configured for UDMA/133
Aug 27 09:52:24 nova kernel: [4366700.757633] ata3: EH complete
Aug 27 09:52:24 nova kernel: [4366700.757744] sd 2:0:0:0: [sdc] 293046768 512-byte hardware sectors (150040 MB)
Aug 27 09:52:24 nova kernel: [4366700.757768] sd 2:0:0:0: [sdc] Write Protect is off
Aug 27 09:52:24 nova kernel: [4366700.757813] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Aug 27 09:52:27 nova kernel: [4366703.749308] res 41/40:10:8d:70:19/18:00:09:00:00/40 Emask 0x409 (media error)
Aug 27 09:52:27 nova kernel: [4366703.753659] ata3.00: configured for UDMA/133
Aug 27 09:52:27 nova kernel: [4366703.753673] ata3: EH complete
Aug 27 09:52:27 nova kernel: [4366703.753716] sd 2:0:0:0: [sdc] 293046768 512-byte hardware sectors (150040 MB)
Aug 27 09:52:27 nova kernel: [4366703.753734] sd 2:0:0:0: [sdc] Write Protect is off
Aug 27 09:52:27 nova kernel: [4366703.753763] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Aug 27 09:52:30 nova kernel: [4366706.745256] res 41/40:10:8d:70:19/18:00:09:00:00/40 Emask 0x409 (media error)
Aug 27 09:52:30 nova kernel: [4366706.749660] ata3.00: configured for UDMA/133
Aug 27 09:52:30 nova kernel: [4366706.749671] ata3: EH complete
Aug 27 09:52:30 nova kernel: [4366706.749712] sd 2:0:0:0: [sdc] 293046768 512-byte hardware sectors (150040 MB)
Aug 27 09:52:30 nova kernel: [4366706.749730] sd 2:0:0:0: [sdc] Write Protect is off
Aug 27 09:52:30 nova kernel: [4366706.749758] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Aug 27 09:52:33 nova kernel: [4366709.541585] res 41/40:10:8c:70:19/18:00:09:00:00/40 Emask 0x409 (media error)
Aug 27 09:52:33 nova kernel: [4366709.546132] ata3.00: configured for UDMA/133
Aug 27 09:52:33 nova kernel: [4366709.546162] ata3: EH complete
Aug 27 09:52:33 nova kernel: [4366709.546241] sd 2:0:0:0: [sdc] 293046768 512-byte hardware sectors (150040 MB)
Aug 27 09:52:33 nova kernel: [4366709.546267] sd 2:0:0:0: [sdc] Write Protect is off
Aug 27 09:52:33 nova kernel: [4366709.546294] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Aug 27 09:52:36 nova kernel: [4366712.387800] res 41/40:10:8d:70:19/18:00:09:00:00/40 Emask 0x409 (media error)
Aug 27 09:52:36 nova kernel: [4366712.392236] ata3.00: configured for UDMA/133
Aug 27 09:52:36 nova kernel: [4366712.392249] ata3: EH complete
Aug 27 09:52:36 nova kernel: [4366712.392311] sd 2:0:0:0: [sdc] 293046768 512-byte hardware sectors (150040 MB)
Aug 27 09:52:36 nova kernel: [4366712.392336] sd 2:0:0:0: [sdc] Write Protect is off
Aug 27 09:52:36 nova kernel: [4366712.392379] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Aug 27 09:52:40 nova kernel: [4366716.332572] res 41/40:10:8d:70:19/18:00:09:00:00/40 Emask 0x409 (media error)
Aug 27 09:52:40 nova kernel: [4366716.336953] ata3.00: configured for UDMA/133
Aug 27 09:52:40 nova kernel: [4366716.336978] ata3: EH complete

( iwanabeguru | 2008. 08. 27., sze – 13:06 )

Aham es mien raidben volt?
raidlevel?

( Skuzzy | 2008. 08. 28., cs – 10:17 )

Softraidnel ez nem ritka, az adataid megmaradnak a jo vinyon, de a beszart vinyo timeoutjai adnak egy satut a rendszernek. En is kivancsi lennek, lehet-e ez konfigolni valahogy, hogy pl x probalkozas utan felejtse el azt a vinyot, es vegye ki a tombbol.

No, PONT AZ a problémám, hogy NEM vette ki. Látható a fenti logból is, hogy egyszerűen csak szenvedett vele, küzdött a /dev/sdc device-ért! Mesterséges lélegeztetés, minden volt itt.

Ám közben a rendszer nem válaszolt a pingre, nem csinált semmit, stb, totál elérhetetlen volt, tehát ahogy fentebb a kolléga írta, kapott egy satut.

És ez szerintem elfogadhatatlan!! Adatmentésre szerintem ott a backup, a raid inkább rendelkezésre állást hivatott szolgálni (no flame plz), NEKEM ez a fő mozgatórugója a használatának. Azért kényelmes, hogy csak minden 5. esetben kell a backup persze :)

Szóval kedves uraim, hogyan éritek el ti, hogy ilyenkor kivegye a raidből, legyen faulty stb. Ez szerintem így elég gáz. Persze lehet, hogy ez csak egy ilyen desktop üzemmódú dolog, és a szerver kernel /dev/sdc driverét úgy kéne konfigolni, hogy adja fel 20 másodperc alatt, vagy valami.

Valami hasonlon gondolkodok eppen en is. Ami fontos lehet, hogy kernel panic-kal hal meg a rendszer, vagy "egyszeruen" megfagy?
Ha kernel panic van, akkor a sysrq-n keresztul ujraindithato a gep. Ezt meglovagolva gondolkodok valami olyasmin, hogy akkor egy script gyorsan nezzen szet, hogy mi az, ami meghalt, azt szedje ki az adott tombbol, aztan anelkul inditsa ujra magat. Vagy valami hasonlo...

Szerk.: Ja, azert nem artana, ha kuldene egy uzenetet, hogy "Baj van, Teso!" De ez mar finomitgatas kerdese.

---
Egy jol feltett kerdes mar egy fel valasz...

Tudtam, hogy valaki bele fog kotni a dologba. A valaszom igen, szeretnek script-et futtatni kernel panic utan. Ha mashogy nem is, akkor ujraindulas utan azonnal. Ha masnem ugy, hogy reboot elott nyomatok egy core dump-ot. http://www.missioncriticallinux.com/projects/mcore/readme.php

De mivel emlitettem, hogy ez csak egy elkepzeles, igy ha sokan mondjak, akkor elhiszem, hogy lehetetlen. De addig nem adom fel.

---
Egy jol feltett kerdes mar egy fel valasz...

( dap | 2008. 09. 01., h – 23:02 )

Régen azt hittem, hogy a software raid megfelelő chipekkel és sata driverekkel fölöslegessé teszi a hardveres raid -et, amíg 2-3 év tapasztalás és kutatás után be kellett lassam: tévedtem, A stabilitás a hardveres raidnél kezdődik.

A probléma ott van, hogy az olcsó sata chip -eket nem tesztelik ki különböző winyóhibákkal, lehetséges olyan szituáció amikor a sata chip megkukul, a driver pedig vár a válaszára ami soha nem jön meg. Ebből az állapotból csak egy NMI hozhatja ki, de akkor már régen rossz nekünk. Lehet, hogy a rendszer még hagy egy panic üzenetet 10mp -vel a sata chip "fagyása" után, de legtöbbször valamiért még azt sem sikerul neki.

Sajnos ez nem konfiguráció kérdése, hanem főleg a hardveré.

( szundi | 2008. 09. 07., v – 01:24 )

Up

Továbbgondoltam a dolgot, és a következő pár zavar ebben a problémában:

Nem tudom, mi működött rosszul. A linux? A sata vezérlő? A vinyó? Kinek a felelőssége eldönteni egy ilyen helyzetben, hogy a vinyó rossz? :)

Emlékeztetésképp: a vinyó valamit csinált, sok ideig nem válaszolt, majd a linux soft resetelte a sata portot, amit a drive talán korrektül kezelt is, feléledt. Gondolom ekkor megkapta ugyanazt a parancsot, majd megint nem válaszolt, és így tovább. Mindeközben a szerver teljes halálban vala, nincs válasz még pingre se...

Itthon szimuláltam az esetet a vinyóval, és a raid tömbből ilyenkor 1 mp-re kiesik, majd amikor visszatér softreset után az életbe a vinyó, magától visszakerül. Na pl. szerintem ez nem korrekt talán, nem tudom, mi a véleményetek.

A TLER egy jó ötlet, azt is ki fogom próbálni, ha tudom, sajnos közben 1x véletlenül a tesztek során fordítva resynceltem a vinyókat és eltűnt a crc erroros rész, most minden smart self-test sikeresen lefut... hogy lehet így teszelni ilyesmit? :) Mindenesetre a beállításokat hétfőn megnézem a dosos progival, aztán írok, hogy mi lett.

Nem tudom, ti hogy vagytok vele, de ilyen softraid megoldás mellett elég nehéz aludni... :) Akárkinek akármelyik vinyója csinálhat ilyet. Nincs valaki, akinek crc-s lett a vinyója? Nem emlékszik, neki akkor mi történt? Mert lehet, hogy a chipset reagálta le rosszul.

Valaki írta, hogy a jó megoldás a hw raidnél kezdődik, de akárhogy gondolkodom rajta, azon a kártyán is meghibásodhat a ram stb, és azon fut egy szoftver (firmware)! Tehát elvileg azt "lemásolva" ugyanazt a megoldást megkaphatom szoftveresen, nem? Ami esetleg hibádzik, az az akksi, amit pl. a 3ware kártyákra lehet rakni, és megmenti a még nem leírt műveleteket :) Egyszóval szerintem softraid is lehet(ne) jó, ha ezeket a problémákat lehetne orvosolni.