Bestaande software raid icm nieuwe Rocketraid 2320

[Verwijderd]

Ik draai al een tijd een bestaande software raid5 onder Linux welke met mdadm gemaakt is. Deze array heeft altijd prima gedraaid om een 4-poorts Promise TX4 kaart. Wegens gebrek aan SATA poorten heb ik een Highpoint Rocketraid kaart aangeschaft om 8 extra poorten te krijgen. Hierbij wil ik nog steeds gebruik maken van software raid.
Nu heb ik een probleem dat de disks uit de bestaande raid niet geen devices toegekend krijgen. En dus kan de raid niet gemount worden. Losse disks krijgen wel een device en zijn zoals normaal aanspreekbaar via /dev/sdx.

In eerste instantie leek de sata_mv driver de oplossing aangezien de kaart een Marvell 88SX6081 chip heeft;

Van http://linux-ata.org/driver-status.html#marvell

Marvell 88SXxxxx
Driver name: sata_mv

Summary: Similar to ServerWorks "frodo": per-device queues, full SATA control including hotplug.
The 88SX50xx series supports TCQ, but not NCQ or PM.
The 88SX6xxx series supports TCQ, NCQ, and PM.
The 88SX7xxx series supports TCQ, NCQ, and PM.

HighPoint (HPT)
Driver name: sata_mv or hptiop (sometimes)

Some of the recent HighPoint cards are based on the Marvell 88SX50xx chips. These will be supported by the Marvell libata driver (in progress, see above).

Newer cards pretend they are SCSI, and are supported by the hptiop driver.

De sata_mv driver geeft echter niet thuis. Het lijkt wel alsof deze helemaal niets doet. Vervolgens de kernel opnieuw gecompiled met de hptiop driver en de rr232x driver van Highpoint zelf gecompiled. Met deze combinatie werden normale disks herkend en ik kan ze mounten. Ontbreekt 1 van de 2, dan gebeurt er helemaal niets, net als bij de sata_mv driver.
Maar de raid disks zijn dus niet zichtbaar. Met Highpoints CLI tool gekeken naar de device list en daar kwam uit dat de normale disks als legacy disks herkend worden. De raid disks worden echter als uninitialized gezien. Dit houdt in dat de schijven eerst geinitialiseerd moeten worden, en dus alle bestaande data om zeep geholpen wordt. Bovendien zou je dan een afhankelijk van de hardware zijn en dat is nou net de reden waarom ik voor software raid gekozen had.

Nu doemen er een aantal vragen op waarop ik geen antwoord kan vinden; Hoe kan ik de bestaande raid gebruiken icm de rocketraid? Waarom doet de sata_mv driver het niet? Waarom is de Highpoint driver blijkbaar nodig als dit bij de Promise ook niet nodig was? Hoe krijg ik de raid als normale devices zodat mdadm ze kan assemblen en ik ze kan mounten? Etc..

Moraal van het verhaal is dat ik compleet vast zit en geen idee meer heb hoe nu verder....

PS, het is een Debian testing systeem met de laatste stabiele kernel (2.6.21.3).

[Verwijderd]

Voor de zekerheid: je wilt dus puur software RAID gebruiken, ook op je highpoint, dus je gebruikt niet de RAID van promise of highpoint, correct?

[Verwijderd]

Klopt, het gaat puur om de SATA poorten om schijven op aan te sluiten. Software raid doet de rest.

[ Voor 42% gewijzigd door Verwijderd op 27-05-2007 14:34 ]

[iceheart]

waarom dan zo'n relatief duur kaartje?

[Verwijderd]

Was de enige enigzins verkrijgbare 8 poorts kaart. Daaronder zit je aan 4 poorten, welke wel een stuk goedkoper zijn, maar elk een slot in beslag nemen. Als alle bays vol zitten, is het totaal 17 SATA poorten, oftwel 4 4-poorts kaarten + 1 onboard. Dat gaat uiteraard weer voor andere problemen zorgen, bijv kaarten die niet samenwerken.
Andere 8-poorts oplossingen zijn gelijk echte raid kaarten en dan zit je 2x zo duur. Dus ik zit min of meer vast aan highpoint voor een relatief goedkope oplossing.

[Verwijderd]

Owkeej, nu gaat er toch echt ff een lichtje uit.... Als test heb ik 2 andere disks gepakt en daar een RAID1 opgezet. RAID1 omdat ik maar 2 disks kon sparen en omdat RAID1 net als RAID5 door de highpoint kaart eerst zou moeten initializen, in tegenstelling tot RAID0 of JBOD.

Net klaar met builden, gereboot en guess what? Ze duiken netjes op in /dev en ik kan ze zonder problemen mounten.... nu snap er ik er dus helemaal niets meer van. Enige verschil is dat het builden van deze array gedaan is met de schijven aan de highpoint en de bestaande niet herkende RAID5 destijds met 3 schijven aan de Promise gebuild is. De 4e schijf is later via onboard toegevoegd (mocht je je afvragen waarom niet aan de 4e poort van de Promise, dan hing de Promise het hele systeem. Blijkbaar kan die geen 4x 500GB schijven aan).

[Verwijderd]

Ik denk dat ik het probleem gevonden heb! Volgens fdisk zijn de partitietabellen ongeldig. En dat is nou juist waar de Highpoint kaart naar schijnt te kijken om te bepalen of het een legacy disk of niet is. Zo zijn de 2 disken waar mee getest is gemarkeerd als 0xFD (= linux raid autodetect). Dat verklaard waarschijnlijk waarom die wel werken en de oude raid niet.
Op dit moment run fsck al een tijd en als daar niets uitkomt zit ik eraan te denken disk voor disk te fixen. Het is RAID5, dus ik neem aan dat als ik er een disk uithaal, die fix vervolgens de array rebuild, volgende disk, enz uiteindelijk de boel moet gaan werken zoals de bedoeling is. Enige nadeel hiervan is het rebuilden ruim 13 uur duurt. Dit zou inhouden dat 4 disken fixen 4x 13 uur = minimaal 52 uur gaat duren

Iemand andere suggesties om de partitietabellen te fixen? En enig idee waarom dit nooit een probleem is geweest?

Ook heb ik inmiddels een ander nadeel gevonden. De Highpoint en Promise kaart gaan niet samen. Het systeem hangt voordat grub geladen wordt. Zit er maar 1 van de 2 kaarten in werkt het wel.

[ Voor 9% gewijzigd door Verwijderd op 27-05-2007 21:11 ]

[Verwijderd]

En weer nieuwe informatie. Zoals het er nu naar uitziet is het deels een software probleem. Bij het uitvoeren van m'n vorige ingeving kwam er namelijk weer wat bovendrijven. Het zou best wel eens kunnen dat ik destijds de raid met schijven heb gemaakt i.p.v. partities (dus dmv /dev/sdb ipv /dev/sdb1). Er zijn dus geen parities, en dus geen partitietabel. Voor mdadm maakt dat niet uit, maar voor de Highpoint dus wel. Klinkt logisch he?

Komen we bij het volgende probeersel; 1 disk verwijderd, gepartitioneerd als raid autodetect en weer toegevoegd aan de array. Voor het toevoegen is de partitietabel goed, echter direct na het toevoegen niet meer. Hierbij werd de schijf als complete disk toegevoegd (dus /dev/sdb). Ok, dit is dus niet de oplossing.
Vervolgens opnieuw gepartitioneerd voor een 2e poging. Maar nu als partitie ipv de complete disk (dus /dev/sdb1). Helaas... dit kan niet omdat deze blijkbaar te klein is:

sdb:...488386496
sdb1: 488384001

Zie het verschil, een hele disk heeft net iets meer blocks dan een partitie welke de hele schijf in beslag neemt... Weer een een doodlopende weg... *zucht*

PS, ik blijf gewoon doorlullen. Ook al reageerd er niet altijd iemand, wellicht heeft iemand anders iets aan dit hele verhaal

[Verwijderd]

Goed, laatste post wat dit betreft. Het is gelukt alle data op andere schijven te proppen en de hele raid opnieuw op te bouwen, dit maal met partitietabel. De conclusie is dat het niets uitmaakt. Zodra de array als ext3 geformateerd wordt, raakt de Highpoint kaart de kluts kwijt. Dus er zit niets anders op dan de kaart terug te sturen en m'n geld terug te vragen.

Kortom ik ben dus weer terug bij af, op zoek naar een betaalbare kaart met 8 SATA poorten.... Suggesties?

[Verwijderd]

Ik heb je hele monoloog niet gevolgd, maar overschrijf je niet perongeluk metadata van de controller? De laatste (paar) sector(s) van een disk worden door je controller gebruikt om metainformatie op te slaan (zoals of de schijf uitmaakt van een RAID array). In Linux en BSD kun je die informatie overschrijven waarna de controller over de zeik gaat bij een reboot. Is dit soms je probleem?

Je posts lezende kan ik niet echt duidelijk opmaken wat voor probleem je nu precies hebt. Misschien nog eens sumarizen?

[ Voor 13% gewijzigd door Verwijderd op 29-05-2007 00:11 ]

[waterking]

Effe een vraag tussen door. Binnenkort wil ik ook een raid setup gaan bouwen met daarop ubuntu feisty fawn. Nu heb ik het gewoon geïnstalleerd op een enkele schijf, maar ik wil er een raid 5 opstelling van maken. Nu lees ik overal en nergens dat je raid 5 met linux softwarematig kunt doen. Ik heb 4sata poorten op mijn moederbord en heb er maar 2 van nodig. Is het dan slim om nog een extra raid controller te kopen, voor puur de extra hardwarematige snelheid ? of kan ik gewoon zonder die raid controller softwarematig raid 5 draaien ?

[Verwijderd]

waterking schreef op dinsdag 29 mei 2007 @ 18:11:
Ik heb 4sata poorten op mijn moederbord en heb er maar 2 van nodig.

Je bedoelt dat de rest van je schijven via PATA gaan?

Is het dan slim om nog een extra raid controller te kopen, voor puur de extra hardwarematige snelheid ? of kan ik gewoon zonder die raid controller softwarematig raid 5 draaien ?

Een losse RAID controller zal waarschijnlijk iets langzamer zijn, je moet juist je onboard connectoren gebruiken, op voorwaarde dat die rechtstreeks op je chipset zijn aangesloten (via een embedded bus). Als het via PCI moet lopen heb je een hogere latency en bij blocking I/O dus mindere performance, omdat gewacht moet worden tot de request is voltooid. Dit is nog totaal afgezien van de lagere bandbreedte van PCI.

[waterking]

Ok, klinkt beetje ingewikkeld.
Maar ik heb alleen s-ata schijven. Ben ik dan een raid controller nodig ?

[Verwijderd]

Wat is het probleem? Hoeveel schijven heb je?

Je zegt je hebt 2 schijven op de SATA controller nodig, maar met 2 schijven heb je geen (volwaardige) RAID5. Dus dan neem ik aan dat je bedoelt dat je ook nog 2 andere PATA schijven hebt, wat 4 schijven maakt die je in RAID5 kan zetten. Pas bij 3 of 4 schijven heeft RAID5 voordeel.

En je moet pas een los kaartje kopen als de aansluitingen op je moederbord op zijn, die zijn namelijk het snelst.

[Verwijderd]

Verwijderd schreef op dinsdag 29 mei 2007 @ 00:09:
Je posts lezende kan ik niet echt duidelijk opmaken wat voor probleem je nu precies hebt. Misschien nog eens sumarizen?

Hmmz, door alle experimenten is het er iid niet duidelijker op geworden. Maar gelukkig is er ook goed nieuws. Het probleem is inmiddels opgelost!

Het probleem bleek uit 2 delen te bestaan. De controller heeft een geldige partitietabel nodig om te bepalen of het om bestaande data gaat of dat het een eigen Highpoint partitie is. Dit was inmiddels duidelijk en staat ook op min of meer verkapte wijze in de manual.
Het 2e deel zorgde voor onverklaarbaar gedrag. Je begint van scratch en toch kwam hert zwikje weer in oude staat terug. Wat bleek nu, de super-blocks van de oude raid bestonden nog, zelfs na een ext3 format. Zodra er gerestart werd detecteerde de kernel de oude blocks en draaide de wijzigingen terug. Hierdoor werd de paritietabel weer verminkt, en dus kon de controller er niets meer mee.

De oplossing bleek te liggen in niet alleen het partitioneren en formatteren, maar ook een mdadm --zero-superblock /dev/sdb uit te voeren, voor elke disk natuurlijk. Alleen dan is alle oude raid informatie echt weg. Vervolgens kun je van de grond af opnieuw de boel opbouwen, alleen dit maal blijven de wijzigingen wel. En sinds nu net is het weer up and running