"alter" fileserver mit software raid5 ???
- Ersteller dsred
- Erstellt am
dsred
Vice Admiral Special
hallo leute,
ich plane gerade einen fileserver aufzusetzten, der per samba und nfs daten für ein kleines netzwerk liefern soll. folgende "alte" hardware ist dafür vorhanden:
epox mvp3g2
amd k62+ (550 MHz, 128kB L2-Cache)
256 mb sdram
highpoint 454 (4-kanal ide-controller)
4x samsung sp1604n (4x160gb)
os: debian [testing]
nun ist zwar die einfachste möglichkeit das ganze entweder normal einzubinden, in dem man das pseudo-software-raid5 des controllers nutzt (mit den von highpoint gebotenen treibern), da das aber auch nur ein software raid ist, würde ich eher die vom kernel zur verfügung gestellten software raid optionen nutzen wollen.
meine frage ist nun: hat jemand von euch mit linux software raid5 erfahrung, insbesondere in bezug auf stabilität, verlässlichkeit und wiederherstellbarkeit. und reicht die oben angegebene maschine für eine derartige aufgabe. es kommt hier nicht auf das letzte MB/s an. jedoch sollte die maschine bei schreib- und lese-zugriffen mindest. ein 100MBit-Netzwerk beliefern können und dabei verlässlich laufen. (ein bißchen puffer wäre natürlich nicht schlecht.)
die alternative wäre natürlich ein raid 0+1, was mir aber aufgrund der verlorenen 160GB im vgl. zu raid 5 weniger zusagen würde (480GB vs. 320GB), oder die platten einzeln einzubinden (640GB, ohne ausfallsicherheit einer platte)
bin auf eure meinung gespannt. hab auch schon gegoogelt, da gibt es aber durchaus widersprüchliche meinungen/erfahrungen zu dem thema. also laßt euch bitte kräftig aus und wenn ihr links habt immer her damit.
besten dank,
dsred
ich plane gerade einen fileserver aufzusetzten, der per samba und nfs daten für ein kleines netzwerk liefern soll. folgende "alte" hardware ist dafür vorhanden:
epox mvp3g2
amd k62+ (550 MHz, 128kB L2-Cache)
256 mb sdram
highpoint 454 (4-kanal ide-controller)
4x samsung sp1604n (4x160gb)
os: debian [testing]
nun ist zwar die einfachste möglichkeit das ganze entweder normal einzubinden, in dem man das pseudo-software-raid5 des controllers nutzt (mit den von highpoint gebotenen treibern), da das aber auch nur ein software raid ist, würde ich eher die vom kernel zur verfügung gestellten software raid optionen nutzen wollen.
meine frage ist nun: hat jemand von euch mit linux software raid5 erfahrung, insbesondere in bezug auf stabilität, verlässlichkeit und wiederherstellbarkeit. und reicht die oben angegebene maschine für eine derartige aufgabe. es kommt hier nicht auf das letzte MB/s an. jedoch sollte die maschine bei schreib- und lese-zugriffen mindest. ein 100MBit-Netzwerk beliefern können und dabei verlässlich laufen. (ein bißchen puffer wäre natürlich nicht schlecht.)
die alternative wäre natürlich ein raid 0+1, was mir aber aufgrund der verlorenen 160GB im vgl. zu raid 5 weniger zusagen würde (480GB vs. 320GB), oder die platten einzeln einzubinden (640GB, ohne ausfallsicherheit einer platte)
bin auf eure meinung gespannt. hab auch schon gegoogelt, da gibt es aber durchaus widersprüchliche meinungen/erfahrungen zu dem thema. also laßt euch bitte kräftig aus und wenn ihr links habt immer her damit.
besten dank,
dsred
thermoman
Vice Admiral Special
- Mitglied seit
- 14.03.2002
- Beiträge
- 598
- Renomée
- 11
Hi,
ich fahre seit einem Monat ein Software-RAID5 unter 2.6.9 mit 4x80GB Samsung Platten. Wenn Du auf Windows auf der Kiste nicht angewiesen bist, solltest Du unbedingt zum Linux Software-RAID greifen anstatt zu den meist schlampigen Treibern der Hersteller. Der Vorteil: Wenn Dir der Controller verreckt und es keinen dieses Modells mehr gibt, sind deine Daten verloren. Beim Linux Software-RAID kannst Du davon ausgehen, daß das noch eine ganze Weile/immer kompatibel bleibt.
Hatte bisher nur ein einziges Problem mit dem RAID - war gerade dabei das nur mit 3 Platten laufenden degraded RAID-5 wieder um eine 4. Platte zu bereichern, der Recovery lief schon seit ner halben Stunde und dann bei ca. 80% war der Kernel der Meinung, auf einer der drei Platten einen Lesefehler erkannt zu haben und hat diese Platte dann mal eben aus dem Array gekickt. Resultat: Die Kiste blieb stehen, nix ging mehr, nur noch ein harter Reset.
Beim booten war natürlich nix mehr mit dem RAID5, durfte dann von LiveCD booten und per Hand mit mdadm und --force das Array wieder manuell zusammenbasteln. Aber: es gingen keine Daten verloren, es lief danach wieder als wäre nix gewesen!
Wenn dein fileserver sonst nix weiter macht sollten die 550 MHz eigentlich reichen.
Gruß,
thermoman
ich fahre seit einem Monat ein Software-RAID5 unter 2.6.9 mit 4x80GB Samsung Platten. Wenn Du auf Windows auf der Kiste nicht angewiesen bist, solltest Du unbedingt zum Linux Software-RAID greifen anstatt zu den meist schlampigen Treibern der Hersteller. Der Vorteil: Wenn Dir der Controller verreckt und es keinen dieses Modells mehr gibt, sind deine Daten verloren. Beim Linux Software-RAID kannst Du davon ausgehen, daß das noch eine ganze Weile/immer kompatibel bleibt.
Hatte bisher nur ein einziges Problem mit dem RAID - war gerade dabei das nur mit 3 Platten laufenden degraded RAID-5 wieder um eine 4. Platte zu bereichern, der Recovery lief schon seit ner halben Stunde und dann bei ca. 80% war der Kernel der Meinung, auf einer der drei Platten einen Lesefehler erkannt zu haben und hat diese Platte dann mal eben aus dem Array gekickt. Resultat: Die Kiste blieb stehen, nix ging mehr, nur noch ein harter Reset.
Beim booten war natürlich nix mehr mit dem RAID5, durfte dann von LiveCD booten und per Hand mit mdadm und --force das Array wieder manuell zusammenbasteln. Aber: es gingen keine Daten verloren, es lief danach wieder als wäre nix gewesen!
Wenn dein fileserver sonst nix weiter macht sollten die 550 MHz eigentlich reichen.
Gruß,
thermoman
dsred
Vice Admiral Special
schön das sich noch jemand gemeldet hat. und dann hört sich das auch noch vielversprechend an.
ich bin gerade dabei die kiste aufzusetzen, wird aber wohl noch etwas dauern.
werde vermutlich schon auf das software-raid 5 von linux zurückgereifen, aus den eben von dir genannten gründen. werde aber dennoch mal den highpoint-treiber eine chance geben und den mal versuchen.
bevor der file-server richtig zum einsatz kommt, werde ich das ganze eh noch ausführlich testen. kritisch erscheint mir nur die cpu. aber ich wollte halt auch nicht, eine total überdimensionierte heizung aufbauen. und die hardware war halt greifbar und muß auch sonst nichts erledigen als das netzwerk bedienen.
also besten dank nochmal. ich melde mich dann nochmal, wenn ich die kiste mal ausgetestet habe.
gruß dsred
ich bin gerade dabei die kiste aufzusetzen, wird aber wohl noch etwas dauern.
werde vermutlich schon auf das software-raid 5 von linux zurückgereifen, aus den eben von dir genannten gründen. werde aber dennoch mal den highpoint-treiber eine chance geben und den mal versuchen.
bevor der file-server richtig zum einsatz kommt, werde ich das ganze eh noch ausführlich testen. kritisch erscheint mir nur die cpu. aber ich wollte halt auch nicht, eine total überdimensionierte heizung aufbauen. und die hardware war halt greifbar und muß auch sonst nichts erledigen als das netzwerk bedienen.
also besten dank nochmal. ich melde mich dann nochmal, wenn ich die kiste mal ausgetestet habe.
gruß dsred
Cybered
Admiral Special
zwar nix zum thema...aber die CPU ist eigentlich zu schade um in nem Fileserver zu "malochen" 
In ner Vitrine würde die sich besser machen
Cybered
In ner Vitrine würde die sich besser machen
Cybered
dsred
Vice Admiral Special
ach die cpu kann auf ihre alten tage ruhig noch was arbeiten, sonst weiß sie mit ihrer zeit eh nichts anzufangen und so in einer vitrine eingesperrt von allen begafft zu werden, ist doch schon fast tier- äh cpu-quälerei. da mag sie ihre natürliche umgebung deutlich lieber 
.
aber mal wieder zum thema:
es scheint sich herauszustellen, dass die highpoint-treiber performance-technisch tatsächlich besser sind (mich wundert´s selber), erzeugen allerdings auch deutlich mehr cpu-last (aber das ist ja ok). genaueres später (vermutlich einiges später )
hab mal hier auf die schnelle die bonnie++ werte (bonnie++ -s 500M):
hpt374-v2.12
Version 1.03 ------Sequential Output------ --Sequential Input---Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block----Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec%CP
server 500M 3795 96 20500 83 14069 32 4377 96 50564 63 136.51
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec%CP
16 531 97 +++++ +++ +++++ +++ 561 98 +++++ +++ 2137 98
server,500M,3795,96,20500,83,14069,32,4377,96,50564,63,136.5,1,16,531,97,+++++,+++,+++++,+++,561,98,+++++,+++,2137,98
linux software raid5:
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec%CP
server 500M 1937 51 17242 32 12515 25 2164 54 16780 22 59.23
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec%CP
16 200 54 +++++ +++ 16838 57 198 63 +++++ +++ 773 59
server,500M,1937,51,17242,32,12515,25,2164,54,16780,22,59.2,3,16,200,54,+++++,+++,16838,57,198,63,+++++,+++,773,59
dann noch einen schönen abend
dsred
.aber mal wieder zum thema:
es scheint sich herauszustellen, dass die highpoint-treiber performance-technisch tatsächlich besser sind (mich wundert´s selber), erzeugen allerdings auch deutlich mehr cpu-last (aber das ist ja ok). genaueres später (vermutlich einiges später
)hab mal hier auf die schnelle die bonnie++ werte (bonnie++ -s 500M):
hpt374-v2.12
Version 1.03 ------Sequential Output------ --Sequential Input---Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block----Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec%CP
server 500M 3795 96 20500 83 14069 32 4377 96 50564 63 136.51
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec%CP
16 531 97 +++++ +++ +++++ +++ 561 98 +++++ +++ 2137 98
server,500M,3795,96,20500,83,14069,32,4377,96,50564,63,136.5,1,16,531,97,+++++,+++,+++++,+++,561,98,+++++,+++,2137,98
linux software raid5:
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec%CP
server 500M 1937 51 17242 32 12515 25 2164 54 16780 22 59.23
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec%CP
16 200 54 +++++ +++ 16838 57 198 63 +++++ +++ 773 59
server,500M,1937,51,17242,32,12515,25,2164,54,16780,22,59.2,3,16,200,54,+++++,+++,16838,57,198,63,+++++,+++,773,59
dann noch einen schönen abend
dsred
Der arme K6-2 schaffts doch gerade mal ne 100 MBit-Karte auszulasten, dann willst du den noch mit nem Soft-RAID 5 quaelen? Selbst mit aktuellen CPUs kann man die Write-Performance vergessen, bei dem K6 duerften so maximal 2-3 MB/Sec durchkommen, wenn ueberhaupt.
Selbst mit aktuellen CPUs kann man die Write-Performance vergessen, bei dem K6 duerften so maximal 2-3 MB/Sec durchkommen, wenn ueberhaupt.dsred
Vice Admiral Special
also ganz so übel wie du das darstellst ist es nicht. per nfs kommt man beim schreiben auf das raid5 immerhin auf 7-8 MB/s. beim lesen sind es knapp über 10 MB/s. und das mehr oder weniger out-of-the-box im schnelltest.
was allerdings doch noch schwächelt ist samba. da liegt die übertragungsrate beim schreiben auf das raid5 bei ca. 5 MB/s und beim lesen bei ca. 6-7 MB/s. halte ich aber beides für etwas niedrig. muss mal schauen, ob man da noch etwas drehen kann, vor allem weil die cpu hier auch nicht richtig ausgelastet wird.
also wenn ich die samba-performance noch etwas verbessern kann, kann ich damit durchaus leben.
gruß dsred
was allerdings doch noch schwächelt ist samba. da liegt die übertragungsrate beim schreiben auf das raid5 bei ca. 5 MB/s und beim lesen bei ca. 6-7 MB/s. halte ich aber beides für etwas niedrig. muss mal schauen, ob man da noch etwas drehen kann, vor allem weil die cpu hier auch nicht richtig ausgelastet wird.
also wenn ich die samba-performance noch etwas verbessern kann, kann ich damit durchaus leben.
gruß dsred
thermoman
Vice Admiral Special
- Mitglied seit
- 14.03.2002
- Beiträge
- 598
- Renomée
- 11
Also ich schaffe mit meinem Software-RAID5 beim Schreiben 68MB/s, was ich eigentlich ganz ordentlich finde. Als Prozessor werkelt in meinem Mutterbrett ein XP1700+, der durch das RAID zu ca. 3-4% belastet wird, also jenseits der 100%.
Gruß,
thermoman
Gruß,
thermoman
dsred
Vice Admiral Special
wow, das finde ich auch recht ordentlich 
aber wie gesagt, bei mir sieht es wohl so aus, als ob das linux-soft-raid5 nicht mit den highpoint ("soft-raid5") treibern mithalten kann, aber evtl. mache ich auch was falsch, weil ich mir das einfach nicht vorstellen kann.
gruß dsred
aber wie gesagt, bei mir sieht es wohl so aus, als ob das linux-soft-raid5 nicht mit den highpoint ("soft-raid5") treibern mithalten kann, aber evtl. mache ich auch was falsch, weil ich mir das einfach nicht vorstellen kann.
gruß dsred
thermoman
Vice Admiral Special
- Mitglied seit
- 14.03.2002
- Beiträge
- 598
- Renomée
- 11
4x Samsung SATA SP0812C sowie DFI Lanparty NFII Ultra B mit Sil 3114
Software-RAID5 wohlgemerkt.
Gerade nochmal geschaut - also das Parity-Berechnen nimmt scheinbar wirklich nur so wenig CPU in anspruch, allerdings pdflush umso mehr:
das war dd if=/dev/zero of=/irgendwo/auf/raid5
Gruß,
thermoman
Software-RAID5 wohlgemerkt.
Gerade nochmal geschaut - also das Parity-Berechnen nimmt scheinbar wirklich nur so wenig CPU in anspruch, allerdings pdflush umso mehr:
Code:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8212 root 25 0 3656 412 3500 R 76.0 0.0 0:38.27 dd
41 root 15 0 0 0 0 S 14.4 0.0 0:04.64 pdflush
43 root 15 0 0 0 0 S 2.5 0.0 0:00.88 kswapd0
738 root 15 0 0 0 0 S 2.5 0.0 0:02.41 md3_raid5das war dd if=/dev/zero of=/irgendwo/auf/raid5
Gruß,
thermoman
Zuletzt bearbeitet:
dsred
Vice Admiral Special
wollte nur noch mal nachtragen, dass ich bei meinen ersten linux softraid 5 test beim bonnie++ bench einen nicht unwesentlcihen fehler gemacht habe. im hintergrund lief noch die synchronisierung!!!
so wie sich das jetzt darstellt ist das linux softraid knapp schneller als die highpoint-treiber, so dass ich unter berücksichtigung der von thermoman genannten vorzüge wohl dabei hängen bleibe.
im augenblick spiele ich noch ein bißchen mit der chunk-size und den file-systemen und formatierungsoptionen herum, weil man da wohl auch noch ein bißchen was an performance herauskitzeln kann. im augenblick liegt die dauer-schreibrate der kiste bei fast 18 MB/s (schreiben auf raid5), via nfs bei fast 9 MB/s und samba bei gut 7 MB/s (alles nur mal ganz grob mittels time cp große.datei raid5)
bin also insgesamt ganz zucersichtlich gestimmt, was das projekt "alter file-server mit software raid5" betrifft.
ich meld mich dann nochmal, wenn ich das projekt abgeschlossen habe. aber ich befürchte das wird aufgrund von zeitmangel noch etwas dauern.
aber nochmals besten dank für all eure kommentare
gruß dsred
so wie sich das jetzt darstellt ist das linux softraid knapp schneller als die highpoint-treiber, so dass ich unter berücksichtigung der von thermoman genannten vorzüge wohl dabei hängen bleibe.
im augenblick spiele ich noch ein bißchen mit der chunk-size und den file-systemen und formatierungsoptionen herum, weil man da wohl auch noch ein bißchen was an performance herauskitzeln kann. im augenblick liegt die dauer-schreibrate der kiste bei fast 18 MB/s (schreiben auf raid5), via nfs bei fast 9 MB/s und samba bei gut 7 MB/s (alles nur mal ganz grob mittels time cp große.datei raid5)
bin also insgesamt ganz zucersichtlich gestimmt, was das projekt "alter file-server mit software raid5" betrifft.
ich meld mich dann nochmal, wenn ich das projekt abgeschlossen habe. aber ich befürchte das wird aufgrund von zeitmangel noch etwas dauern.
aber nochmals besten dank für all eure kommentare
gruß dsred
thermoman
Vice Admiral Special
- Mitglied seit
- 14.03.2002
- Beiträge
- 598
- Renomée
- 11
Hi,
bzgl. ext3 ist das hier ganz lesenswert:
http://www.tldp.org/HOWTO/Software-RAID-HOWTO-5.html#ss5.11
Merke: blocksize * stride = chunksize bzw. stripesize.
Habe bei mir 128kB als stripe-size gewählt, in Kombination mit 4kB Blocksize auf ext3 waren es dann stride=32 bei mkfs.ext3.
thermoman
bzgl. ext3 ist das hier ganz lesenswert:
http://www.tldp.org/HOWTO/Software-RAID-HOWTO-5.html#ss5.11
Merke: blocksize * stride = chunksize bzw. stripesize.
Habe bei mir 128kB als stripe-size gewählt, in Kombination mit 4kB Blocksize auf ext3 waren es dann stride=32 bei mkfs.ext3.
thermoman
Auf meinem großen Rechner läuft momentan ein Software-RAID1 und nachdem das super geklappt hat werd ich auf meinem Fileserver auch ein Raid5 zusammensetzen.
Da steckt ein Cyrix M2 225MHz drinnen, der das aber auch noch packen wird. Interessant ist am Anfang der Test zu den verschiedenen Paritätsalgorithmen, der Cyrix packt dabei 450 MB/s - sollte ausreichen.
Da steckt ein Cyrix M2 225MHz drinnen, der das aber auch noch packen wird. Interessant ist am Anfang der Test zu den verschiedenen Paritätsalgorithmen, der Cyrix packt dabei 450 MB/s - sollte ausreichen
.dsred
Vice Admiral Special
@thermoman
besten dank, genau an den parametern spiele ich gerade herum. und so wie aussieht ist eine chunk-size von 128k performance-mäßig wohl am besten. jetzt wollte ich abschließend nur noch die filesysteme xfs, reiserfs und ext3 vergleichen.
@i_hasser
ich will dich nicht abschrecken. aber der Cyrix M2 225MHz könnte für ein raid 5 doch etwas unterdimensioniert sein, wenn du damit ein 100MBit-Netzwerk auslasten möchtest. bei meinem K6-2+ kommen beim Test der Paritätsalgorithmen für den besten algoryhtmus (pII_mmx) ~1200MB/s raus, woraus die oben angegeben datenraten resultieren. mit dem letzten rest an feinabstimmung wird die samba-performance vielleicht noch ein bißchen steigen, so dass der server das netzwerk wirklich beliefern kann, aber wie gesagt ich vermute, dass meine hardware so die untere grenze für ein raid 5 darstellt.
was die situation ändern/verbessern könnte, wären vielleicht scsi-platten. ich meine bei den howto's, foren-beiträgen usw. die ich so gelesen habe, dass das linux-soft-raid wohl auf derartigen platten noch mal bessr performen soll. aber ich habe dafür natürlich keine bestätigung.
und entmutigen will ich dich natürlich auch nicht. probier es am besten mal aus. kostet dich halt ein bißchen zeit
gruß dsred
besten dank, genau an den parametern spiele ich gerade herum. und so wie aussieht ist eine chunk-size von 128k performance-mäßig wohl am besten. jetzt wollte ich abschließend nur noch die filesysteme xfs, reiserfs und ext3 vergleichen.
@i_hasser
ich will dich nicht abschrecken. aber der Cyrix M2 225MHz könnte für ein raid 5 doch etwas unterdimensioniert sein, wenn du damit ein 100MBit-Netzwerk auslasten möchtest. bei meinem K6-2+ kommen beim Test der Paritätsalgorithmen für den besten algoryhtmus (pII_mmx) ~1200MB/s raus, woraus die oben angegeben datenraten resultieren. mit dem letzten rest an feinabstimmung wird die samba-performance vielleicht noch ein bißchen steigen, so dass der server das netzwerk wirklich beliefern kann, aber wie gesagt ich vermute, dass meine hardware so die untere grenze für ein raid 5 darstellt.
was die situation ändern/verbessern könnte, wären vielleicht scsi-platten. ich meine bei den howto's, foren-beiträgen usw. die ich so gelesen habe, dass das linux-soft-raid wohl auf derartigen platten noch mal bessr performen soll. aber ich habe dafür natürlich keine bestätigung.
und entmutigen will ich dich natürlich auch nicht. probier es am besten mal aus. kostet dich halt ein bißchen zeit
gruß dsred
Naja, wenn das keine 10MB/s werden ist das auch net schlimm. Aber ich bin da recht zuversichtlich, da kommt nämlich ein 3Com 100MBit NIC rein und die sind in der Regel sehr viel weniger CPU belastend als die Realtek Sch***dinger.
Die HDDs selbst dürften über 10MB/s nur müde lächeln.
Außerdem benutz ich kein Samba, sondern FTP. Das dürfte etwas weniger CPU belastend sein.
Die HDDs selbst dürften über 10MB/s nur müde lächeln
.Außerdem benutz ich kein Samba, sondern FTP. Das dürfte etwas weniger CPU belastend sein.
dsred
Vice Admiral Special
einen 3com-nic benutze ich auch schon. nichts desto trotz würde mich sehr interessieren, wie dein projekt dann vorangeht, bzw. ob dir das performance-mäßig ausreicht. also wenn du deine erfahrungen hier postet, würde ich mich das sehr freuen.
gruß dsred
gruß dsred
![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
.dsred
Vice Admiral Special
16.12.2004
noch mal ein problem mit linux-softraid 5:
nachdem ich so langsam mit meinen linux-soft-raid5 tests gegen ende und alles nach meinen
vorstellungen eingerichtet war, mußte ich feststellen, dass das raid5 sehr anfällig ist.
beim kopieren meiner daten auf das array, bekam ich plötzlich einen dma-error auf einer
der 4 platten was als sofortiger ausfall der platte interpretiert wurde. daraufhin hab ich
natürlich die gesamte platte getestet (hutil von samsung), sowie wie ein neues kabel
benutzt
--> keine fehler, platte und kabel in ordnung.
also array neu synchonisiert, und das spiel ging von vorne los. erneuter dma-fehler....
ich vermute mal das hier irgendetwas mit den im kernel integrierten hpt-treiber nicht ganz
in ordnung ist. also wenn einer von euch noch einen highpoint-raid-controller unter linux
benutzt und zwar mit den linux-ide treiber, könnte er mal seine erfahrungen posten.
17.12.2004:
da ich so langsam mal zu potte kommen wollte, hab ich mich jetzt endgültig für die
opensource-treiber von highpoint entschieden, die sich performance-mäßig im prinzip nicht
von dem linux-softraid unterscheiden, dafür aber weniger flexibel sind. bis jetzt sind sie
allerdings problemloser. Ein weiterer Vorteil der noch für die highpoint-treiber spricht,
ist das der hersteller ein programm mitliefert, mit dem man das raid-array von jedem
beliebigen rechner fernwarten kann.
18.12.2004 - benchmark:
mit anpassung der stripe-size auf 128kB und xfs als file-system wird das netzwerk absolut
gut bedient. per NFS kommt der Server mit fast 10 MB/s schon fast an das maximum dessen
was möglich ist. und auch bei samba kann man wohl bei einer dauertranferrate beim kopieren
großer dateien von knapp über 9 MB/s nicht wirklich meckern.
hier noch zwei benchmarks:
>bonnie++ -s 1040
habe nun alle daten auf dem server liegen (zur not aber noch ein backup, falls es noch
probleme geben sollte) und genieße das wochenende.
-> projekt software-raid5 auf altem server bis auf weiteres erfolgreich abgeschlossen !!!
ich danke nochmal für eure kommentare und hilfestellungen und wünsche ein schönes wochenende.
gruß dsred
noch mal ein problem mit linux-softraid 5:
nachdem ich so langsam mit meinen linux-soft-raid5 tests gegen ende und alles nach meinen
vorstellungen eingerichtet war, mußte ich feststellen, dass das raid5 sehr anfällig ist.
beim kopieren meiner daten auf das array, bekam ich plötzlich einen dma-error auf einer
der 4 platten was als sofortiger ausfall der platte interpretiert wurde. daraufhin hab ich
natürlich die gesamte platte getestet (hutil von samsung), sowie wie ein neues kabel
benutzt
--> keine fehler, platte und kabel in ordnung.
also array neu synchonisiert, und das spiel ging von vorne los. erneuter dma-fehler....
ich vermute mal das hier irgendetwas mit den im kernel integrierten hpt-treiber nicht ganz
in ordnung ist. also wenn einer von euch noch einen highpoint-raid-controller unter linux
benutzt und zwar mit den linux-ide treiber, könnte er mal seine erfahrungen posten.
17.12.2004:
da ich so langsam mal zu potte kommen wollte, hab ich mich jetzt endgültig für die
opensource-treiber von highpoint entschieden, die sich performance-mäßig im prinzip nicht
von dem linux-softraid unterscheiden, dafür aber weniger flexibel sind. bis jetzt sind sie
allerdings problemloser. Ein weiterer Vorteil der noch für die highpoint-treiber spricht,
ist das der hersteller ein programm mitliefert, mit dem man das raid-array von jedem
beliebigen rechner fernwarten kann.
18.12.2004 - benchmark:
mit anpassung der stripe-size auf 128kB und xfs als file-system wird das netzwerk absolut
gut bedient. per NFS kommt der Server mit fast 10 MB/s schon fast an das maximum dessen
was möglich ist. und auch bei samba kann man wohl bei einer dauertranferrate beim kopieren
großer dateien von knapp über 9 MB/s nicht wirklich meckern.
hier noch zwei benchmarks:
>bonnie++ -s 1040
Code:
hpt-2.12, mit xfs:
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
fatmama 1040M 3989 94 23113 62 16500 38 4469 96 58003 58 206.1 1
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 1358 56 +++++ +++ 1505 60 1356 59 +++++ +++ 1221 55
fatmama,1040M,3989,94,23113,62,16500,38,4469,96,58003,58,206.1,1,16,1358,56,+++++,+++,1505,60,1356,59,+++++,+++,1221,55
zum vgl. mit ext3:
hpt-2.12, ext3 -b 4096, chunk-size=128, stride=32
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
server 1040M 3772 90 21047 49 13510 26 4383 96 39499 39 153.4 1
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 517 98 +++++ +++ +++++ +++ 517 98 +++++ +++ 1919 98
server,1040M,3772,90,21047,49,13510,26,4383,96,39499,39,153.4,1,16,517,98,+++++,+++,+++++,+++,517,98,+++++,+++,1919,98habe nun alle daten auf dem server liegen (zur not aber noch ein backup, falls es noch
probleme geben sollte) und genieße das wochenende.
-> projekt software-raid5 auf altem server bis auf weiteres erfolgreich abgeschlossen !!!
ich danke nochmal für eure kommentare und hilfestellungen und wünsche ein schönes wochenende.
gruß dsred
