Großer Nachteil eines 1-Bay NAS gegenüber eines X-Bay NAS?

Sebi85

Enthusiast
Thread Starter
Mitglied seit
12.07.2005
Beiträge
2.318
Hallo zusammen,

bisher habe ich ein 2-Bay NAS. Das habe ich von 2x1 TB Raid 1 auf 2x4 TB Raid 1 getauscht und dazu eine 5 TB externe HDD auf der ich die Daten des NAS sichere. Wenn ich dann wieder die Kapazität erhöhen will, dann brauche ich wieder 2 HDDs und habe dann 2x1TB und 2x4TB HDDs herumliegen, die ich nicht wirklich mehr verwenden kann. Würde ich auf ein 1-Bay NAS umsteigen, dann müsste ich immer nur eine HDD neu kaufen und es würde auch nur eine HDD brach liegen. Mir ist klar, dass ich ohne Raid 1 natürlich eine höhere Wahrscheinlichkeit habe, Daten zu verlieren. Die Frage ist jetzt, macht das wirklich einen so großen Unterschied für Privatanwender?

Hauptverwendungszweck: Datengrab --> Zugriff per Netzlaufwerk/Handy und streaming.

Vorab vielen Dank.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Die Frage ist jetzt, macht das wirklich einen so großen Unterschied für Privatanwender?
Wenn Du nicht jederzeit, auch nach einem Festplattenausfall, auf die Daten zugreifen musst (z.B. weil Du finanziell davon abhängst) und regelmäßig Backups erstellst, dann brauchst Du kein RAID 1.

Die meisten NAS kann man aber auch so einstellen, dass ein JBOD (die Kapazität der eingebauten Festplatten wird einfach ohne Redundanz zusammengefasst) herauskommt. Ob das JBOD dann mit zusätzlich eingebauten Festplatten erweitert werden kann, hängt vom NAS ab. Manche können das, andere können das nicht.
 
Ich kann mir nicht vorstellen das Privatnutzer Daten haben auf die sie permanent Zugriff haben müssen. Raid ist kein Backup somit ist es (sofern du eben nicht immer Verfügbarkeit der Daten benötigst) sinnvoll die größtmögliche Kapazität zu nutzen und extern ein Backup zu haben.
 
Permanent muss ich nicht Zugriff drauf haben. Als mit die letzte Platte im Raid 1 abgeraucht ist, war das NAS ausgeschalten bis die neue da war. Könnte man das NAS überhaupt weiterbetreiben, wenn eine Platte fehlt? Backup mache ich natürlich bei beiden Lösungen. Dann gibt es also keinen wirlichen Grund warum man als Privatanwender ein mehrfach Bay NAS nehmen sollte?`Da fällt mir nur die höhere Lesegeschwindigkeit bei Raid 1 ein.
 
Könnte man das NAS überhaupt weiterbetreiben, wenn eine Platte fehlt?
Das ist der Sinn eines RAID mit Redundanz: wenn eine Festplatte ausfällt, sind die Daten weiterhin verfügbar.

Dann gibt es also keinen wirlichen Grund warum man als Privatanwender ein mehrfach Bay NAS nehmen sollte? Da fällt mir nur die höhere Lesegeschwindigkeit bei Raid 1 ein.
Je nachdem wie das NAS es macht, kann es sein, dass beim Lesen eine höhere Geschwindigkeit erreicht wird, es muss aber nicht sein.

Ein Grund könnte sein, dass man eben keine x Netzteile und LAN-Ports für x Festplatten haben möchte, sondern ein Netzteil und einen LAN-Port am Switch für alle Festplatten gemeinsam, z.B. weil man in der Abstellkammer nur eine Steckdose und einen LAN-Port zur Verfügung hat. Alternativ eben, wenn man mehrere Platten in ein JBOD stecken möchte, was mit 1-Bay-NAS-Geräten nicht funktioniert, oder wenn man es wirklich hochverfügbar haben möchte/muss, weil da Daten drauf sind, auf die man wirklich jederzeit zugreifen möchte/muss.
 
Ob ich jetzt ein 1-Bay-NAS oder ein x-Bay-NAS habe ist doch vom Anschließen her egal. Beider Geräte brauchen ja nur einen Stecker, oder habe ich dich nicht richtig verstanden? Hat JBOD (2x 4TB HDDs) Nachteiele gegenüber einer einfachen HDD (1x8TB)? Kann Windows 10 nicht so eine Art JBOD, in dem es mehrere HDDs zu einer zusammenfast?
 
@Sebi85
Windows kann von sich aus keine Controller bereitstellen also softwareseitig womit du das einfach per Klicks machen kannst. Wenn du ein Mainboard hast was Raid unterstützt, kannst du das dort im Bios bzw. während des Bootes einrichten. Das wird dann in Windows als ein Volume angezeigt. In deinem Fall meine ich zu erkennen das du ein NAS hauptsächlich benötigst, um im Bedarfsfall Fernzugriff darauf zu haben. Somit recht eigentlich ein 1 Bay NAS + die externe Sicherung. Würde ich mal jetzt so behaupten.
 
Du könntest auch einfach dein jetziges 2*4TB Raid1 Nas das dir ja 4 TB nutzkapazität bieten auf JBOD(wird oft auch als Raid0 bezeichnet) umstellen dann hast du 2*4TB = 8 TB und müßtest halt garncihts neu kaufen.

Wie schon geschrieben dient ein Raid 1 nur zu erhöhung der Verfügbarkeit und der Bequemlichkeit.
Für die Sicherheit der Daten ist das backup viel wichtiger.
 
Auf die Idee bin ich auch gerade gekommen :haha:

Aber Raid 0 != JBOD
Raid 0: Erhöhte Geschwindigkeit, bei einem Ausfall sind alle Daten weg
JBOD: Die Daten auf der anderen Platte kann man zum Teil retten.

Da ich aber sowieso ein Backup mache dürfte das ja egal sein.

Windows kann das aber von Haus aus, seit Win 8

Festplatten können Sie unter Windows 8 und Windows Server 2012 zu einer beliebigen Anzahl von Speicherpools zusammenfassen. Dabei ist es unerheblich, über welchen Standard die Festplatten am System betrieben werden. Speicherpools unterstützen USB, SATA und SAS (Serial Attached SCSI). Selbst unterschiedlich angeschlossene Festplatten können an einem gemeinsamen Pool betrieben werden, wobei auch hier die Größe keine Rolle spielt. Es lassen sich verschiedene Anschluss-Systeme mit verschiedenen Größen mischen und zu einem Pool zusammenfassen.
 
verkauf halt die alten platten sofern sie noch gehen^^ oder nutze sie als backup wenn die platten noch im guten zustand sind^^
 
Naja, Raid sollte doch durch Redundanz auch gehen Bitfehler auf den Platten helfen. meine ich. Das ist bei der Geschichte doch auch ein interessanter Punkt.
 
Ja, einen schwebenden Sektor findet man bei HDDs in einem echten RAID (also keinem RAID 0, da dem die Redundanz fehlt für die das R in RAID steht) eigentlich nie. Das liegt daran, dass jeder vernünftige RAID Lösung dann die Daten rekonstruiert und den Sektor bei dem die Platte einen Lesefehler statt der Daten geliefert hat dann dort überschreibt und damit prüft der Controller der Platte die neu geschriebenen Daten und ersetzt ggf. den betroffenen Sektor durch einen Reservesektor. Eche RAIDs bieten schon mehr Sicherheit, ersetzten aber natürlich keine Backups.
 
Also ich überspringe das mal wieso keinen HP Micro Server? Da kannst du Open NAS oder wie das heist drauf spielen. ICH würde mir nichts Properitäres nehmen. Abgesehen davon ist ein echter Raid Controller einfach nur geil! Durch den Ram Cache IM CONTROLLER erreichst du einen super speed gerade beim schreiben!
 
Du meinst vermutlich OpenMediaVault und ja, so ein Microserver ist damit die viel günstigere Lösung als die Kisten die als NAS verkauft werden. Einen HW RAID Controller braucht man aber nicht, unter Linux sind die SW RAIDs anderes als unter Windows sehr performant, zumindest solange der Schreibcache der Platten nicht deaktiviert ist. Das ist bei den HP N36L von denen Du zwei hast, aber der Fall, was man aber im BIOS (ggf. braucht man dafür das Mod-BIOS) aber einstellen kann und dann schafft auch ein md SW-RAID weit mehr als das Gigabit Netzwerk übertragen kann. Bei den HW-RAID Controllern funktioniert das RAM auch nur als Schreibcache, wenn er eine BBU hat oder man so tut als hätte er eine.
 
B
Also ich überspringe das mal wieso keinen HP Micro Server? Da kannst du Open NAS oder wie das heist drauf spielen. ICH würde mir nichts Properitäres nehmen. Abgesehen davon ist ein echter Raid Controller einfach nur geil! Durch den Ram Cache IM CONTROLLER erreichst du einen super speed gerade beim schreiben!
Wie viel Cache hat dein Raidcontroller?
128 MB, 256 MB, 512 MB oder wenn du ein sehr teures Modell hast vieleicht auch 1GB.
aktuelle HDDs haben einen internen Cache von 32 oder 64 Mbyte.
Bei 128 MB Controllercache, kann der Controller also gerade mal den HDD Cache von 5 HDDs im Raid5 Cachen - sehr sinnig...

Ein FreeNAS/NAS4Free usw. auf einem xbeliebigen System hat als Cache die Grösse des verbauten Arbeitsspeicher abzüglich von vielleicht 500 MB - die das System selbst belegt.
Bei einem HP Microserver Gen8 mit Celeron sind das ca. 3,5 GB (4GB-512MB) - Aufrüstbar auf 32 GB (offiziell 16 GB).

Ein HP Microserver mit einer dedizierten NAS-Distri raucht deinen Raidcontroller gepflegt in der Pfeife und strengt sich dabei nichtmal an.
Selbst der Celreon hat noch genug Reserve für 1 oder 2 VMs - wenn der Arbeitsspeicher dafür entsprechend aufgerüstet wurde.

Der Einsatz eines dedizierten Hardwareraidcontrollers bringt also nur unter Windows etwas, da Windows beim Softwareraid performancetechnisch weit hinterherhinkt, da sind dann sogar die Fake-Raidcontroller ohne dedizierten Controllercache noch Leistungsfähiger.
Mit Storagespaces will MS das wohl ändern, Storagespaces steckt aber noch gewaltig in den Kinderschuhen.
 
Zuletzt bearbeitet:
Wie viel Cache hat dein Raidcontroller?
128 MB, 256 MB, 512 MB oder wenn du ein sehr teures Modell hast vieleicht auch 1GB.
der ältere 256MB und der neue 512MB. Und bei einen Raid würde ich nur Controller Cache nutzen ist performanter.
 
der ältere 256MB und der neue 512MB. Und bei einen Raid würde ich nur Controller Cache nutzen ist performanter.
AHA.....
ich sehe schon dein nächstes Posting: "Wieso ist die Schreibrate meines Raids so niedrig"
Die Schreibrate bricht bei deaktiviertem Schreibcache der HDDs gnadenlos weg.
 
B
Wie viel Cache hat dein Raidcontroller?
128 MB, 256 MB, 512 MB oder wenn du ein sehr teures Modell hast vieleicht auch 1GB.
aktuelle HDDs haben einen internen Cache von 32 oder 64 Mbyte.
Bei 128 MB Controllercache, kann der Controller also gerade mal den HDD Cache von 5 HDDs im Raid5 Cachen - sehr sinnig...

Moment, du scheinst da gerade ein paar Sachen Durcheinander zu schmeißen...
Der Cache im Raidcontroller ist eigentlich auch dafür da, irgendwelchen Inhalt schnell zu puffern um nicht auf die Rückmeldung der HDDs zu warten, dass der Datenblock geschrieben wurde.
Sinnvollerweise betreibt man so ein Konstrukt mit BBU, ggf. auch mit einem Controller welcher anstatt RAM ähnlichen Verfahren Flashstorage als Cache nutzt oder dergleichen. (Frag mich nicht nach dem genauen Namen dafür, der ist mir gerade entfallen)
Der Vorteil, wenn du nen dedizierten Controller samt BBU und Cache hast, du kannst diesen im Write-Back Mode fahren. Dabei wartet das Konstrukt eben nicht auf die Rückmeldung, dass die Daten auf dem physischen Volume angekommen sind, sondern werden im Cache gepuffert -> dann auf die Platten geschrieben, während dessen gibts aber schon den nächsten Schreibbefehl. Die Wartezeit auf die Rückmeldung entfällt also, da der Inhalt in den Cache geschrieben wurde und ans Hostsystem damit die Schreiboperation erfolgreich abgeschlossen ist!
Ohne Write-Back aka im Write-Through Modus wartet das Konstrukt. Das dauert ewig... Egal wie groß dein Cache nun ist. Die Blöcke, welche am Stück geschrieben werden, sind wohl deutlich kleiner als 128MB. Der Speednachteil des Write-Through Modus ist aber extrem!
Ein FreeNAS/NAS4Free usw. auf einem xbeliebigen System hat als Cache die Grösse des verbauten Arbeitsspeicher abzüglich von vielleicht 500 MB - die das System selbst belegt.
Bei einem HP Microserver Gen8 mit Celeron sind das ca. 3,5 GB (4GB-512MB) - Aufrüstbar auf 32 GB (offiziell 16 GB).

Auch hier wirfst du zwei Sachen in einen Topf... Was hindert dich daran bei Einsatz eines dedizierten Raidcontrollers ein Storage Caching des Betriebssystems zu nutzen??? Nichts...
Es ist also keineswegs ein Vorteil von einem Software Raid. Sondern es ist ein Vorteil, der IMMER gegeben ist. Den man sich, nimmt man es genau, aber gerade im privaten Umfeld reichlich VORHER überlegen sollte. -> ist der Strom nämlich mal weg, sind Daten verlustig! Der Raidcontroller nutzt dafür die BBU um den Inhalt der/des Caches zu speichern. Daten im RAM sind verloren und kommen auch nicht wieder... USV ist genau genommen also Pflicht!
Jedes moderne Linux/Unix oder Windows based OS nutzt diese HDD Cacheverfahren per default... Sollte man also mal drüber nachdenken!
Ein Hypervisor wie der ESXi bspw. nutzt das nicht... Deswegen ist die Disks per default auf nem billigen Raidcontroller ohne Cache/BBU und im Write-Through Mode auch so schweine langsam... Da wird schlicht NULL zwischengecacht. Die Daten laufen von der Befehlsabsetzung bis direkt auf die Disk und das Konstrukt wartet auf die Rückantwort.

Der Einsatz eines dedizierten Hardwareraidcontrollers bringt also nur unter Windows etwas, da Windows beim Softwareraid performancetechnisch weit hinterherhinkt, da sind dann sogar die Fake-Raidcontroller ohne dedizierten Controllercache noch Leistungsfähiger.

Wie gesagt, auch das ist eigentlich unsinn... Der Sinn beim Einsatz eines Raidcontrollers hängt von vielen Faktoren ab. Ob Windows/Linux oder nicht, ist dabei eigentlich unwichtig... Selbst bei Einsatz unter Linux kann es (siehe oben) sinnvoll sein, anstatt des Softwareraids mit RAM Cache einen Hardwarecontroller mit BBU zu nutzen. Auch kann man sich damit bspw. den HDD internen Cache sparen -> ausschalten, wenn es keine USV am System gibt. Denn der Inhalt dieses Caches ist eben bei Stromflussunterbruch nicht rettbar -> und damit ggf. ein Teil des Datenbestands auf der Disk!
 
Zuletzt bearbeitet:
Die Schreibrate bricht bei deaktiviertem Schreibcache der HDDs gnadenlos weg.
Bei mir ist der Akku hin und nein die Performance ist immer noch ordentlich! Klar man merkt das der Cache nicht mehr da ist aber langsamer als eine "normale" HDD ist das System eindeutig nicht!
anstatt des Softwareraids mit RAM Cache einen Hardwarecontroller mit BBU zu nutzen.
Hier muss man schauen wie lange die BBU die Daten halten kann.
Ohne Write-Back aka im Write-Through Modus wartet das Konstrukt. Das dauert ewig... Egal wie groß dein Cache nun ist. Die Blöcke, welche am Stück geschrieben werden, sind wohl deutlich kleiner als 128MB. Der Speednachteil des Write-Through Modus ist aber extrem!
Also bei mir lauft es auch so schnell ohne BBU. Gut ok ich setze auf Business HDDs. Ein weiterer Vorteil der noch nicht genannt wurde ist das man SED HDD/ SDD einsetzen kann die 100% Transparent arbeiten.
 
Definiere "ordentlich"...
Und Definiere dein genutztes System... Alles andere ist rumraten um den heißen Brei.
Mal davon ab, wenn dein "Akku" -> meint wohl die BBU, hin ist, heist das nicht, dass Write-Back nicht trotzdem aktiv ist. Denn oftmals lässt sich der Modus trotzdem erzwingen. Sinnvoll ist das allerdings nicht. Zumindest nicht in Jedemfall.

PS: und nein, es ist wurscht, wie "lange die BBU die Daten halten kann". Mal davon ab, das da nix gehalten wird. Die BBU ist ein Stück Batterie. Nicht mehr und nicht weniger... Diese Batterie sorgt dafür, dass im Falle des Stromausfalles der Speicherinhalt aus dem DRAM Cache des Controllers nicht flöten geht. Solange Strom drauf ist, macht die BBU gelinde gesagt GAR nix.
 
Diese Batterie sorgt dafür, dass im Falle des Stromausfalles der Speicherinhalt aus dem DRAM Cache des Controllers nicht flöten geht. Solange Strom drauf ist, macht die BBU gelinde gesagt GAR nix.
nochmal ich meinte das man schauen muss wie lange die BBU die Daten halten kann wenn der Strom weg ist. Das kann je nach BBU unterschiedlich sein. Beispiel weil mal jemand meinte bei einen Hochwasser (wo nur der Strom weg ist) es egal weil die BBU eh die Daten haltet. Je nach Hersteller mal kürzer oder länger. Da muss man zb mit einen Diesel "kurz" das Gerät Starten das die Daten auf die HDD geschrieben werden können.
 
Bei mir ist der Akku hin und nein die Performance ist immer noch ordentlich! Klar man merkt das der Cache nicht mehr da ist aber langsamer als eine "normale" HDD ist das System eindeutig nicht!

Ich bezog mich auf den Cache der HDDs, der Unterschied zwischen WB (Ohne BBU) und WT (mit BBu oder forced) Cache des Controllers hat nicht ganz so gravierende Auswirkungen, WT ist natürlich "gefühlt" langsamer als WB - zumindest im "normalen" Nutzungesprofil - da die Schreib- und Leseanforderungen anders Priorisiert werden.

Ohne Write-Back aka im Write-Through Modus wartet das Konstrukt. Das dauert ewig... Egal wie groß dein Cache nun ist. Die Blöcke, welche am Stück geschrieben werden, sind wohl deutlich kleiner als 128MB. Der Speednachteil des Write-Through Modus ist aber extrem!
Jein!
Bei überwiegend schreibenden Nutzungsprofil ist die Auswirkung vernachläsigbar.
Write Back bedeutet, Schreibanforderungen werden bei Leseanforderung zurückgestellt und Warten auf das Ende der Leseanforderung oder auf ein Forced Cache-Flush. >> Lesepriorität (laufende Schreiboperationen werden unterbrochen wenn eine Leseanforderung kommt)
Write Trough bedeutet, Leseanforderungen warten auf den Abschluss der Schreibanforderungen >> Schreibpriorität ( laufende Leseoperationen werden unterbrochen wenn eine Schreibanforderung kommt)

Zum Thema BBU:
Die BBU sichert den Inhalt des Controller-Caches, das Garantiert aber in keiner Weise ein konsistentes Dateisystem mit komplett geschriebenen Daten und Metadaten - es erhöht Nur etwas die Wahrscheinlichkeit, daß das Dateisystem auch bei einem Stromausfall, Ausfall des Netzteils, BSOD oder Systemfreeze konsistent bleibt.
CoW Dateisysteme wie ZFS oder BTRFS haben genau dieses Problem nicht, das Dateisystem ist immer Konsistent - nicht vollständig geschriebene Daten sind in allen Fällen verloren.

- - - Updated - - -

nochmal ich meinte das man schauen muss wie lange die BBU die Daten halten kann wenn der Strom weg ist. Das kann je nach BBU unterschiedlich sein. Beispiel weil mal jemand meinte bei einen Hochwasser (wo nur der Strom weg ist) es egal weil die BBU eh die Daten haltet. Je nach Hersteller mal kürzer oder länger. Da muss man zb mit einen Diesel "kurz" das Gerät Starten das die Daten auf die HDD geschrieben werden können.
Üblich sind 72h bei neuen BBUs mit 100% Kapazität

Nochmal: Schalte bei deinen HDDs am Raidcontroller den internen HDD-SchreibCache aus und du wirs dein Performancewunder erleben - im negativen Sinne!
Der interne HDD Cache arbeitet per default im Write-Trough modus und ist nowendig, da nur der HDD Controller "weiss" wo welcher LBA liegt und die zu Schreibenden LBAs entsprechend optimieren kann.
Bei abgeschaltetem Schreibcache wird der Schreibbefehl für ein oder mehrere Dateisystemcluster einfach in zu schreibende LBAs "übersetzt" und diese werden von Ihrer logischen und physikalischen Reihenfolge und Position nacheinander ausgeführt

Es gibt natürlich Anwendungen (z.B. Exchange) für die es empfohlen wird den Schreibcache der HDDs abzuschalten, dafür ist allerdings nahezu Vorraussetzung, daß diese Anwendung dann für die Datenbank eine eigene leere Partition bekommt, bei der die Datenbankdatei unfragmentiert angelegt werden kann. Hier ist dann die Anwendung dafür zuständig die Schreibanforderungen zu organisieren und zu optimieren. (Die Exchangedatenbank sollte dazu auch regelmässig reorganisiert werden um die Fragmentierung innerhalb der Datenbank zu reduzieren)

USV:
Eine USV schützt die Daten im OS Cache genausowenig, wie eine BBU das Dateisystem konsistent halten kann.
Eine USV hilft nur bei Stromausfall und kann das System in diesem Fall primär ordungsgemäss herunterfahren, nicht aber bei BSOD, Systemfreeze oder Defekt anderer Komponenten.

Die BBU kann auch nur Schreiboperationen von Dateien "absichern", die kleiner als die Cachegrösse sind.
128M oder 512 MB sind da ein "Witz" - zumindest wenn man mit Mediadaten arbeitet, wie du es tust (TV Mitschnitte). Für MP3 reicht es noch so gerade eben - jedenfalls meistens. Wenn die Daten Grösser als der Arbeitsspeicher sind kommt auch noch der Swap Speicher aka Auslagerungsdatei oder der Temp-Pfad dazu.

Im übrigen geht es hier immer noch um ein NAS! Das Ding soll Daten im Netzwerk bereitstellen - und das mit ausreichender Performance (Limitiert wird das ganze eh durch die Netzwerkanbindung)
NAS = Network Attached Storage
 
Zuletzt bearbeitet:
128M oder 512 MB sind da ein "Witz" - zumindest wenn man mit Mediadaten arbeitet, wie du es tust (TV Mitschnitte). Für MP3 reicht es noch so gerade eben - jedenfalls meistens. Wenn die Daten Grösser als der Arbeitsspeicher sind kommt auch noch der Swap Speicher aka Auslagerungsdatei oder der Temp-Pfad dazu.
Ka was du mir da wieder unterstellst aber nein ich mache nichts der gleichen.
Mein alter IBM Server zeichnet auf eine Single SSD 2HD + 2 DVB-T Sendungen gleichzeitig auf ohne Raid oder Cache oder was auch immer nur bei ner einfachen SSD.
 
achso, deine aufgezeichnete TV Mitschnitte sind alle unter 128MB groß
Ich Wusste gar nicht, daß Werbeclips so interressant sind, daß man diese aufzeichnen muß....

ich bin hier raus...
P.S wärstdu nicht schon so lange hier angemeldet, könntwe man die glatt für die Reinkarnation von SuperTechFreak halten.
 
Zuletzt bearbeitet:
Bei überwiegend schreibenden Nutzungsprofil ist die Auswirkung vernachläsigbar.
Write Back bedeutet, Schreibanforderungen werden bei Leseanforderung zurückgestellt und Warten auf das Ende der Leseanforderung oder auf ein Forced Cache-Flush. >> Lesepriorität (laufende Schreiboperationen werden unterbrochen wenn eine Leseanforderung kommt)
Write Trough bedeutet, Leseanforderungen warten auf den Abschluss der Schreibanforderungen >> Schreibpriorität ( laufende Leseoperationen werden unterbrochen wenn eine Schreibanforderung kommt)

Öhm nein...
Meine Aussage ist bezogen auf folgendes:
Write Back und Write Through

Im Allgemeinen verfügen die meisten RAID-Controller über zwei unterschiedliche Strategien, um Daten vom Betriebssystem auf die Festplatten zu schreiben: Write Back und Write Through.

Beim Write Back schickt der RAID-Controller einen "Completion-Status" (Bestätigungsbefehl) an das Betriebssystem, sobald der Pufferspeicher des Controllers die Schreibdaten für die Festplatte vom System erhalten hat. Der Controller hält die Informationen so lange im Cache, bis der Controller einen geeigneten Zeitpunkt findet, die Daten an die Festplatte zu übertragen. Dies erfolgt zu einem Zeitpunkt, zu dem die Systemressourcen nicht voll beansprucht werden, so dass diese Strategie die Schreibleistung signifikant verbessert.

Allerdings hat das Write-Back-Verfahren auch Nachteile. Tritt eine Störung bei der Stromversorgung auf, sind unter Umständen wichtige Daten, die noch nicht vom Cache-Controller auf die Festplatte geschrieben wurden, unwiderruflich verloren. Deshalb ist es empfehlenswert, die meist optional erhältliche Batteriepufferung des Cache-Controllers mitzubestellen oder sich gleich für eine USV zu entscheiden.

Anders verhält sich die Write-Through-Strategie. Diese sendet einen "Completion-Status" erst dann an das Betriebssystem, wenn die Daten sicher auf die Festplatte geschrieben wurden. Deshalb kostet das Verfahren Übertragungs- beziehungsweise System-Performance, da die Informationen ohne Zwischenpufferung direkt, ohne Rücksicht auf aktuelle Systemressourcen, auf die Festplatte geschrieben werden. Darüber hinaus unterscheidet sich die Schreibleistung mit aktiviertem Write-Through-Cache kaum von der Performance eines Controllers ohne Cache-Unterstützung.
Text von hier:
RAID-Controller-Praxis - channelpartner.de

Ob das nun "überwiegend schreibende Last" ist oder nicht, ist dabei wenig bis gar nicht entscheidend. Es geht um die Wartezeit. Ich würde es bestenfalls noch anhand von sequenziel oder random Writes festmachen. Aber erfahrungsgemäß sind auch sequenzielle Writes massiv langsamer. Random sowieso, da der Anteil der Wartezeit bis zum nächsten Write eben massiv viel länger ist, als das ganz nur bis in den Cache zu pusten.

Die BBU sichert den Inhalt des Controller-Caches, das Garantiert aber in keiner Weise ein konsistentes Dateisystem mit komplett geschriebenen Daten und Metadaten - es erhöht Nur etwas die Wahrscheinlichkeit, daß das Dateisystem auch bei einem Stromausfall, Ausfall des Netzteils, BSOD oder Systemfreeze konsistent bleibt.
CoW Dateisysteme wie ZFS oder BTRFS haben genau dieses Problem nicht, das Dateisystem ist immer Konsistent - nicht vollständig geschriebene Daten sind in allen Fällen verloren.

Wenn dein Dateisystem crasht, ist es ehrlich gesagt ein beschissenes Dateisystem...
Warum sollte es crashen, wenn ALLE Daten konsistent auf den Disks stehen UND jegliche Änderungen am Filesystem im Controllercache und nirgends anders stehen? Da sollte normal nix crashen... Denn die BBU hält besagte Änderungen eine gewisse Zeit eben vor...
Anders sieht es ganz klar bei "Software-Defined-Storagelösungen" aus. Eben weil du den RAM Inhalt, wenn dieser als "Write-Cache" genutzt wird, nicht schützen kannst. Zumindest nicht derart... Eine USV hilft in dem Fall, damit läuft die Kiste halt weiter und SOLLTE gezielt und sauber heruntergefahren werden...

Nochmal: Schalte bei deinen HDDs am Raidcontroller den internen HDD-SchreibCache aus und du wirs dein Performancewunder erleben - im negativen Sinne!
Der interne HDD Cache arbeitet per default im Write-Trough modus und ist nowendig, da nur der HDD Controller "weiss" wo welcher LBA liegt und die zu Schreibenden LBAs entsprechend optimieren kann.
Bei abgeschaltetem Schreibcache wird der Schreibbefehl für ein oder mehrere Dateisystemcluster einfach in zu schreibende LBAs "übersetzt" und diese werden von Ihrer logischen und physikalischen Reihenfolge und Position nacheinander ausgeführt
Der der Cache im wt Mode arbeitet, siehe oben, dann ist doch alles in Butter... Die Rückantwort zurück zum Storagecontroller erfolgt also erst DANN, wenn die Daten auf der Platte angekommen sind. Nicht vorher. Ein Ausschalten des Caches wäre effektiv das Gleiche. Hätte möglicherweise aber eben die von dir angesprochenen Nachteile!

Die BBU kann auch nur Schreiboperationen von Dateien "absichern", die kleiner als die Cachegrösse sind.
128M oder 512 MB sind da ein "Witz" - zumindest wenn man mit Mediadaten arbeitet, wie du es tust (TV Mitschnitte). Für MP3 reicht es noch so gerade eben - jedenfalls meistens. Wenn die Daten Grösser als der Arbeitsspeicher sind kommt auch noch der Swap Speicher aka Auslagerungsdatei oder der Temp-Pfad dazu.

Auch das kann ich nicht nachvollziehen... Siehe oben, wieso gehst du davon aus, dass ausschließlich eine Softwarelösung für das Storage über RAM Cache verfügt? Das macht effektiv JEDES ansatzweise moderne OS... Der kleine "Witz" Cache am Raidcontroller ist also eine zusätzliche Cachestufe. Die KANN effektiv nur Vorteile bringen -> gesetzt dem Fall, man ist entsprechend abgesichert.
Ein halbwegs anständiges Windows/Linux OS, sie oben, wird auch ohne Storage Controller Caches anständige Datenraten und Durchsatz hinbekommen, weil der RAM als Cache missbraucht wird... Spezielle Appliances, wo dies explizit nicht gewünscht ist, erreichen da ganz andere Werte. Vor allem ohne Cache am Controller...
 
zieh einfach mal den Stromstecker, nachdem du in Photoshop auf Speichern gedrückt hast.
Bei einer grossen Collage mit mehreren Ebenen Inklusive Protokoll, kann die Datei gut und gerne mal mehrere Gigabyte Gross werden.

Bitte nicht wundern wenn die Datei trotz Controllercache korrupt oder nicht vollständig geschrieben ist.
Und auch ein NTFS Dateisystem kann dann mal über den Jordan gehen (mir ist in über 20 Jahren keines Hops gegangen - es bleibt aber eine zumindest kleine Möglichkeit, daß das passiert).

"Completion Status"
Denk mal drüber nach was ich geschrieben habe - meine Aussagen beinhalten den, ansonsten wäre WB langsamer als WT!
Ein "geeigneter Zeitpunkt" zum Schreiben ist bei WB, wenn keine Leseanforderung besteht.
Trotzdem schöne Ergänzung / Beschreibung mit anderen Worten, Danke!

Bei überwiegend schreibender Last gibt es zwischen WT und WB allenfalls einen Messbaren Unterschied, da die Daten sofort geschrieben werden (es besteht keine Leseanforderung die das Schreiben verzögert)

Moderne OSses Cachen intensiv, das ist richtig.
Trotzdem läuft ein Software Raid (LVM oder ZFS) unter Linux, BSD, Solaris auch ohne Raidcontroller mit eigenem Cache äusserst performant.
Windows bekommt das nicht hin, da "muß" es ein Hardwareraidcontroller mit Cache sein, wenn man ein performantes Speichersubsys haben will.
Somit ist die Ausage das Alle OSses Cachen unter diesem Aspekt leider irrelevant.

Achja, oben wurde "bemängelt", daß z.B. EsXi gar nicht cached.
Auch das ist logisch und wäre Kontraproduktiv.
ESXi ist ein Typ1-Hypervisor dessen einzige Aufgabe ist Ressourcen für VMs bereitzustellen und zuzuteilen.
Ein Cache im RAM unter ESXi würde die Ressource RAM reduzieren
Da die VMs selber Cachen würde letztendlich doppelt gecached werden.
 
Zuletzt bearbeitet:
Die Empfehlung für einen Microserver verstehe ich nicht ganz. Ich habe ja schon ein NAS, warum also neue Hardware kaufen? Ich habe jetzt einfach mal meine 2 4TB WD RED HDD auf JBOD umgestellt. Das funktioniert einwandfrei und bevor jemand fragt, ja ich mache auch ein Backup :)
Ich frage mich nur ob RAID 0 die bessere LÖsung gewesen wäre...
 
Ein RAID 0 wäre ggf. schneller gewesen, wobei diese einfachen NAS Kisten oft so lahm sind, dass dies auch einen Unterschied macht. Bzgl. der Datensicherheit ist beides ähnlich mies, die Chancen auf Datenrettung sind bei JBOD (als BIG) ggf. minimal besser.
 
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