LSI MegaRaid und Dell Perc5/i SAS/SATA PCIe [2|1]

Status
Für weitere Antworten geschlossen.
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Was ist "Trim" dieser Begriff fällt hier in der letzten Zeit häufiger, und ein Tool soll wohl auch geben.
 
Die Rechnung mit einem Fehler auf 10^14 Bits ist nicht wirklich realistisch, bei aktuellen Festplatten liegt diese Grenze bei 10^15 Bits.

Also braucht ihr euch keine Sorgen machen.


und zudem: selbst wenn bei einem rebuild mal ein bit von 10tb draufgeht... das zerstört wohl kaum den kompletten verbund. ich denke mit diesem einen defekten bit kann ich gut und gerne leben! mir doch wurscht ob auf einem bild ein pixel fehlt.. ein ausdruck läuft ohnehin nur mit einem bruchteil der pixel und ein mp3 file wirds wohl auch nicht zerstören nur wenn ihm die information eines bits fehlt. ich denke 100%tig ok sind die daten niemals, denn man hat schließlich auch bei einem single drive eine gewisse wahrscheinlichkeit dass beim beschreiben ein bit nicht korrekt geschrieben wurde.
ein gebrannte cd/dvd ist auch niemals komplett korrekt und trotzdem können die daten/filme etc hinreichend gut ausgelesen werden.
und zu behaupten: wenn ein rebuild gemacht wird, sei der komplette verbund in gefahr halte ich für eine sehr wage behauptung.
 
Was ist "Trim" dieser Begriff fällt hier in der letzten Zeit häufiger, und ein Tool soll wohl auch geben.

TRIM brauchste bei SSD, ist ein befehl den das OS beim Löschen von Daten mitschickt, dass die SSD auch weiß welche Daten nicht mehr gebraucht werden und kann diese löschen. Dadurch stehen dem Controller der SSD mehr freie, unbeschriebene Flashzellen zur verfügung, in welche einfach geschrieben werden kann, ohne einen zusätzlichen Lösch-Zyklus auszulösen -> Geschwindigkeit & Haltbarkeit von SSD wird erhöht.



@Deni: So wie ich das verstanden habe, wird bei einem rebuild ein ganzer Block zerstört, also kann es schonmal vorkommen dass z.b. ein Image nicht mehr funktioniert etc. bei dem von schlingel verlinkten User war bei einem AVI film einige sec Bildfehler.
 
Die Rechnung mit einem Fehler auf 10^14 Bits ist nicht wirklich realistisch, bei aktuellen Festplatten liegt diese Grenze bei 10^15 Bits.

Also braucht ihr euch keine Sorgen machen.

nope: datenblack zur black-serie:

<1 in 1015 <1 in 1015 <1 in 1014 <1 in 1014

nur bei den großen isset 10^15.

die greens haben alle 10^15. wahrscheinlich wegen der geringeren drehzahl
 
Echte Server setzen i.d.r auf SAS-Festplatten, diese haben dann 10^16 an Fehlertolerranz, im Fall einer 450GB/15K SAS von Hitachi.

Die Hitachi A7K1000/7K1000 hat 10^15, wie auch die E7K1000. Die 7K1000B hat 10^14.
 
Das ganze für die Samsung F1 750GB:

Reliability Specifications

Non-recoverable Read Error 1 sector in 10^15 bits
Start/Stop Cycles 50,000

Die 1tb ist identisch.
 
Ich habe da mal ne Frage zum PERC5i...

Ich habe ein Gigabyte G33-DS3R, das hat nur 1xPCIe x16 und 3xPCIe x1, aber dafür Onboardgrafik. Zur Zeit steckt eine 8800GTS drin. Sollte der Controller laufen, wenn ich die GraKa herausnehme und die Onboardgrafik benutze? (Dann brauche ich noch eine DVI-Karte, denn VGA möchte ich mir nicht antun...) Um den Pinmod komme ich wohl nicht herum, oder?

Oder soll ich mir das Experiment bei diesem Board besser sparen?

Edit: Mist, sehe gerade, dass die ADD2-Karten für DVI auch in den PCIe x16 Slot gesteckt werden müssen...
 
Zuletzt bearbeitet:
und zudem: selbst wenn bei einem rebuild mal ein bit von 10tb draufgeht... das zerstört wohl kaum den kompletten verbund. ich denke mit diesem einen defekten bit kann ich gut und gerne leben! mir doch wurscht ob auf einem bild ein pixel fehlt.. ein ausdruck läuft ohnehin nur mit einem bruchteil der pixel und ein mp3 file wirds wohl auch nicht zerstören nur wenn ihm die information eines bits fehlt. ich denke 100%tig ok sind die daten niemals, denn man hat schließlich auch bei einem single drive eine gewisse wahrscheinlichkeit dass beim beschreiben ein bit nicht korrekt geschrieben wurde.
ein gebrannte cd/dvd ist auch niemals komplett korrekt und trotzdem können die daten/filme etc hinreichend gut ausgelesen werden.
und zu behaupten: wenn ein rebuild gemacht wird, sei der komplette verbund in gefahr halte ich für eine sehr wage behauptung.
den verbund stört das auch nicht weiter (bzw. merkt der das beim rebuild ja eben nicht), aber die daten dadrauf sind dann halt beeinträchtigt. bei einem home-server spielt das ganze auch (so gut wie) keine rolle, ob da nu mal ein kurzer "blip" in einer mp3-datei ist, oder ein pixel in nem bild gelb statt grün ist. aber bei einem unternehmen, was da seine datenbanken drauf laufen lässt, siet das schon wieder ganz anders aus. wenn da durch dieses eine bit irgendwelche verweise/verknüpfungen geändert werden, kann das unter umständen die gesamte datenbank mitreißen (besonders, wenn der fehler nicht gleich auffällt). oder die gepackte oder verschlüsselte datei lässt sich dann auf einmal auch nicht mehr öffnen. in einer programm-datei kann das auch ziemlich fatale auswirkungen haben...
und da solche fehler eben auch bei einzelnen platten auftreten können, setzt man in dem fall ja gerade auf ein raid-system, das auch solche fehler erkennt, und korrigiert. und solange das raid-system läuft, ist es (fast) egal, wie viele fehler auftreten, solange sie erkannt und gleich wieder korrigiert werden. bloß wenn eben eine festplatte ausfällt, fehlt ja diese erkennung beim rebuild und der fehler kann sich unbemerkt in deinen datenbestand einschleichen. solange diese wahrscheinlichkeit bei 0,0x% lag, war das auch noch nicht so kritisch, aber inzwischen liegt die wahrscheinlichkeit bei solchen terabyte-datenmengen schon irgendwo bei 50%. das heißt, bei einem ausfall einer platte und dem anschließendem rebuild ist die wahrscheinlichkeit schon sehr hoch, daß sich irgendwo ein fehler in deine daten einschleicht, und du weißt nichtmal wo...


edit: mir fällt grad ein, kann man bei einem raid5 überhaupt einen (bit-)fehler korrigieren? woher will der raid-controller wissen, ob das falsche bit jetzt auf der "haupt"-festplatte oder der paritäts-festplatte ist?
funktioniert so eine korrektur bei einem raid6?
 
Frage:
Ich will zu den 7 Platten nun auch noch meine SSD an den Perc anschließen, wenn ich die jedoch einfach anschließe und nen Raid 0 drauß mache, wird sie erkannt, ich kann mitm andern OS drauf zugreifen, aber ich kann davon nicht booten.
Kann ich irgendwo umstellen welches Raid array quasi primär ist? Mein Raid5 is Virtual Disk0, die SSD Virtual Disk1. Wenn ich die SSD einfach annen Onboardcontroller hänge bottet er einwandfrei.
Im Bios war der Perc als 1.bootdevice drinnen...
Wie muss ichs einstellen dass ich von der SSD booten kann wenn sie am Perc hängt?


edit: grad mal nachgeschaut, auch die Samsung EcoGreen F2 hat 10^15 -> Reliability Specifications: Non-recoverable Read Error: 1 sector in 10^15 bits
 
Zuletzt bearbeitet:
du musst die platte im perc-bios noch als erste boot-platte einstellen.

edit: mir fällt grad ein, kann man bei einem raid5 überhaupt einen (bit-)fehler korrigieren? woher will der raid-controller wissen, ob das falsche bit jetzt auf der "haupt"-festplatte oder der paritäts-festplatte ist?
funktioniert so eine korrektur bei einem raid6?

ich könnte mir zwei versionen vorstellen:

- das bit wurde nur 1x falsch ausgelesen sprich die ECC der HDD hats nedd gemerkt. wenn der controller dies durch die parity-prüfung mitbekommt schätze ich er wirds einfach nochmal probieren und dann nochmal dieses bit vergleichen. spätestens dann sollte ja ECC der HDD wieder greifen. nur wenn jetzt genau derselbe inhalt gelesen würde (sehr sehr unwahrscheinlich m.m.n) hättest du nen problem. in dem fall könnte man die bits drum herum betrachten und guggen was die sagen. aber das führt ingesamt zum thema inkonsistenz und nicht zum ECC-pass-Problem

- der sektor ist komplett hinüber. das bekommt der controller auch beim nächsten mal keine/mistige daten und erkennt somit, dass der sektor schrott ist. denke das führt dann zu "unexpected sense". danach sollte die platte den sektor relokalisieren und der controller schreibt mittels der parity wieder alles sauber in den neu zugewiesenen sektor.

genau dann greift ja auch die fehlerkorektur der Platten. bzw bei Raid-Edits auch nach gewisser Zeit die des Controllers.
 
Zuletzt bearbeitet:
bis jetzt 1a, keine fehler oder macken. Zur Zeit läuft bei mir Onboardgrafik und Sound, mir hats am we mein 600w Be Quiet Netzteil zerschossen, dachte schon da wars mitm raid... aber ansonsten läuft alles tadellos. Heute neues Enermax eingebaut, werde später auch Graka + Xfi wieder einbaun (ersatz NT hat nur 250W *hust*). OC tests hab ich auch noch keine gemacht, der Perc hat immer so schön fleißig gearbeitet, nich dass da wieder was zu bruch geht ;)
Glaube wenn ich in nen paar Jahren mal wieder nen neuen Rechner zusammenbau wird das mein Server, einfach noch nen Perc in den PCIEx16 slot und man hat genug anschlüsse für nen megaraid ^^
 
So Leute,


ES IST VORBEI!


Wie die meisten sich noch erinnern können habe ich eine kleine
Irrfahrt hinter mir.

Mein erstes Board:
MSI Neo2 Digital. Lief so weit gut konnte aber nciht mehr als 4 GB RAM nutzen (obwohl im Handbuch etwas anderes steht.) Dazu kam noch, dass der Perc bzw. die BBU bei Stromausfall die Daten nicht im Cache halten konnte (Fehlermeldung). Betrieb war nur mit PIN Mod möglich

Mein zweites Board GA-MA78G-DS3H:
Ich habe mir dann das Gigabyte Board bestellt, dass auch der USer LAN benutzt. Ich wollte halt ein Board, was funktioniert und den Pin Mod nicht braucht.
Pin Mod war wirklich nicht notwendig, jedoch hatte ich nun das Problem, das der Rechner nicht mehr hochfahren wollte wenn die BBU angeschlossen war! Dies aber nur nach einem Kaltstart. Beim Warmstart war das kein Problem, obwohl ich zwischenzeitlich die LSI FM aufgespielt hatte.
Ich vermute, dass es am SMBUs lag. Denn das Board hatte beim Start kein IRQ zugewiesen bekommen. Das ist bei einigen GB Boards wohl normal (laut GB Forum).


Nun habe ich mir das ASUS M4A78-E gekauft.
UND? KEIN Problem mehr mit der BBU, 8 GB werden erkannt, PIN Mod ist nicht erforderlich, Kaltstartproblem mit der BBU ist auch weg. Einfach: Es klappt alles. Ich habe die alte Dell FW aufgespielt und nun ist auch das Warmstartproblem weg.

ES LÄUFT :-))))))))))))))))))))))))))))))))))))))))))))))

Einfach toll das Board.


Also, es ist ziemlich wichtig sich alle Spec. des Boards mal anzusehen.
Ich habe mir ja wie oben geschrieben, aufgrund der Meinung von "LAN" das Board gekauft.
Er hatte keine Problme (klar, er hatte keine BBU). Mit der BBu sieht die Sache anders aus.
Siehe meine Probleme.

EVO hat es richtig ausgedrückt, der Perc am NICHT DELL Server ist echt ne BAstellösung bzw. viel Glück ist hier auch wichtig.

Eigentlich hätte ich mir für den Arbeitsaufwand und Ärger gleich einen Dell Server kaufen können.

Nun bin ich aber zufrieden. Das Baord hat auch nocht ESATA und kann 16 GB maximal benutzen. Dazu zwei PCIe 16 Ports. Echt gut. Meine volle Empfehlung.


Danke besonders an Tekkno, Schlingel, Wadenkrampf und die anderen, die mir geholfen haben.


Grüße
 
Zuletzt bearbeitet:
So Leute,


ES IST VORBEI!


Nun habe ich mir das ASUS M4A78-E gekauft.
UND? KEIN Problem mehr mit der BBU, 8 GB werden erkannt, PIN Mod ist nicht erforderlich, Kaltstartproblem mit der BBU ist auch weg. Einfach: Es klappt alles. Ich habe die alte Dell FW aufgespielt und nun ist auch das Warmstartproblem weg.

ES LÄUFT :-))))))))))))))))))))))))))))))))))))))))))))))

Einfach toll das Board.

Nun bin ich aber zufrieden. Das Baord hat auch nocht ESATA und kann 16 GB maximal benutzen. Dazu zwei PCIe 16 Ports. Echt gut. Meine volle Empfehlung.

Grüße

schön für dich :)

hab gestern mein 2tes bestellt.
Für einen Storage Server ist es optimal. 4850e rein mit Perc und man hat ein recht günstiges & sparsames System ohne große Bastelarbeit ;)
 
Zuletzt bearbeitet:
Ehmm eine 4850 für einen Server finde ich ein wenig zuviel. Da würde ich eher eine passive 4670 empfehlen, dürfte noch sparsamer sein.

Bis denne ...
 
EVO hat es richtig ausgedrückt, der Perc am NICHT DELL Server ist echt ne BAstellösung bzw. viel Glück ist hier auch wichtig.

Hmm, dann hatte ich wohl schon eine ganze menge Glück. Bisher lief der PERC bei mir auf 3 verschiedenen Boards ohne Probleme, allerdings mit Pin-Mod. Und am Wochenende werd ich mein Glück wohl nochmal herausfordern, und den Controller auf einem MSI P7N Diamond (4x PCIe x16 :fresse:) ausprobieren.
Ich frage mich aber, warum du dich so gegen den Pin-Mod sträubst? Das ganze ist eine Sache von (einmalig) nichtmal 1 Minute, und irgendwelche Nachteile hab ich dadurch auch noch keine festgestellt... :confused:
 
Mir geht es nicht um das Abkleben. Das habe ich auch inter mir.


Was ich gelernt habe, das die Unterbrechung des SMBuses auf einigen Rehcnern / Boards zu Problmen führen kann.
Ich möchte von vorne herein diese Probleme ausschliessen und deshalb den Pin Mod
vermeiden.


Mir geht es um Problemvermeidung. UNd ein Board, was mit nur mit einem abgeklebten PIN / Perc läuft, das halte ich für suboptimal.

Ist natürlich schön für Dich, wenn alle Deine Rechner laufen (auch mit PIN MOD).
Mein Perc lief aber nicht so (ich habe die Rev.01 (villeicht ist das auch der Grund?)).
Schlingel hat ihn extra für mich an seinem Rechner getestet.

Sonst mag ich den Perc . P/L ist echt genial.


Grüße
 
wat binich froh :-)

Trag doch mal bitte die drei user / Wadenkrampf / ttom / kutjub/ auf der ersten Seite ein.
Das Board ist echn ne Empfehlung. Zu mal es zwei PCIe Ports hat.

Wenn Du dabei bist kannst Du ja auch den Hinweiss auf mein altes Board (GA-MA78G-DS3H) geben, dass es mit der BBU nicht klappt. Board Rev 1.0 (Vielleicht wichtig)

Grüße
 
Nochmal sorry für die Probleme mit der BBU, aber sowas ahnt ja keiner. :stupid: Wenn sich irgendwann mal die Chance bietet billig ne BBU mit Kabel zu schießen, werde ich das auch mal austesten. ;)
 
Das mit der BBU ist gut zu wissen, ich habe auch das GA-MA78G-DS3H und es läuft mit dem Perc5/i hervorragend, habe keinerlei Probleme beim Kalt- oder Warmstart.

Bis denne ...

---------- Beitrag hinzugefügt um 15:27 ---------- Vorheriger Beitrag war um 15:25 ----------

Ich meine doch die CPU und bist wohl bei der Graka ;)
Das Board hat doch ne OnBoard GPU :)
Upps, da habe ich wohl das kleine e übersehen. :fresse:

Bis denne ...
 
Mal ne andere Frage. Habe 5 750er Platten zu Raid 5 verknüppert. Sind also etwa 2,8GiB. Jetzt habe ich 2 virtuelle Platten darauf angelegt. Eine mit 1TiB MBR und eine mit 1,8TiB als GPT. Was passiert wenn ich eine weitere Platte hinzu füge? Vergrößern sich da beide virt. Platten gleichmäßig, oder nur die letzte virtuelle Platte?

---------- Beitrag hinzugefügt um 19:08 ---------- Vorheriger Beitrag war um 17:30 ----------

Or nee, was ist denn jetzt wieder? Ich finde den Punkt nicht mehr um das Raid zu erweitern. Also ich habe wie beschrieben 5 Disks zu Raid 5 verbunden und 2 virtuelle Festplatten drauf erstellt. Kann es sein dass man das Raid dann nicht erweitern kann wenn 2 virtuelle angelegt sind? Ich kann die 6. Festplatte nur als HotSpare markieren oder so.
Wenn dem So ist, was würde passieren wenn ich die 2. virtuelle lösche und den hinteren Platz frei lasse? Könnte ich dann erweitern?
 
Nochmal sorry für die Probleme mit der BBU, aber sowas ahnt ja keiner. :stupid: Wenn sich irgendwann mal die Chance bietet billig ne BBU mit Kabel zu schießen, werde ich das auch mal austesten. ;)

Hallo LAN,

bitte, dies ist kein Vorwurf von mir. Du warst damals so nett und hast mir meine Fragen beantwortet.

Wenn Du eine BBU hast, dann kannst Du es gerne mal testen.
Wird mich auch stark interessieren.

Mein Perc hat die Rev. a01 und das MoBO die Rev. 1.0

Kannst das ja hier reinstellen falls Du zum Test kommst.

Grüße
 
Zuletzt bearbeitet:
So, mein PERC6 geht wieder tiptop.

Habe jetzt zwei RAID 5 gemacht. Wenn ich jedoch booten will vom RAID mit dem OS drauf, kommt FAILURE BOOT DISK (oder so). Dem Controller habe ich aber die richtige VD zum booten angegeben. Ebenso steht im BIOS der COntroller als 1.boot device.

Hänge ich das RAID ab (das ohne OS) bootet er korrekt das OS.

Was da los?
 
Zuletzt bearbeitet:
hallihallo,

sehe ich das richtig, dass der Perc 5/i nicht unter 2000 SP4 läuft?

danke
 
Status
Für weitere Antworten geschlossen.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh