[Linux RAID]mdadm problemen met build

[EnnaN]

Goed, ik heb een vervelend probleem met mijn (software) raid onder linux (debian).
The facts:
* Server (duron 1300, k7s41gx asrock)
* Ik heb op een apart SATAkaartje (zit niet op het moederbord) twee 320 gig (WD) schijven hangen.(/dev/sd[ab])
* Daarop heb ik (per schijf) 1 linux raid partitie zitten (/dev/sd[ab]1).
* Deze had ik met mdadm als /dev/md0 draaien, (raid1 / mirrored).
* er staat een ext3 partitie op die /dev/md0 (en dus ook op de 2 /dev/sd schijven )

na een nieuwe installatie die vervelend genoeg nodig was om andere redenen, ging ik mijn raid weer builden. hiervoor gebruikte ik het volgende commando:

code:

mdadm --build -- verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1

Dit is to the best of my knowledge correct, en in ieder geval is dit de methode waar het de vorige keer prima mee ging. nu echter niet

code:

md: bind<sda1>
md: nonpersistent superblock ...
md: bind<sdb1>
md: nonpersistent superblock ...
md: raid1 personality registered as nr 3
raid1: raid set md0 active with 2 out of 2 mirrors
mdadm: array /dev/md0 built and started
md: syncing RAID array md0
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maxsimum available idle IO bandwith (but not more than 200000 KB/sec) for reconstruction
md: using 128k window, over a total of 312568642 blocks

so far so good. Nu gaat ie dus syncen. het enige wat ik zo niet kan plaatsten is de nonpersistent superblock melding. is dat iets om me zorgen over te maken?
elkeweg, na een poosje syncen:

code:

ata2: command 0x35 timeout, stat 0xd9 host_stat 0x61
scsi1: ERROR on channel 0, id 0, lun 0 , CDB: Write (10) 00 02 2e 46 bf 00 04 00 00
Current sdb: sense key Medium Error
Additional sense: Write Error - auto reallocation failed
end_request: I/O error, dev sdb, sector 36587199
ATA: Abnormal status 0xd9 on port 0xdc81dec7
ATA: Abnormal status 0xd9 on port 0xdc81dec7
ATA: Abnormal status 0xd9 on port 0xdc81dec7

De /proc/mdstat laat daarna duidelijk zien dat er niets meer gebeurd. (tijd gaat alleen maar omhoog, snelheid naar beneden en hij komt niet verder dan het aantal blocks waar de fout optreedt).

tries:
* reboot, nog een keer proberen. hij blijft dan op een ander punt (eens op 44% en eens op 6%) steken.
* reboot, de schijven 'los' mounten. dit werkt like charm (mount /dev/sda1 /root/test) . Ik kan er ook van lezen etc. hetzelfde voor sdb1, waar evenveel op staat. de schijven lijken prima dus, en ik heb verder ook geen reden aan te nemen dat er iets mis mee is.

wat ik verder nog kan doen is de schijven gaan testen (heb wel een bootdisk met tools etc) op fouten, maar ik ben bang dat ik gewoon iets raars doe met mdadm. klopt dat hele verhaal met die superblocks etc wel? doe ik nou gewoon iets doms bij mijn raid? Als iemand wat steun kan geven, gaarne

edit: voor de zekerheid: forum search gedaan op die ata2 timeout regel, de snese key medium error (iets met tapes ) en mdadm algemeen. just in case ;D

[EnnaN]

update:

toch even harddisks getest met western digital data lifeguard tools/diagnostics

1)wdc wd3200js-00pdb0
quick test - without errors
2)wdc wd3200js-00pdb0
quick test - without errors

zoals verwacht. nog even naar irq's gekeken, maar voor zover ik kan zien draait die sata kaart braaf aleentjes op irq 12.

[ronny]

Ik kan zo gauw niet ontdekken of je een aparte schijf hebt voor het OS.
Indien je een aparte schijf hebt voor je OS dan is de md0 nog volledig in takt en dan kun je volgens mij hem zo weer mounten. volgens mij hoef je dan niet eerst te rebuilden, er is immers niets mis met de raid.

offtopic:
Ik denk eerlijkgezegt dat dit meer een vraagje is voor NOS.
Het is namelijk meer Linux software als hardware.

[ Voor 58% gewijzigd door ronny op 16-01-2007 15:48 ]

[EnnaN]

Het OS staat op een aparte schijf, maar hoe bedoel je "de md0 zo weer mounten" ? als ik een nieuwe debian op de hda gooi, dan is er geen md0, omdat er niet direct opdracht gegeven is om die sda1 en die sdb1 samen te nemen toch?

offtopic:
ik had hem express hier neer gezet, omdat hier alle RAID feestjes staan. mocht het zo zijn dat ik iets doms doe met het weer starten van het apparaat dan is het idd een NOS-topic, maar ik snap niet waarom die foutmelding komt en ik dacht dus als eerste dat daar iets mis mee is. maarja, het is idd zo dat ik nog niet ontdekt heb wat het probleem is, dus achteraf kunnen we pas echt zeggen op welk plekje hij hoort

[BalusC]

Jouw schijven zijn dus nog gezond, dan ligt het probleem eerder aan Linux.

Topicmove Opslagmedia & I/O Controllers » Non-Windows Operating Systems dus

[EnnaN]

als ik nu hoop dat iemand een goede test voor m'n sata kaartje weet dan zit ik dus inmiddels in het verkeerde hoekje .. ah well..

goed. weet dan iemand hoe ik ronnys idee van "gewoon mounten" moet uitvoeren, of wat er mis kan zijn?

[ph0t0nix]

Moet je geen ''mdadm --assemble ...'' gebruiken? Daarmee geef je aan de /dev/sda1 en /dev/sdb1 bij elkaar horen en kun je vervolgens /dev/md0 mounten. Volgens mij is dat wat ronny bedoelt.

[EnnaN]

maar voordat dat kan moet die md0 toch wel bestaan? als ik boot in de nieuwe install is de /proc/mdstat leeg. ik was van mening dat zolang die leeg is, je niet kan assemblen. als ik zo iets doe

code:

mdadm --assemble md0 /dev/sda1 /dev/sdb1

krijg ik dan ook de volgende melding:

code:

mdadm: error opening md0: no such file or directory

doe ik overigens dit (wat achteraf gezien correcter lijkt)

code:

mdadm --assemble /dev/md0 /dev/sda1 /dev/sdb1

dan krijg ik

code:

md: invalid raid superblock magic on sda1
md: sda1 has invalid sb, not importing!
md: md_import_device returned -22
mdadm: failed to add /dev/sda1 to /dev/md0: Invalid argument
mdadm: /dev/md0 assembled from 0 drives - not enough to start the array.

[MrBarBarian]

Mijn "HowTo" weet het antwoord! (eindelijk is ie eens nuttig!...

je moet het superblock even zero'en!

[EnnaN]

hmm, ziet er goed uit:

Superblock problems
Be sure to erase the old superblock before adding allready used disks to a new array
mdadm --zero-superblock /dev/hdb6

maaruhm, het is dus wel de bedoeling dat ik gewoon m'n oude array terugkrijg (inclusief data ). in het geval dat het nodig lijkt heb ik nog wel ergens een 200 gig over waar ik die data tijdelijk kan parkeren, maar goed.

als ik het goed begrijp zeg je dus: superblock leeg halen (van beide schijven?), en dan weer assemble doen?

code:

mdadm --zero-superblock /dev/sda1
mdadm --zero-superblock /dev/sdb1
mdadm --assemble /dev/md0 /dev/sda1 /dev/sdb1

dus? enige dataloss-mogelijkheden gok?

[Verwijderd]

EnnaN schreef op dinsdag 16 januari 2007 @ 20:41:
hmm, ziet er goed uit:

[...]


maaruhm, het is dus wel de bedoeling dat ik gewoon m'n oude array terugkrijg (inclusief data ). in het geval dat het nodig lijkt heb ik nog wel ergens een 200 gig over waar ik die data tijdelijk kan parkeren, maar goed.

als ik het goed begrijp zeg je dus: superblock leeg halen (van beide schijven?), en dan weer assemble doen?

code:

mdadm --zero-superblock /dev/sda1
mdadm --zero-superblock /dev/sdb1
mdadm --assemble /dev/md0 /dev/sda1 /dev/sdb1

dus? enige dataloss-mogelijkheden gok?

Als het goed is had je helemaal niks met mdadm hoeven doen, de Linux kernel, mits je een beetje moderne versie gebruikt, doet het detecteren van software RAID geheel automatisch aan de hand van de UUID's op de schijf.

Indien dit niet automatisch gebeurd, kan je mdadm --assemble gebruiken.
Gebruik NOOIT --build!
Als je in de manpage van mdadm had gekeken, had je dit gezien:

Build
Build an array that doesn't have per-device superblocks. For these sorts of arrays, mdadm cannot differentiate between initial creation and subsequent assembly of an array. It also cannot perform any checks that appropriate devices have been requested. Because of this, the Build mode should only be used together with a complete understanding of what you are doing.

Met het zero'en van de superblock kan mdadm je array niet meer mounten, ook weer uit de manpage:

Devices can be given on the --assemble command line or in the config file. Only devices which have an md superblock which contains the right identity will be considered for any array.

Ik denk dat de reden voor het niet automatisch detecteren van je RAID de volgende was:

If mdadm cannot find any array for the given host at all, and if --auto-update-homehost is given, then mdadm will search again for any array (not just an array created for this host) and will assemble each assuming --update=homehost. This will change the host tag in the superblock so that on the next run, these arrays will be found without the second pass. The intention of this feature is to support transitioning a set of md arrays to using homehost tagging.

Voor de volgende keer.

Ik heb het zelf nog nooit geprobeerd, maar als het goed is, kan je na het zero'en van de superblocks --build gebruiken om mdadm te dwingen de array alsnog te maken, dan schrijft hij ook automatisch weer de juiste superblocks terug.
Maak eerst een backup zou ik zeggen.

Dus, maak een backup, zero die zooi en:

BUILD MODE

Usage: mdadm --build device --chunk=X --level=Y --raid-devices=Z devices

This usage is similar to --create. The difference is that it creates an array without a superblock. With these arrays there is no difference between initially creating the array and subsequently assembling the array, except that hopefully there is useful data there in the second case.

The level may raid0, linear, multipath, or faulty, or one of their synonyms. All devices must be listed and the array will be started once complete.

[ Voor 18% gewijzigd door Verwijderd op 16-01-2007 22:13 ]

[EnnaN]

Als het goed is had je helemaal niks met mdadm hoeven doen, de Linux kernel, mits je een beetje moderne versie gebruikt, doet het detecteren van software RAID geheel automatisch aan de hand van de UUID's op de schijf.
Indien dit niet automatisch gebeurd, kan je mdadm --assemble gebruiken.

tjah, dat gebeurde dus niet. dat kan dus nu niet (meer?), maar dat kan door mijn build komen?

Gebruik NOOIT --build!
Als je in de manpage van mdadm had gekeken, had je dit gezien:

dat had ik natuurlijk gelezen, maar ik moest m'n raid omhoog zien te krijgen, en dit leek de methode. misschien had ik de functie van build niet goed begrepen, maar had natuurlijk wel de manpage gelezen.

Met het zero'en van de superblock kan mdadm je array niet meer mounten, ook weer uit de manpage:
--
Ik heb het zelf nog nooit geprobeerd, maar als het goed is, kan je na het zero'en van de superblocks --build gebruiken om mdadm te dwingen de array alsnog te maken, dan schrijft hij ook automatisch weer de juiste superblocks terug.

maar het is verwacht dat dat NIET werkt zonder het zero'en?


en dan om nog maar even te zeuren: ik vind de fout die ik krijg bij het builden nogal niet lijken op bovenstaande problemen. ligt dat aan mij, of kan er nog iets anders aan de hand zijn?
ik zal iig vanavond de files backuppen en dan eens met het zero-en van de superblock beginnen. wat jij zegt is dus na het zero-en moet je _wel_ builden, rite?

[MrBarBarian]

Je hebt 2 disken, dus altijd backup mogelijkheid. Je kan gewoon overnieuw beginnen:

- Haal een disk uit het array (is dus al gebeurt ). formatteren en mounten
- Dump de contents van je array naar de zojuist gemounte disk (hoeft niet eens persee, mirror enzo)
- Sloop het gehele array
- bouw het opnieuw op met 1 disk (mdadm --create --level=1 --raid-devices=2 /dev/sda1 missing)
- formatter je array en dump de contents van je eerste disk er naartoe..
- relabel je eerste disk en zet hem weer in de array..

schone lei!

Maar met assemble had he ook moeten kunnen ja

[ Voor 8% gewijzigd door MrBarBarian op 16-01-2007 22:36 ]

[EnnaN]

dat is inderdaad ook een mogelijkheid, maar ik maak me dus druk om die timeout die op random momenten tijdens het resyncen voorkomt bij de build! ik ben bang dat dat net zo hard weer terugkomt, dus probeer ik daarom te snappen waarom het nu niet meer lukt van twee disks uit een array weer een array te bouwen.

als ik bovenstaande zo snap zijn de superblocks kennelijk niet goed meer, en dat kan ik door die te nullen en te builden tegengaan, of ik bouw idd gewoon een nieuwe waarbij ik data ga behouden door een missing schijf oid.
maar zou ik met een build nu niet de superblocks kunnen 'resetten'? en zo nee, kan die superblock dus deze timeout (of wat die fout maar betekend) geven?

(overigens is de hulp enorm gewaardeerd, ondanks dat ik de hele tijd vragen blijf stellen )

[MrBarBarian]

One way to find out I guess...

(ik heb je TS maar eens goed gelezen ) Ik zou het volgende doen:

- Array opnieuw maken
- als het fout gaat, badblocks runnen op beide disken (blijft het fout gaan, dan maxtool als het maxtor disken zijn en een lowlevel format)

Watvoor controller heb je? Zoals je hebt kunnen lezen heb ik nogal wat problemen gehad met silicon. Misschien ook een oorzaak..

Volgens mij mag een foutief uuid nooit deze fouten opleveren

[EnnaN]

@array opnieuw: dat dacht ik ook. ik zal vanavond over het netwerk de data extra backuppen.. dat zal wel even duren.

@controller: inderdaad een silicon image. ook ik heb hier veel problemen mee gehad, en dan metname met maxtor schijven (die vastliepen en moeilijk deden en random j. dodelijk waren. uiteindelijk de schivjen omgeruild voor WD's.) uiteindelijk ben ik dus een beetje bang voor dit ding, hoewel di ehet goed gedaan heeft het afglopen half jaar (? zo iets iig). stukke schijven leek het ook al niet aan te liggen.

maar goed, ik zal morgen eens een nieuwe raid aanmaken.

[EnnaN]

update: na een rsync gedaan te hebben vanacht om de data veilig te stellen heb ik dus maar even wat geklooid. omdat de meningen niet helemaal overeenkomen een keuze gemaakt uit de bovenstaande tips:

eerst maar eens die superblocks nullify-en met

code:

mdadm --zero-superblock /dev/sda1
mdadm --zero-superblock /dev/sdb1

dat gaf verder geen autoput. maar ook geen problemen
daarna wou een assemble nog steeds niet (dat was volgens mij verwacht, zonder superblocks, rite?), maar onze vriend de build:

code:

mdadm --build -- verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1

deed het nu in een keer goed. dus, ik heb weer een raid..
maar om niet zomaar klaar te zijn:

1) kan die zero-superblock de oplossing zijn geweest? als in, hij stallde niet zomaar op hetzelfde moment, dus was dit toeval? kan een probleem met de superblock de in de TS getikte problemen veroorzaken?
2) moet er uiteindelijk in de /etc/mdadm.conf iets komen te staan voordat de md0 automatisch herkend wordt door mdadm tijdens/na reboot?


edit: volledige meldingen in de dmesg van de build en de mount trouwens:

code:

md: bind<sda1>
md: nonpersistent superblock ...
md: bind<sdb1>
md: nonpersistent superblock ...
md: raid1 personality registered as nr 3
raid1: raid set md0 active with 2 out of 2 mirrors
md: syncing RAID array md0
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwith (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 312568641 blocks.
md: md0: sync done.
RAID1 conf printout:
 --- wd:2 rd:2
 disk 0, wo:0, o:1, dev:sda1
 disk 1, wo:0, o:1, dev:sdb1
ReiserFS: md0: found reiserfs format "3.6" with standard journal
ReiserFS: md0: using ordered data mode
ReiserFS: md0: journal params: device md0, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: md0: checking transaction log (md0)
ReiserFS: md0: Using r5 hash to sort names

[ Voor 32% gewijzigd door EnnaN op 17-01-2007 15:56 ]

[Verwijderd]

EnnaN schreef op woensdag 17 januari 2007 @ 15:53:
update: na een rsync gedaan te hebben vanacht om de data veilig te stellen heb ik dus maar even wat geklooid. omdat de meningen niet helemaal overeenkomen een keuze gemaakt uit de bovenstaande tips:

eerst maar eens die superblocks nullify-en met

code:

mdadm --zero-superblock /dev/sda1
mdadm --zero-superblock /dev/sdb1

dat gaf verder geen autoput. maar ook geen problemen
daarna wou een assemble nog steeds niet (dat was volgens mij verwacht, zonder superblocks, rite?), maar onze vriend de build:

code:

mdadm --build -- verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1

deed het nu in een keer goed. dus, ik heb weer een raid..
maar om niet zomaar klaar te zijn:

1) kan die zero-superblock de oplossing zijn geweest? als in, hij stallde niet zomaar op hetzelfde moment, dus was dit toeval? kan een probleem met de superblock de in de TS getikte problemen veroorzaken?
2) moet er uiteindelijk in de /etc/mdadm.conf iets komen te staan voordat de md0 automatisch herkend wordt door mdadm tijdens/na reboot?


edit: volledige meldingen in de dmesg van de build en de mount trouwens:

code:

md: bind<sda1>
md: nonpersistent superblock ...
md: bind<sdb1>
md: nonpersistent superblock ...
md: raid1 personality registered as nr 3
raid1: raid set md0 active with 2 out of 2 mirrors
md: syncing RAID array md0
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwith (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 312568641 blocks.
md: md0: sync done.
RAID1 conf printout:
 --- wd:2 rd:2
 disk 0, wo:0, o:1, dev:sda1
 disk 1, wo:0, o:1, dev:sdb1
ReiserFS: md0: found reiserfs format "3.6" with standard journal
ReiserFS: md0: using ordered data mode
ReiserFS: md0: journal params: device md0, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: md0: checking transaction log (md0)
ReiserFS: md0: Using r5 hash to sort names

De kernel detecteert automatisch welke partitie bij welke hoort en maakt daar een array van.
Je ziet dan in je dmesg iets als:

md: Autodetecting RAID arrays.
md: autorun ...
md: considering sdb3 ...
md: adding sdb3 ...
md: sdb2 has different UUID to sdb3
md: sdb1 has different UUID to sdb3
md: adding sda3 ...
md: sda2 has different UUID to sdb3
md: sda1 has different UUID to sdb3
md: created md3
md: bind<sda3>
md: bind<sdb3>
md: running: <sdb3><sda3>
raid1: raid set md3 active with 2 out of 2 mirrors

Daarvoor heb je echter wel intacte superblocks nodig, ik denk dat --build die weer aangemaakt heeft.

Dit kan je simpel testen met "mdadm -D /dev/md0".

Je zou dan iets als:
"Persistence : Superblock is persistent"
moeten zien.

[EnnaN]

controleerd:

code:

pustule:/var/tmp# mdadm -D /dev/md0
/dev/md0:
        Version : 00.90.01
  Creation Time : Wed Jan 17 13:58:40 2007
     Raid Level : raid1
     Array Size : 312568641 (298.09 GiB 320.07 GB)
    Device Size : 312568641 (298.09 GiB 320.07 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is not persistent

    Update Time : Wed Jan 17 15:50:40 2007
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1

niet consistent dus. daar zal ik dan ws wat aan moeten doen voor het gaat werken, niet?

google laat mij geloven dat ik na het nullen van die superblocks niet build maar create had willen gebruiken, al in

code:

mdadm --create --assume-clean --level=1

iemand daar ideen over?

[ Voor 4% gewijzigd door EnnaN op 17-01-2007 18:15 ]

[EnnaN]

klein schopje. ik zit nu dus met een not-persistent superblock, en ik vraag me af of dit heel erg is, en of ik hier wat aan moet doen alvorens weer 'live' te gaan met deze raid?

[EnnaN]

goed, om het not-persistent superblock probleem op te lossen maar een create gedaan

mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1

allemaal leuk en aardig, herkent een bestandssysteem, gaat daarna het ding bouwen, en syncen..... en dan weer het oude verhaal.
hoewel er dus iets niet helemaal goed is aan het huidige apparaat, lijkt het mij dat er toch ergens iets vervelends fout zit!

persoonlijk zie ik nog steeds niet hoe een raar gemaakte RAID die "abnormal status requests" gedaan kan krijgen. voor de duidleijkheid de dmesg:

md: md0 stopped.
md: bind<sda1>
md: bind<sdb1>
md: md0: raid array is not clean -- starting background reconstruction
md: raid1 personality registered as nr 3
raid1: raid set md0 active with 2 out of 2 mirrors
md: syncing RAID array md0
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwith (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 312568576 blocks.
ata2: command 0x35 timeout, stat 0xd9 host_stat 0x61
scsi1: ERROR on channel 0, id 0, lun 0, CDB: Write (10) 00 10 44 7c 3f 00 04 00 00
Current sdb: sense key Medium Error
Additional sense: Write error - auto reallocation failed
end_request: I/O error, dev sdb, sector 272923711
ATA: abnormal status 0xD9 on port 0xDC837EC7
ATA: abnormal status 0xD9 on port 0xDC837EC7
ATA: abnormal status 0xD9 on port 0xDC837EC7

[EnnaN]

hopende dat iemand hier nog langswandeld blijf ik maar updaten

complete testen van de schijven (dus niet alleen de quick test, maar ook de extended test) van de WD diagnostics laten ook geen enkel probleem zien. mogelijke oorzaken volgens mij

* raid verkeerd gemaakt
* communicatie met sata kaart niet goed

bij de eerste vind ik het raar dat ik een I/O error krijg.. dat is toch strange?

bij de communicatie met de sata kaart kun je denken aan soft en hardware.. voor beide nog niet veel aanwijzingen..

[ph0t0nix]

Heb je al eens een nieuwere kernel geprobeerd? Wie weet is het gewoon een driverbug.

[EnnaN]

hmm. het lijkt vrij up to date, maar ik zal even precies kijken (hopefully morgen)

[EnnaN]

ik draai een standard debian kernel, 2.6.8-3-k7 .. dat lijkt niet heel nieuw.. ik ben nogal blij met die standard kernels, dan hoef ik niet veel effort in het compilen van een eigen kernel te steken etc. ik had niet het idee dat ik een nieuwere kon vinden, zal daar nog even naar kijken.

edit: goed, dan draai ik nu dus 2.6.18-3-k7 ben ik iig up to date. dan en dan maar weer rebuilden

[ Voor 15% gewijzigd door EnnaN op 28-01-2007 16:41 ]

[EnnaN]

heul interessant. met deze kernel kan ik ineens niet meer iets met /dev/md0..

code:

mdadm: error opening /dev/md0: No such file or directory

welja.

om toch maar even wat te kunnen kijken of het zo beter werkt het volgende gedaan
[code]mknod -m 0660 /dev/md0 b 9 0
chgrp disk /dev/md0
mdadm --assemble /dev/md0 /dev/sd[ab]1
/code]
zodat ik iig weer kan testen.
maar erg ideaal is het niet.

volgnede probleem dus erbij... any help still welcome


-------------------------------------------------

goed. laatste hoop dat het nog zin heeft iets te posten
wederom geen happy camper.

code:

d: md0 stopped.
md: bind<sdb1>
md: bind<sda1>
md: raid1 personality registered for level 1
raid1: raid set md0 active with 1 out of 2 mirrors
RAID1 conf printout:
 --- wd:1 rd:2
 disk 0, wo:0, o:1, dev:sda1
 disk 1, wo:1, o:1, dev:sdb1
md: syncing RAID array md0
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 312568576 blocks.
ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x2400000 action 0x2 frozen
ata2.00: (BMDMA stat 0x61)
ata2.00: tag 0 cmd 0x35 Emask 0x12 stat 0xd9 err 0x4 (ATA bus error)
ata2: hard resetting port
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata2.00: configured for UDMA/100
ata2: EH complete
SCSI device sdb: 625142448 512-byte hdwr sectors (320073 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x2400000 action 0x2 frozen
ata2.00: (BMDMA stat 0x61)
ata2.00: tag 0 cmd 0x35 Emask 0x12 stat 0xd9 err 0x4 (ATA bus error)
ata2: hard resetting port
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata2.00: configured for UDMA/100
ata2: EH complete
SCSI device sdb: 625142448 512-byte hdwr sectors (320073 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x90000 action 0x2 frozen
ata1.00: (BMDMA stat 0x61)
ata1.00: tag 0 cmd 0x25 Emask 0x12 stat 0xc2 err 0x76 (ATA bus error)
ata1: hard resetting port
ata1: port is slow to respond, please be patient
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: configured for UDMA/100
ata1: EH complete
SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x90000 action 0x2 frozen
ata1.00: (BMDMA stat 0x61)
ata1.00: tag 0 cmd 0xc8 Emask 0x12 stat 0xc2 err 0x76 (ATA bus error)
ata1: hard resetting port
ata1: SATA link down (SStatus 0 SControl 310)
ata1: failed to recover some devices, retrying in 5 secs
ata1: hard resetting port
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: configured for UDMA/100
ata1: EH pending after completion, repeating EH (cnt=4)
ata1: exception Emask 0x10 SAct 0x0 SErr 0x10000 action 0x1
ata1: soft resetting port
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: configured for UDMA/100
ata1: EH complete
SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x90000 action 0x2 frozen
ata1.00: (BMDMA stat 0x61)
ata1.00: tag 0 cmd 0xc8 Emask 0x12 stat 0xd0 err 0x0 (ATA bus error)
ata1: hard resetting port
ata1: SATA link down (SStatus 0 SControl 310)
ata1: failed to recover some devices, retrying in 5 secs
ata1: hard resetting port
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: configured for UDMA/100
ata1: EH pending after completion, repeating EH (cnt=4)
ata1: exception Emask 0x10 SAct 0x0 SErr 0x10000 action 0x1
ata1: soft resetting port
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: configured for UDMA/100
ata1: EH complete
SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x90000 action 0x2 frozen
ata1.00: (BMDMA stat 0x61)
ata1.00: tag 0 cmd 0x25 Emask 0x12 stat 0xc2 err 0x20 (ATA bus error)
ata1: hard resetting port
ata1: SATA link down (SStatus 0 SControl 310)
ata1: failed to recover some devices, retrying in 5 secs
ata1: hard resetting port
ata1: port is slow to respond, please be patient
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: configured for UDMA/100
ata1: EH pending after completion, repeating EH (cnt=4)
ata1: exception Emask 0x10 SAct 0x0 SErr 0x10000 action 0x1
ata1: soft resetting port
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: configured for UDMA/100
ata1: EH complete
SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
ata1.00: limiting speed to UDMA/66
ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x90000 action 0x2 frozen
ata1.00: (BMDMA stat 0x61)
ata1.00: tag 0 cmd 0x25 Emask 0x12 stat 0x1b err 0x50 (ATA bus error)
ata1: hard resetting port
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: configured for UDMA/66
ata1: EH complete
SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
ata1.00: limiting speed to UDMA/44
ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x90000 action 0x2 frozen
ata1.00: (BMDMA stat 0x61)
ata1.00: tag 0 cmd 0xc8 Emask 0x12 stat 0xc2 err 0x76 (ATA bus error)
ata1: hard resetting port
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: configured for UDMA/44
ata1: EH complete
SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x2400000 action 0x2 frozen
ata2.00: (BMDMA stat 0x61)
ata2.00: tag 0 cmd 0x35 Emask 0x12 stat 0xd9 err 0x4 (ATA bus error)
ata2: hard resetting port
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata2.00: configured for UDMA/100
ata2: EH pending after completion, repeating EH (cnt=4)
ata2: EH complete
SCSI device sdb: 625142448 512-byte hdwr sectors (320073 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back

om vervolgens een hele serie dit te doen:

code:

raid1: sda: unrecoverable I/O read error for block 0
scsi 0:0:0:0: rejecting I/O to dead device
raid1: sda: unrecoverable I/O read error for block 128
scsi 0:0:0:0: rejecting I/O to dead device
raid1: sda: unrecoverable I/O read error for block 256
scsi 0:0:0:0: rejecting I/O to dead device
raid1: sda: unrecoverable I/O read error for block 384

[ Voor 96% gewijzigd door EnnaN op 28-01-2007 17:55 ]

[Zeezicht]

Mmm zulke errors heb ik laatst ook gehad, of althans ze lijken er sterk op.
Kan je ook een andere SATA poort proberen, mss dat daar iets mis mee is. Ik had het probleem namelijk op poort 1 en 2 en nu ik 3 en 4 gebruik is alles weer goed.

[EnnaN]

volledig nieuwe computer, volledig nieuwe installatie, maar dezelfde schijven en sata kaart geeft dezelfde shite...

dus ik begin steeds minder de software te verdenken. maar omdat het een 'oud' moederbord zonder sata betreft moet ik dus ergens een ander sata kaartje vinden/lenen etc..

but thats exactly wat ik ga doen volgende week

[Zeezicht]

Ok das dus klote. Maar ik ben erg benieuwd of je dan geen problemen meer hebt. Want ik vraag bij mijn geval ook wel een beetje af wat het nou precies is. En misschien moet ik dus een nieuwe moederbord gaan vragen onder garantie.

Dus als je je resultaten zou willen posten zodra je dat hebt gedaan, graag!

[EnnaN]

zal ik zeker doen. Heb jij toevallig enig idee of dergelijke fouten kunnen worden veroorzaakt door die al dan niet aanwezige persistency? het leek mij dus niet, but hey, what do i know

[ph0t0nix]

EnnaN schreef op zondag 28 januari 2007 @ 16:51:
heul interessant. met deze kernel kan ik ineens niet meer iets met /dev/md0..

code:

mdadm: error opening /dev/md0: No such file or directory

welja.

om toch maar even wat te kunnen kijken of het zo beter werkt het volgende gedaan
[code]mknod -m 0660 /dev/md0 b 9 0
chgrp disk /dev/md0
mdadm --assemble /dev/md0 /dev/sd[ab]1
/code]
zodat ik iig weer kan testen.
maar erg ideaal is het niet.

Dat komt waarschijnlijk omdat de kernels na 2.6.15 (dacht ik) een andere, nieuwere versie van udev nodig hebben. Ergens rond die tijd is ook begonnen met het uitfaseren van hotplug ten voordele van udev. Er zijn misschien nog wat dependencies niet in orde.

[ph0t0nix]

EnnaN schreef op maandag 29 januari 2007 @ 00:47:
volledig nieuwe computer, volledig nieuwe installatie, maar dezelfde schijven en sata kaart geeft dezelfde shite...

dus ik begin steeds minder de software te verdenken. maar omdat het een 'oud' moederbord zonder sata betreft moet ik dus ergens een ander sata kaartje vinden/lenen etc..

but thats exactly wat ik ga doen volgende week

Ik ben uiteindleijk ook op een ander moederbord overgegaan (met nvidia sata poorten (nForce4)), omdat ik problemen bleef houden met de Silicon Image controller op het vorige moederbord (waarbij gezegd moet worden dat het een nForce2 mobo was, en ik toen nog Maxtor schrijven gebruikte, dus of het echt aan de Silicon Image controller lag...).

Zoals Zeezicht al zei: Als de controller meer SATA poorten heeft, kan het wel eens helpen om ze om te wisselen.

Krijg je de errors ook als je maar een van de schijven eraan hangt (en je RAID dus "broken" mount)?

[EnnaN]

@silicon en maxtor: praat me er niet van. dat heeft me ook al tijden gekost, maar toen uiteindelijk die schijven omgewisselt voor WD.. die combo tussen maxtor en silicon werkte iig niet

@broken: nope. als ik hem gewoon mount (dus gewoon "mount /dev/sda1 /tempdir" dan werkt het, en als ik de raid maak op md0 met een "missing" ipv "/dev/sdb1" dan gaat het goed.

wat hem niet lukt is het syncen. dan gaat hij, redeneerde ik, dus een lange tijd achter elkaar de gegevens met elkaar vergelijken (neem ik aan dus, weet ik niet heel veel van) .. en dan bij die lange I/O naar het systeem gaat er ineens iets fout, kan ie niet syncen, en is er iets mis

@udev: ja, zo iets is het wel inderdaad, maar omdat ik niet dacht dat ik al een oplossing had voor het RAID probleem had ik me daar nog niet op gestort, leek me van latere zorg zolang het nu maar testbaar is

[analog_]

Niet erg gerelateerd maar dat versnelt het rebuilden telkens wel (bij mij ging hij van 5MB naar 45) :

code:

/proc/sys/dev/raid/speed_limit_min and _max

. Zie ook hier. Kan je trouwens niet een image maken van de ene schijf en hem kopieren naar de andere ? Soort van houwtje touwtje syncen ?

[EnnaN]

well, volgens mij zijn ze al vrij gelijk, maar bij het syncen gaat ie dat checken als ik het goed heb (correct me if i'm wrong).
bestandssysteem is for the eye iig gelijk.

[ph0t0nix]

volgens mij zijn ze al vrij gelijk, maar bij het syncen gaat ie dat checken als ik het goed heb

Volgens mij ook. Je kunt de voortgang volgen door regelmatig een 'cat /proc/mdstat' te doen.

Je schreef eerder dat je een volledig nieuwe installatie had op een nieuw mobo maar met dezelfde harddisks en sata kaart. Wil je daarmee zeggen dat je je OS disk van een vers OS hebt voorzien, maar de RAID disks nog steeds de oude RAID array hebben? (Dat ik het even goed begrijp)

[EnnaN]

@cat mdstat: idd: vandaar dat ik ook weet dat bij de foutmelding de sync niet altijd op hetzelfde moment stopte. echt heel verschillend, van bijna direct tot na 1,5 uur syncen, dus op 90+% ...

verder heb ik een andere computer gepakt, daar op een IDE disk een nieuw OS (nieuwste debian netinstall) met volledige updates en de nieuwste kernel die ik kon vinden op gezet. Daar heb ik de kaart en de stata disks in gestopt.
en mocht je impliceren dat het misschien wel eens tijd zou worden om die disks te wipen ben ik het met je eens. ik kan alleen nog nie tverklaren waarom dat zou helpen ;D

[ph0t0nix]

ik kan alleen nog nie tverklaren waarom dat zou helpen

Ik ook niet. Maar onderhand begint de trukendoos leeg te raken :-).

wat hem niet lukt is het syncen. dan gaat hij, redeneerde ik, dus een lange tijd achter elkaar de gegevens met elkaar vergelijken (neem ik aan dus, weet ik niet heel veel van) .. en dan bij die lange I/O naar het systeem gaat er ineens iets fout, kan ie niet syncen, en is er iets mis

En als je heel grote files kopieert van en naar de array (of naar een losse schijf uit de array)? Dat zou tenslotte ook voor lange I/O moeten zorgen...
Misschien een van de disks even helemaal leeg gooien en als gewone disk (geen RAID) in je systeem plaatsen en dan een groot bestand kopieren. Kijken of lange I/O dan ook niet wil.

[EnnaN]

so. i _know_ i'm being toyed with.

dus. ondanks wat photonix schreef over udev (en wat dus waar was), werd bij mijn nieuwe sessie vanochtend tijdens booten ineens keurig een raid herkent. wel maar met 1 schijf, waardoor hij prompt ging syncen. mijn huidige mdstat doet netjes

code:

md0 : active raid1 sda1[0] sdb1[1]
      312568576 blocks [2/2] [UU]

overigens wel met een stuk of 6 van dit soort meldingen in de dmesg:

code:

ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x2400000 action 0x2 frozen
ata2.00: (BMDMA stat 0x61)
ata2.00: tag 0 cmd 0x35 Emask 0x12 stat 0xd9 err 0x4 (ATA bus error)
ata2: hard resetting port
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata2.00: configured for UDMA/100
ata2: EH complete
SCSI device sdb: 625142448 512-byte hdwr sectors (320073 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back

ik denk dan ook dat het min of meer 'toeval' is dat het nu wel gelukt is. Ik heb niets veranderd behalve rebooten na de vorige keer, en omdat het crashmoment toch al willekeurig was tijdens het syncen (soms snel, soms laat)...

in other news: de "mdadm -D /dev/md0" geeft nu wel duidelijk dat het superblock persistent is! this is a good thing no?

een nieuwe sata kaart heb ik nog niet, dus daar kan ik niet mee testen. die foutmeldingen zitten me verre van lekker. kijken of het weer goed gaat na een reboot. daarna zal ik kijken of het opsnellen van die min/max speed wat helpt. dan is het process in ieder geval niet zo langdurig.

edit: hee, wat doen die code blocks funky?
edit2: hee, nieuwepagina, niet gelezen! stom van mij. goede tip, ik denk dat ik idd wat extra IO ga proberen. wat bijvoorbeeld wel was gelukt was vlak voordat ik ging kloten een volledige rsync van de hele schijf naar een via samba gemounte schijf. 300gig, rsync over het netwerk/smaba. dat duurde uren. en dat ging goed (afaik. geen foutmeldingen iig).

edit3: Als de raid eenmaal gemaakt is heeft ie volgens mij geen problemen: zojuist een kleine 20 gig over het netwerk gestuurd (samba gemoutn op en een windows comp) en dat ging prima. geen meldingen in de dmesg oid.

[ Voor 17% gewijzigd door EnnaN op 02-02-2007 15:35 ]

[ph0t0nix]

Hen je niks te doen van 't weekend? Probeer dan eens een schijf uit de array te knikkeren en 'm daarna weer toe te voegen. Eens zien of het syncen dan nog steeds goed gaat (zonder dmesg meldingen).

Of hou je het nu liever even werkend?

[EnnaN]

dat was ik van plan, maar hij staat nu uit: is het standaard dat als ik hem nu aanzet dat hij weer gaat syncen, of zou het zonder syncen weer up moeten zijn?
in ieder geval klinkt het wel als een plan, ik heb hem liever stabiel dan werkend, dus klussen wordt hem nog wel


het weekend bevat overigens een kleine party in den haag, dus dat wordt morgen avond pas weer testen.

[ph0t0nix]

is het standaard dat als ik hem nu aanzet dat hij weer gaat syncen, of zou het zonder syncen weer up moeten zijn?

Zolang er niks mis is met je array moet hij zonder syncen opstarten.

[EnnaN]

nu doet rebooten inderdaad ineens netjes de raid weer up doen (waarschijnlijk omdat hij dus gesynced is, en de superblock netjes weer persistent is). en er lijkt dan ook geen probleem te zijn. nu toch maar even hertesten.

dus

code:

pustule:~# mdadm --manage /dev/md0 --fail /dev/sda1
mdadm: set /dev/sda1 faulty in /dev/md0
pustule:~# mdadm --manage /dev/md0 --remove /dev/sda1
mdadm: hot removed /dev/sda1
pustule:~# mdadm --manage /dev/md0 --add /dev/sda1
mdadm: re-added /dev/sda1

kijken of het nu gaat werken.

niet dus. zelfde gedrag. het lijkt een tijd goed te gaan, maar al snel komen er steeds meer IO errors.
als ik me even op de laatste focus:

code:

> SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
> sda: Write Protect is off
> sda: Mode Sense: 00 3a 00 00
> SCSI device sda: drive cache: write back
> ata1.00: speed down requested but no transfer mode left
> ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x2400000 action 0x2 frozen
> ata1.00: tag 0 cmd 0x39 Emask 0x12 stat 0x58 err 0x0 (ATA bus error)
> ata1: hard resetting port
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> ata1.00: configured for PIO0
> ata1: EH pending after completion, repeating EH (cnt=4)
> ata1: EH complete
> SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
> sda: Write Protect is off
> sda: Mode Sense: 00 3a 00 00
> SCSI device sda: drive cache: write back

het syncen gaat nu nog maar heel langzaam (< 3344 K/sec), en het systeem reageert erg traag (lees: eigenlijk niet meer).

[ph0t0nix]

ata1.00: speed down requested but no transfer mode left
(...)
ata1.00: configured for PIO0

Blijkbaar schakelt je schijf van DMA transfers over naar PIO, da's nooit goed voor de snelheid.
Is hdparm inmiddels al geschikt voor SATA disks (toen ik voor het laatst met dit soort dingen te maken had, nog niet)? Als dat wel zo is, dan zou je eens kunnen kijken wat hdparm over je schijf zegt als lles nog goed/snel reageert en wat er na bovenstaande errors gebeurt.

[Verwijderd]

EnnaN schreef op zondag 04 februari 2007 @ 19:25:
<knip>

Frapant genoeg heb ik momenteel precies dezelfde situatie als jij, 2 seagate's die 5 weken perfect in RAID1 gedraait hebben, paar dagen geleden had mdadm er 1 uit de RAID gekicked, paar uur later kapte de 2e er ook mee.
In de eerste instantie was de array nog wel te rebuilden, dacht eerst dat het aan de controller (Intel ICH5 chipsetje) lag, maar later ging de hele zooi weer onderuit.

Omdat ik twijfelde of het aan de schijven lag heb ik ze op mijn werk op een aantal andere controllers getest, een en al driveready seek complete errors. Niet goed.

Voor de zekerheid 1 schijf geformateerd, nieuwe array erop en de data van de andere schijf overgekopierd. Ging vlekkeloos.

Totdat ik de andere schijf aan de RAID toevoegde en hij ging syncen.
Dat ging goed tot 89% en toen kreeg ik exact jouw errors.

Ik weet dus eigenlijk wel zeker dat het probleem in de schijven zit, welke weet ik alleen nog niet.
Ik ga morgen effe spelen met smartctl en wat oppervlaktetests doen.
De SMART logs laten iig een lading READ errors zien en Short Offline tests failen bij in ieder geval 1 van de 2 schijven.

Ooit smartctl op jouw schijven losgelaten?
apt-get install smartmontools en dan smartctl -d ata -a /dev/sda/b.
Man smartctl voor meer commando's.

Ik denk dat jij ook gewoon met een brakke schijf zit, ondanks dat die wd tool dat niet laat zien.

[EnnaN]

@photonix: wat zou je precies willen weten? de cached/uncached snelheid voor syncen? of tijdens syncen (na syncen kom ik momenteel even niet aan toe gok ik zo?)

het syncen gaat trouwens wel door, maar het hele systeem is zo traag, en na uur of wat heb ik er niet echt zin meer in. ik ga even wat anders proberen: de sync-snelheid tweaken zoals hierboven wordt gesuggereerd, en even wat hdparm eroverheen halen


@fabio: als ik seatools erop los laat dan krijg ik allemaal "you're good to go" meldingen. martctl etc heb ik er niet overheen gehaald, maar wel een smart-meet tool van een boodtcd. zag ik geloof ik niets raars, hoewel ik die dingen raar vind lezen. ... ik zal smartctl er eens overheen halen zometeen. eerst maar rebooten

edit: overigens krijg ik ineens wat controle over het systeem. de proc/mdstat zegt dat hij met 3312K/sec bezig is, en dus over een mooie 600 minuten klaar kan zijn... maar hij doet nog wel iets.
hdparm -t geeft direct mooi antwoord op beide schijven (resp. 680 en 530 kB/s). voor buffered disk reads dus.

[ Voor 17% gewijzigd door EnnaN op 06-02-2007 19:52 ]

[TD-er]

Hmm snelheden van 3 MB/s en hoge CPU-load is vrijwel zeker inderdaad een DMA-mode die niet werkt

Zou best kunnen dat je met hdparm niet scsi-schijven kunt uitlezen.

code:

fileserver:~# hdparm -d /dev/hda

/dev/hda:
 using_dma    =  1 (on)

Als ik het aan mijn sda-drive vraag (3ware controller), dan krijg ik geen antwoord terug.
Maar goed, een DMA-mode die uit staat heeft vaak ook wel een oorzaak. kijk of je iets over PIO/DMA kunt terug vinden in de logs.

[EnnaN]

vast wel. die grote lappen errors melden iig: "ata1.00: configured for PIO0"

maar waarom zou de dma uit gaan?

[TD-er]

EnnaN schreef op dinsdag 06 februari 2007 @ 21:47:
vast wel. die grote lappen errors melden iig: "ata1.00: configured for PIO0"

maar waarom zou de dma uit gaan?

DMA gaat uit als er communicatie-fouten optreden.

[EnnaN]

hmz, dan is het dus ws. een symptoom van de vermoedde I/O problemen, rite? ik wil kijken of het op deze manier goed komt (lekker traag syncen)...

kan het zijn dat dat sata kaartje het gewoon niet zo leuk vind als beide schijven lang tegelijk worden bekeken? i dunno, just guessing?

[ph0t0nix]

Ik zou ook zeggen dat de controller het probleem is. Anderzijds doet fabio-c weer vermoeden dat het toch de schijven zijn... Miscchien is het wel de combinatie van schijven en controller. Net zoals Maxtor schijven problemen hadden met nForce4 controllers...

[EnnaN]

het process wordt in ieder geval wel duidelijk. <<oorzaak>> zorgt ervoor dat de I/O niet goed gaat. Dan gaat het SATA kaartje moeilijk doen (vastlopen, terugschakelen, unfreezen etc) en dus speedownen. DMA wordt eruit gekickt en er blijft een miezerig traag systeem over. Door alle I/O etc wordt het systeem bijna volledig tot stilstand gebracht, maar de het syncen gaat door... dit duurt ongeveer 10 uur (heb het een nachtje laten draaien), en dan komt het wel goed (???). inderdaad, na 10 uur syncen is de raid clean en klaar etc.

erg snelle schijven worden het vervolgens niet:

code:

pustule:~# hdparm -t -T /dev/sda

/dev/sda:
 Timing cached reads:   494 MB in  2.00 seconds = 246.46 MB/sec
 Timing buffered disk reads:    8 MB in  3.35 seconds =   2.39 MB/sec
pustule:~# hdparm -t -T /dev/sdb

/dev/sdb:
 Timing cached reads:   500 MB in  2.00 seconds = 249.91 MB/sec
 Timing buffered disk reads:  190 MB in  3.00 seconds =  63.33 MB/sec

(herhalen geeft vergelijkbare waarden)..

ik kan met hdparm volgens mij niet uitlezen welke schijven DMA aan hebben staan, maar als ik dit zo zie vermoed ik dat sda niet dma had (sda was degene die ik net weer teruggezet heb in de raid na de "fail een schijf" test) en sdb nog vrolijk wel.


overigens ook nog even die smartctl gedaan, dit leek me het interessante stuk:

code:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0003   194   191   021    Pre-fail  Always       -       5275
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       90
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   200   200   051    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   096   096   000    Old_age   Always       -       3033
 10 Spin_Retry_Count        0x0013   100   253   051    Pre-fail  Always       -       0
 11 Calibration_Retry_Count 0x0013   100   253   051    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       89
194 Temperature_Celsius     0x0022   115   001   000    Old_age   Always       -       35
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0012   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       5
200 Multi_Zone_Error_Rate   0x0009   200   200   051    Pre-fail  Offline      -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Conveyance offline  Completed without error       00%      2996         -

edit: overigens gaat het na reboot in een keer goed, md0 wordt herkend, en beide disks gaan met een "Timing buffered disk reads" van boven de 60

[ Voor 44% gewijzigd door EnnaN op 07-02-2007 12:10 ]

[EnnaN]

ok. gesynced draaien werkt ook niet meer. ik kan me niet voorstellen dat dit GEEN hardware probleem is meer.

gesynced, en nachtje draaien, staat mijn dmesg vol met meldingen, waaronder:

code:

ata2: exception Emask 0x10 SAct 0x0 SErr 0x90000 action 0x2 frozen
ata2: hard resetting port
ata2: SATA link down (SStatus 0 SControl 310)
ata2: failed to recover some devices, retrying in 5 secs
ata2: hard resetting port
ata2: SATA link down (SStatus 0 SControl 310)
ata2: failed to recover some devices, retrying in 5 secs
ata2: hard resetting port
ata2: SATA link down (SStatus 0 SControl 310)
ata2.00: disabled
ata2: EH complete
ata2.00: detaching (SCSI 1:0:0:0)
scsi 1:0:0:0: rejecting I/O to dead device
raid1: sdb1: rescheduling sector 262152
scsi 1:0:0:0: rejecting I/O to dead device
scsi 1:0:0:0: rejecting I/O to dead device
raid1: Disk failure on sdb1, disabling device.
        Operation continuing on 1 devices
raid1: sda1: redirecting sector 262152 to another mirror
RAID1 conf printout:
 --- wd:1 rd:2
 disk 0, wo:0, o:1, dev:sda1
 disk 1, wo:1, o:0, dev:sdb1
RAID1 conf printout:
 --- wd:1 rd:2
 disk 0, wo:0, o:1, dev:sda1

... er wordt er dus 1 uit de array gekicked.

wat zou er stuk zijn, en hoe kom ik er achter?

[TD-er]

wissel beide schijven om van kabel (dus beide kabeltjes op dezelfde poorten van de controller houden)
Zo sluit je uit of het de schijf is, of de rest.
De sata kabel kan ook brak zijn, vandaar die nog even laten zitten.

[EnnaN]

het is nu helemaal waanzin. na die paar chrashes wil hij sdb helemaal niet meer zien, ook niet in de satakaart bios.

plan de campagne:
* satakaart uitsluiten/aanwijzen door de disks in m'n werkbak te hangen (met knoppix ).
* if geen problemen,
** satakaart vernieuwen
*else
** kabels wisselen
** if problemen
*** nieuwe kabels
** else
*** huilen, disks nog maar eens testen
** endif
* endif

[Verwijderd]

Ik heb ondertussen de schijven uit mijn eerdere verhaal gewoon teruggestuurd.
Test ze voor de zekerheid aan een andere controller, geven ze daar ook problemen, terug met die dingen. Het is echt de tijd en moeite niet waard om er zo lang mee te prutsen.

[EnnaN]

Verwijderd schreef op zaterdag 10 februari 2007 @ 12:25:
Ik heb ondertussen de schijven uit mijn eerdere verhaal gewoon teruggestuurd.
Test ze voor de zekerheid aan een andere controller, geven ze daar ook problemen, terug met die dingen. Het is echt de tijd en moeite niet waard om er zo lang mee te prutsen.

mee eens, maar terugsturen heeft alleen zin als ze kapot zijn, anders lost het niets op

[EnnaN]

kleine update: Ik heb gister de schijven in een derde computer gestopt, deze keer een die zelf SATA heeft. Dit ging dus om een gigabyte ga-965p-ds3, die als ik het me goed herinner een jmicron(?) chipset gebruikt om toch nog een PATA te kunnen leveren. Handig als je wilt branden met je PATA dvdbrander, niet zo handig als je knoppix wilt booten

Gelukkig had de daily ubuntu-build wel de drivers in huis om met dat kreng te werken. Die dus live geboot met de 2 disks er aan.

mounten. syncen. failen. re-add. sync. mount. fsck. alles er over heen gedaan vanaf gister 14:00 tot 0200 ongeveer: geen centje pijn. niets allemaal prima.

Hierbij (doet de toldyousodans ) denk ik dus toch dat het een hardwareprobleem is, en wel het stomme satakaartje. Maandag ga ik first thing (nee, niet want maandagochtend zijn de winkels dicht..) een echt satakaartje kopen.

@fabio-c: bodemlijn is dus bij mij dat het niet de schijf was, hopen dat het bij jou wel goed gaat.

om even het vervolgplan te bespreken:

Nu kost een beetje een sata kaart als je niet die van sweex neemt al gauw zo'n 80/90 euro. hoe zo'n slecht idee is het om die server op IDE te laten draaien?
berekening:
'we' willen nog 320 oid voor een werkcomputer hier in huis. dus dan kan ik
* sata kaartje voor server + nieuwe satadisk voor werkbak
kopen, of
* 2x IDE disk voor server en 'oude' SATA in werkbak

Dat tweede is misschien iets duurder (ik zag 250gb IDE disks, worden die dingen nog groter? of is dat alleen SATA), maar niet veel. EN dan heb ik 1 SATA disks _over_. en das dan wel weer hip....

[TD-er]

Ik heb hier 320 schijven met Pata en volgens mij zijn ze er ook wel groter.
Wat je ook zou kunnen doen is een pata => sata converter kopen (2x)

Met pata > 120 GB moet je wel even kijken of je controller in je server het wel aankan, al is dat tegenwoordig niet echt meer een probleem.

[EnnaN]

werkt dat een beetje? dat pata => sata?
(wtf? mijn copy paste werkt niet meer? nouja, iig in topic 1195872 was iig 1 iemand nogal negatief over die dingen. hoewel het al snel stabieler is dan de ktzooi die het nu is, wil ik natuurlijk wel naar een stabiele oplossing )

server mobo is een vrij nieuwe, maar ik zal het even opzoeken

edit:hmm. dat was weird. iig was het dus dit topic die ik bedoelde, en dan met name de reply van borromini

[ Voor 20% gewijzigd door EnnaN op 11-02-2007 13:00 ]

[TD-er]

uiteraard is het een lapmiddel, maar het leek me goedkoper dan nieuwe schijven. Ik heb er zelf geen ervaring mee, maar ik weet dat sommige raid-controllers dergelijke chips ook gebruikt hebben in de eerste SATA kaarten.

[ph0t0nix]

Voordeel van het gebruiken van IDE drives is dat (afhankelijk van je mobo chipset) de PCI bus geen bottleneck is. Als je een SATA-kaartje koopt, moet 'ie in een PCI slot en als je dus nog meer PCI apparaten hebt, kan het erg druk worden op de bus.

Nadeel van PATA is dat je in de toekomst misschien gelimiteerd bent met je harddiskcapaciteit. De meeste nieuwe modellen zijn tegenwoordig toch SATA.
Het hangt er dus vanaf hoe lang de server nog mee moet en of de benodigde diskspace op de server veel gaat groeien.

[EnnaN]

even 'ter afsluiting'.

* IDE was een leuk idee, maar na wat overleg lijkt het natuulijk niet zo handig. Ik wil de schijven puur data houden, ivm uitwisselen enzo, en het systeem apart. Dat kan dan dus al niet meer, omdat je die RAID disks mooi apart wilt houden, en dus heb je een plek voor je systeemdisk te weinig.
* promise raid kaartje is best duur -> wat onderdelen zoeken, kijken bij de lokale, bevriende, computerboer en dergelijk komt er op neer dat het net zo duur is om een upgradesetje te kopen, en dan met een mobo inclusief sata.

dus mijn nieuwe servertjes draait nu vrolijk een asus p5l-mx, met onboard sata

happy

[ph0t0nix]

Veel plezier!