Adaptec I2O RAID controller gond?!

Linux-haladó

Sziasztok,

Adott egy Kubuntu Feisty linux, 2.6.18-as kernellel. A gépben található 2 db I2O kártya. Adaptec 2100S és 2400A. Raidutil kimenet lentebb:

RAIDUTIL Version: 3.31 Date: 8/12/2002 LINUX CLI Configuration Utility
Adaptec ENGINE Version: 3.31 Date: 8/12/2002 Adaptec LINUX SCSI Engine

# b0 b1 b2 Controller Cache FW NVRAM Serial Status
---------------------------------------------------------------------------
d0 -- -- -- ADAP2400A 48MB 3A0L ADPT 1.0 BF0F33803GKOptimal
d1 -- ADAP2100S 48MB 330H CHNL 1.1 EA0B10210PPOptimal

Physical View
Address Type Manufacturer/Model Capacity Status
---------------------------------------------------------------------------
d0b0t0d0 Disk Drive (DASD) SAMSUNG HD400LD 381554MB Optimal
d0b1t0d0 Disk Drive (DASD) SAMSUNG HD400LD 381554MB Optimal
d0b2t0d0 Disk Drive (DASD) SAMSUNG HD400LD 381554MB Optimal
d0b3t0d0 Disk Drive (DASD) SAMSUNG HD400LD 381554MB Optimal
d1b0t0d0 Disk Drive (DASD) IBM IC35L018UWD210-0 17501MB Optimal

Logical View
Address Type Manufacturer/Model Capacity Status
---------------------------------------------------------------------------
d0b0t0d0 RAID 5 (Redundant ADAPTEC RAID-5 1144662MB Optimal
d0b0t0d0 Disk Drive (DASD) SAMSUNG HD400LD 381554MB Optimal
d0b1t0d0 Disk Drive (DASD) SAMSUNG HD400LD 381554MB Optimal
d0b2t0d0 Disk Drive (DASD) SAMSUNG HD400LD 381554MB Optimal
d0b3t0d0 Disk Drive (DASD) SAMSUNG HD400LD 381554MB Optimal

Address Max Speed Actual Rate / Width
---------------------------------------------------------------------------
d0b0t0d0 50 MHz 100 MB/sec wide
d0b1t0d0 50 MHz 100 MB/sec wide
d0b2t0d0 50 MHz 100 MB/sec wide
d0b3t0d0 50 MHz 100 MB/sec wide
d1b0t0d0 Ultra3 160 MB/sec wide

Address Manufacturer/Model Write Cache Mode
---------------------------------------------------------------------------
d1b0t0d0 IBM IC35L018UWD210-0 Write Back
d0b0t0d0 ADAPTEC RAID-5 Write Back
d0b0t0d0 SAMSUNG HD400LD Write Back
d0b1t0d0 SAMSUNG HD400LD Write Back
d0b2t0d0 SAMSUNG HD400LD Write Back
d0b3t0d0 SAMSUNG HD400LD Write Back

# Controller Cache FW NVRAM BIOS SMOR Serial
---------------------------------------------------------------------------
d0 ADAP2400A 48MB 3A0L ADPT 1.0 BF0F33803GK
d1 ADAP2100S 48MB 330H CHNL 1.1 1.62 1.12/79I EA0B10210PP

# Controller Status Voltage Current Full Cap Rem Cap Rem Time
---------------------------------------------------------------------------
d0 ADAP2400A No battery
d1 ADAP2100S No battery

Address Manufacturer/Model FW Serial 123456789012
---------------------------------------------------------------------------
d0b0t0d0 SAMSUNG HD400LD WQ10 S0AXJ1GL933855 -X-XX--X-O--
d0b1t0d0 SAMSUNG HD400LD WQ10 S0PQJ1LP301787 -X-XX--X-O--
d0b2t0d0 SAMSUNG HD400LD WQ10 S0PQJ1LP301786 -X-XX--X-O--
d0b3t0d0 SAMSUNG HD400LD WQ10 S0PQJ1LP301788 -X-XX--X-O--
d1b0t0d0 IBM IC35L018UWD210-0 S5BS VLZA1548 -XXXX---XOX-

Eddig minden ment klasszul, de mai napon egy CDimage másolásakor mindig 12%-nál lefagy a teljes gép. Az alábbi hibaüzenetek előzik meg:

Jul 16 08:49:09 kubuntu kernel: [505655.022014] dpti0: Trying to Abort cmd=584779
Jul 16 08:49:09 kubuntu kernel: [505655.022387] dpti0: Abort cmd not supported
Jul 16 08:49:09 kubuntu kernel: [505655.022391] dpti0: Trying to Abort cmd=584780
Jul 16 08:49:09 kubuntu kernel: [505655.022688] dpti0: Abort cmd not supported
Jul 16 08:49:09 kubuntu kernel: [505655.022693] dpti0: Trying to reset device
Jul 16 08:49:09 kubuntu kernel: [505655.022981] dpti0: Device reset not supported
Jul 16 08:49:09 kubuntu kernel: [505655.022986] dpti0: Bus reset: SCSI Bus 0: tid: 11
Jul 16 08:49:09 kubuntu kernel: [505655.027244] dpti0: Bus reset success.
Jul 16 08:49:29 kubuntu kernel: [505675.022409] dpti0: Trying to Abort cmd=584779
Jul 16 08:49:29 kubuntu kernel: [505675.022790] dpti0: Abort cmd not supported
Jul 16 08:49:39 kubuntu kernel: [505685.018605] dpti0: Trying to Abort cmd=584780
Jul 16 08:49:39 kubuntu kernel: [505685.018979] dpti0: Abort cmd not supported
Jul 16 08:49:39 kubuntu kernel: [505685.018984] dpti0: Hba Reset: scsi id 0: tid: 11
Jul 16 08:49:39 kubuntu kernel: [505685.053972] dpti0: Quiesced.

A raidutil szerint a RAID5 és a diskek is Optimal állapotban vannak újrainditás után is.

Találkozott hasonló problémával más is? Ugy vettem észre a 2.6.18-as kernel volt a legideálisabb a 2.6.xxx szériából, de most tanácstalan vagyok mi lehet a gond. Esetleg a meleg?

Bármi hasznos segitséget, ötletet szivesen veszek

  • 1818 megtekintés

( bugos | 2007. 07. 17., k – 10:07 )

Sziasztok

Újabb fejlemény az ügyben. Töröltem a kérdéses ISO-t (mivel másolni, ftp-ni nem lehetett), majd másoltam oda jópár hasonló méretű ISO-t és azokat simán tudtam lemezre irni meg másolni. Persze még azért mindig nem vagyok túl nyugodt, megfelelő magyarázat hijján. Lehet csak a file körül volt valami gubanc?

Nem akarok vészmadárkodni, de szerintem ments le mindent, dobd ki a vezérlőket (a 2400A-t mindenképpen), és vegyél egy másikat (LSI Logic, 3Ware oké), vagy használj szoftveres RAID-et, mert az megbízhatóbb és gyorsabb. Már leírtam itt is, hogy nekem egyszer firmwarehiba miatt elszállt egy 2400A, vele együtt a teljes tömb, az összes adatnak lőttek rajta. :I

A történet a következő volt:

2400A, rajta 4x40 GB HDD. Ebből d0-d1-d2 RAID5 tömbben, d3 hot-spare. D0 meghibásodott a vezérlő szerint, ezért elkezdte d3-mal újraépíteni a tömböt. Majd szerinte d3 is hibás lett, ezért a tömböt degraded módba rakta, végül teljesen használhatatlannak nyilvánította.

Miután meggyőződtem róla, hogy semmit nem tudok visszaszedni az adatokból, leteszteltem a vinyókat. D0 valóban badblockos lett, d3-nak semmi baja sem volt, tehát az újraépítés simán végig kellett volna, hogy fusson. De ha nem, akkor sem kellett volna leállnia, mert a maradék 2 lemezzel a tömbnek ugye működőképesnek kellett volna maradnia.

2100S-sel nem volt ilyen horror-tapasztalatom, az csak zavaróan hülye. Egyik ügyfélnél évekkel ezelőtt ilyenen volt - többek között - egy RAID1 tömb, 2x18 GB lemezzel. Az egyik badblockos lett, csere, de már csak 36 GB-os lemezt lehetett kapni. Vettünk egyet, be a hot-swap fiókba a régi helyére, de a vezérlő semmiféle piszkálásra nem volt hajlandó újraépíteni a tömböt rajta, mert nem egyezett a méretük. Na, itt repült ki a gépből és áttértünk szoftveres RAID-re - legalább 2x olyan gyors lett az I/O tőle. :)))

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

( gdudas | 2008. 09. 24., sze – 09:45 )

Sziasztok!

Van egy Adaptec 2010S kártyám amin van 4 db Ultra 320-as SCSI disk RAID10-ben. Azt jelezte az egyik vinyóra, hogy "Failed", ezért kicseréltem az összes lemezt újakra, ami furcsaság azóta, hogy Muninban a CPU Usage-nál elkezdett nőni az IOwait, pedig a régi felállásnál nem volt ezzel kapcsolatban semmi kiugró érték a grafikonban.

Megnéztem egy másik rendszert amiben hasonló kártya van, és ott ki van kapcsolva a Write cache, itt pedig nincs, azt hogy régen ki/be volt nem tudom... Amennyire én tudtam a Write cache-el csak nyerhetek, mert gyorsabb lesz. Létezhet, hogy ez fogja meg, vagy valami más probléma lesz? Semmi máshoz nem nyúltam csak kicseréltem a vinyókat, megcsináltam a tömböket, és telepítettem.

Próbaképpen kikapcsolnám a write cachet menet közben, de valamiért csak a RAID0-ra tudtam:
d0b0t0d0 ADAPTEC RAID-10 Write Through
d0b0t0d0 ADAPTEC RAID-1 Write Back
d0b0t0d0 FUJITSU MAX3073NP Write Back
d0b0t1d0 FUJITSU MAX3073NP Write Back
d0b0t2d0 ADAPTEC RAID-1 Write Back
d0b0t2d0 FUJITSU MAX3073NP Write Back
d0b0t3d0 FUJITSU MAX3073NP Write Back

Van valakinek valami ötlete, hogy raidutil-al hogyan tudnám menet közben a többire is kikapcsolni? Egyébként a másik rendszer sebességben is lepipálja ezt, annak ellenére hogy ott RAID5-ben van 3 vinyó Write cache nélkül.

Valakinek valami ötlete? Köszi!