SCSI-disk crasht op gezet moment

[deepbass909]

Ik heb een hobbie server, met een IBM ServeRAID controller erin. Aan deze controller hangen meerdere harddisks in verschillende RAID-configs.
Er hangt er echter 1tje alleen. Deze schijf gebruik ik als /home/tmp onder mijn Linux, en er draaien wat minder belangrijke programma's op.
Nu is het vage dat de hele server stabiel is, totdat ik eDonkeyclc start. Dat gaat een uur of 12 goed, en dan crasht die ene schijf (waar eDonkeyclc vanaf draait, en hij zijn bestanden op opslaat).

Het betreft een Quantum Atlas V schrijf van 8.4GB op SCSI-u2w

Ik raak er een beetje van gefrustreerd, want het crashen van deze schijf maakt dat ik mijn server steeds opnieuw moet opstarten om de schijf weer gemount te krijgen...

Wat ik mij vooral afvraag, is of dit een hardware of software probleem betreft? Het vage is namelijk dat hij zonder eDonkeyclc wel blijft werken...

[Laurent]

Staat er niks over dit gebeuren in de logs, b.v. als je 'dmesg' runt zodra de disk ophoudt? Vaak staat hier wel wat informatie over crashende hardware in, zo kan je vaak ook achterhalen of het echt een hardwarefout is.

[Verwijderd]

Misschien eens even die software proberen op een andere schijf? Poortjes wissellen e.d. wil ook wel eens helpen.

[deepbass909]

Poortjes wisselen kan ik niet zomaar, aangezien het een Hot-swap systeem is, waarbij de bay posities aangeven welke config erbij hoort. Dus als ik schijven ga wisselen ben ik:
1. data kwijt van deze schijf
2. loop ik het risico andere raid-sets te beschadigen.

ik heb even dmesg gedraait, en krijg daar bijzonder veel scsi fouten:

code:

SCSI disk error : host 1 channel 0 id 3 lun 0 return code = 70000
 I/O error: dev 08:31, sector 7868416

Alleen zeggen deze weinig meer dan dat deze schijf niet meer benaderbaar is (Wat klopt, want de controller heeft hem uitgeschakeld...)

Helaas heb ik van de controller zelf weinig meer dan een log van de beheersoftware, waarin geen hardwarefouten worden opgeslagen.

[gwreijman]

deepbass909 schreef op dinsdag 15 maart 2005 @ 17:31:
Poortjes wisselen kan ik niet zomaar, aangezien het een Hot-swap systeem is, waarbij de bay posities aangeven welke config erbij hoort. Dus als ik schijven ga wisselen ben ik:
1. data kwijt van deze schijf
2. loop ik het risico andere raid-sets te beschadigen.

ik heb even dmesg gedraait, en krijg daar bijzonder veel scsi fouten:

code:

SCSI disk error : host 1 channel 0 id 3 lun 0 return code = 70000
 I/O error: dev 08:31, sector 7868416

Alleen zeggen deze weinig meer dan dat deze schijf niet meer benaderbaar is (Wat klopt, want de controller heeft hem uitgeschakeld...)

Helaas heb ik van de controller zelf weinig meer dan een log van de beheersoftware, waarin geen hardwarefouten worden opgeslagen.

Misschien is de harddisk aan het overlijden?

[deepbass909]

Je zou dan verwachten dat die schijf altijd na een bepaalde tijd uitvalt, en niet bij het draaien van een bepaald programma...
Ik heb hem nog niet goed kunnen testen, maar hoop het eigenlijk niet dat deze schijf aan het overlijden is... heb op het moment niet echt geld om een scsi schijf te vervangen, want die dingen blijven helaas erg duur...

[twiekert]

Kan je de schijf niet verifyen in de bios van de raid kaart?

Ik zou als dat niet helpt de nieuwste kernel en/of module voor die ibm kaart installeren. Daarna de nieuwste firmware voor de raidkaart, wel ff de readme/changelog lezen over wat er gebeurt met bestaande logical drives en config (soms zijn deze incompatible van oude > nieuwe firmware en moet je de logical drives opnieuw aanmaken).

Let wel op bij het installeren van een nieuwe module, sommige modules werken niet met alle firmwares waardoor je verplicht moet upgraden.

[deepbass909]

Kernel versie zal echt het probleem niet zijn (de kaart is inmiddels een jaar of 7 oud, en wordt al standaard ondersteund vanaf kernel 2.2 minimaal).
Verder heeft de kaart al de nieuwste firmware, moet ik alleen de driver nog upgraden, maar dat moest ik ook allang voordat ik problemen begon te krijgen. Dus ook daar lijkt mij niet direct het probleem liggen. Maar gelukkig kan ik de software zonder problemen upgraden, zonder dat ik gelijk mijn logical drives kwijt ben.

Wat betreft het test van de schijf, de standaard SCSI tests die ik kan uitvoeren, geven allemaal een goed resultaat. Er is 1 test die rigoreuzer is, alleen vernietigd die mijn data, en aangezien er nog data opstaat, is dat op het moment dus niet mogelijk.

[twiekert]

En als je de schijf helemaal volgooit met een test bestand? bijvoorbeeld cp /dev/zero /home/tmp/testfile?

[deepbass909]

ik ga dat vrijdag proberen (eerst maar even een paper over klimaatsverandering en een tentamen internationaal milieubeleid maken...)

[deepbass909]

Ik heb een testfile geschreven, die inmiddels 8.2GB groot is... (schijf is nu dus tot 't nokkie gevult), maar draait nog steeds...
Maar wat duurt het genereren van 8Gieg aan lege data lang... vooral als je realiseerd dat het dus ook echt niks is

Ik ga hem nog een keer draaien. Misschien dat ik eens een scripje moet schrijven die automatisch steeds het bestand schrijft en verwijderd... zodat ik hem wat langer kan testen.

[twiekert]

dan lijkt mij hardware problemen uitgesloten. Edonkey zal verschillende files open houden om te schrijven. mischien dat dat i.c.m. met een slechte driver voor de scsi kaart ervoor zorgt dat er niets meer naar de hdd geschreven kan worden.

dit is toch ergens een softwarebug, er hebben meer mensen last van:
http://www.google.nl/sear...return+code+%3D+70000&lr=

[deepbass909]

Ik heb google ff doorgekeken, maar kwam daar eigenlijk alleen het probleem tegen, en geen oplossing... helaas...
Wat betreft driver en bios, deze zijn beide 7.00.14

code:

IBM ServeRAID General Information:

        Controller Type                   : ServeRAID
        IO region                         : 0x9000 (256 bytes)
        Memory region                     : 0x40000000 (8192 bytes)
        Shared memory address             : 0xcc862000
        IRQ number                        : 9
        BIOS Version                      : 7.00.14
        Firmware Version                  : 2.25.01
        Boot Block Version                :  96304
        Driver Version                    : 7.00.14
        Driver Build                      : 624
        Max Physical Devices              : 45
        Max Active Commands               : 32
        Current Queued Commands           : 0
        Current Active Commands           : 0
        Current Queued PT Commands        : 0
        Current Active PT Commands        : 0

Hier zal geen conflict zitten. Dit zijn overigens ook de nieuwste versies die nog werken op mijn kaart (bezit een ServeRAID 1 controller, en de support is daar inmiddels voor gestopt).
Ik zal later nog eens proberen om een kernel te bouwen voor deze machine op basis van de 2.6 kernel, maar om de één of andere reden wil het mij voor deze machine maar niet lukken (wel voor 3 andere pc's, die gaan zonder problemen... maar deze loopt telkens stuk op de Raid controller).

Afin, genoeg om te testen dus...

[twiekert]

deze user heeft deze problemen gekregen sinds een update naar de kernel 2.4.20
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=104707

Je zou ook nog een oudere kernel kunnen proberen en als het daar wel goed werkt dan ligt het of aan de module (maar of daar nog veel aan gesleuteld is na 7 jaar ondersteuning) of aan de generic scsi support die ergens incompatible is.

[deepbass909]

DIt is een nieuw advies voor mij, een oudere kernel testen
Ik zal daar eerdaags eens tijd aan besteden. Het bouwen en testen van een nieuwe kernel op deze machine is zacht gezegt namelijk een uitdaging.

Wat de driver betreft, die wordt nog steeds door ontwikkeld (IBM heeft nog steeds ServerRAID SCSI controllers), maar is vanaf versie 7.1 (de laatste) ondersteuning voor de ServeRAID 1 komen te vervallen. Terug naar een oudere versie kan ik niet, want het is niet mogelijk de BIOS te voorzien van een oudere versie, en driver en BIOS versie moeten gelijk zijn.

[deepbass909]

Jeej, het probleem is opgelost!!
Wat nou precies de oorzaak was weet ik niet, maar ik heb 2 dingen veranderd.
Ten eerste heb ik de SCSI kaart verplaatst naar het pci-slot het dichtst bij de CPU kaart en chip set, zodat de afstand tussen die zo klein mogelijk geworden is.
Ten tweede heb ik de SCSI array aan een andere controller van de kaart gehangen. Al mijn schijven zaten eerst op kanaal 2, en nu op kanaal 1.

Mijn schijf is nog niet weer gecrasht, de server is stabieler en sneller. Dus 1 van die 2 dingen was de bron, welke weet ik niet precies, maar het werkt!!

[JHMvP]

Te laat maar toch...
Die IBM ServeRaid kaarten hebben eigen-aardigheden; ze werken perfect maar je moet er wat ervaring mee hebben Zeker op moederborden waarbij een bepaald PCI-slot (meeestal nr.1) een hogere prioriteit krijgt dan de andere PCI -sloten, moet je deze kaart daarin stoppen. Per definitie zou ik dat ALTIJD doen maar ServeRaid is daarin wat kritischer... Ik zou dan ook zeggen dat het hieraan heeft gelegen.

Een array alleen aan bus2 hangen is natuurlijk ook niet echt netjes maar ik heb zelf een tweetal IBM servertjes gehad die op die manier 6 jaren onafgebroken (op een handjevol reboots na!) hebben gedraaid.

[deepbass909]

Het enige wat ik nu nog zoek zijn goede handleidingen van de ServeRAID 1 kaart en de IBM PC server 330 Dual Pentium Pro. Er zijn namelijk nogal wat aansluitingen intern (zowel op het moederbord, als de ServeRAID kaart en de backplane van de Hot-swap bay) waarvan ik totaal geen idee heb wat ze doen, en hoe ze o.a. gebruikt kunnen worden (te denken valt aan een connector als System managment...)

Ik zal daar eerdaags wel even een nieuw topic over openen. Deze draad is wat mij betreft afgesloten.