Moin, ich habe mal eine Frage an die ZFS-Experten hier aus der Runde. Ich brauche in meinem Rechner rund 2TB schnellen Speicher. NVMe Steckplätze sind belegt und keine PCI Lanes sind mehr verfügbar. Jetzt nehmen wir mal an, ich würde 4 (consumer) SSDs nehmen, die ca. 480-500GB groß sind und die als Stripe verwenden, würde es funktionieren? Gibt es irgendetwas zu beachten? Die Inhalte der SSDs werden dann regelmäßig weggesichert, um Datenverlust mache ich mir deshalb keine Sorgen. Ich brauche nur sehr schnellen Speicher fürs Arbeiten.
ZFS als Strips aus verschiedenen SSDs?
- Ersteller LL0rd
- Erstellt am
Geht schon.
Eine Consumer SSD kann sagen wir mal 300 MB/s sequentiell. Die als Raid-0 machen dann zusammen theoretisch 1,2 GB/s, in realworld vielleicht 700 MB/s. Lesend wird das dauerhaft so sein, schreibend wird nach einiger Zeit die Performance recht massiv einbrechen.
IOPS einer einzelnen SSD unter dauerhaften Schreiben wird eventuell bei ca 5k liegen. Im Raid-0 hat man den gleichen Wert. (Die Schönwetterangaben im Datenblatt z.B. 80k kann man getrost ignorieren)
Stürzt der Rechner ab, so ist der Inhalt des SSD Schreibcaches verloren (keine plp). Wenn man das Raid-0 als Speicherort für Datenbanken oder VMs nutzen möchte, so ist das sagen wir mal "suboptimal" da damit Datenverlust oder korrupte Dateisysteme entstehen können. Backup hilft dann nur bedingt weil man viel zu spät erfährt dass es ein Problem gibt und das dann auch auf dem Backup ist.
Ausfallhäufigkeit, je SSD z.B. statistisch ca 5% pro Jahr. Ausfallwahrscheinlichkeit eines Raid-0 aus 4 SSD=20% (im Schnitt alle 5 Jahre). Mit älteren SSD nimmt das aber schnell zu.
Eine Consumer SSD kann sagen wir mal 300 MB/s sequentiell. Die als Raid-0 machen dann zusammen theoretisch 1,2 GB/s, in realworld vielleicht 700 MB/s. Lesend wird das dauerhaft so sein, schreibend wird nach einiger Zeit die Performance recht massiv einbrechen.
IOPS einer einzelnen SSD unter dauerhaften Schreiben wird eventuell bei ca 5k liegen. Im Raid-0 hat man den gleichen Wert. (Die Schönwetterangaben im Datenblatt z.B. 80k kann man getrost ignorieren)
Stürzt der Rechner ab, so ist der Inhalt des SSD Schreibcaches verloren (keine plp). Wenn man das Raid-0 als Speicherort für Datenbanken oder VMs nutzen möchte, so ist das sagen wir mal "suboptimal" da damit Datenverlust oder korrupte Dateisysteme entstehen können. Backup hilft dann nur bedingt weil man viel zu spät erfährt dass es ein Problem gibt und das dann auch auf dem Backup ist.
Ausfallhäufigkeit, je SSD z.B. statistisch ca 5% pro Jahr. Ausfallwahrscheinlichkeit eines Raid-0 aus 4 SSD=20% (im Schnitt alle 5 Jahre). Mit älteren SSD nimmt das aber schnell zu.
Also Zweck des "Raid-0" soll sein, dass relativ viel Speicherplatz zur Verfügung steht für verschiedene Video-Bearbeitung und Datei-Operationen wie Packen und Entpacken von Dateien. Bzw. dem Cache der Video-Software. Kommt es zu einem Datenverlust, so ist dieser nicht tragisch, da er nur die Footage betrifft, die sowieso im Original noch verfügbar bzw. den Cache, der eh neu gebaut werden kann.
Was genau meinst du denn damit, dass die Schreib-Performance abnehmen wird? Hatte ich tatsächlich mal bei einer SSD bei ausgeschaltetem TRIM. Wie schnell wird denn die Performance denn abnehmen? Sprechen wir da von wenigen geschriebenen TB auf eine 500GB SSD oder mehr?
Nein es geht darum das die günstigen SSDs meistens einen Hochgeschwindigkeitszwischenspeicher haben. Nach 200-400GB am Stück geschriebenen Daten bricht die Leistung ein. Diese erholt sich natürlich wieder sobald der Zwischenspeicher geschrieben ist. Wenn du im Internet nach QLC-SSDs suchst findest du viel zu dem Thema, da das bei dieser Art recht stark ausgeprägt ist.
Es geht erstmal um einen RAM oder SLC Schreibcache.
Der bringt anfänglich Performance (und das powerloss Problem). Ist der voll sinkt die Performance.
Daneben muss man bei SSD beachten (bis auf Optane) dass man nicht einzelne "Sektoren" beschreiben kann sondern nur komplette recht große Bereiche/Blocks. Nur wenn die komplett leer sind kann man direkt schreiben, ansonst muss man den Block erst lesen, anpassen/auffüllen und dann komplett neu schreiben. Neue SSD oder SSD nach sicherem Löschen oder einem Trim sind daher viel schneller als SSD nach einiger Zeit der Nutzung da man dann keine teilweise belegte Blocks hat.
Trim wird durch das Betriebssystem geleistet. Das kann nur gut geschehen wenn keine sonstige Schreib-Last anliegt. Bei dauerhaftem Schreiben geht das nicht sonderlich gut. Datacenter SSD sind darauf optimiert und haben einen großen reservierten Bereich (oft 10-20% der SSD) um auch ohne Trim Unterstützung dauerhaft schnell zu sein. Die Hintergrund Optimierung (Garbage Collection) der SSD selber (ohne dass Trim beteiligt ist) arbeitet da besonders gut.
Desktop SSD sind da nicht so gut und haben keinen oder nur eine geringe Reservierung für diese Optimierungen und werden daher auch wenn man Trim aktiviert schnell langsam bei längerem Schreiben,
www.thomas-krenn.com
Der bringt anfänglich Performance (und das powerloss Problem). Ist der voll sinkt die Performance.
Daneben muss man bei SSD beachten (bis auf Optane) dass man nicht einzelne "Sektoren" beschreiben kann sondern nur komplette recht große Bereiche/Blocks. Nur wenn die komplett leer sind kann man direkt schreiben, ansonst muss man den Block erst lesen, anpassen/auffüllen und dann komplett neu schreiben. Neue SSD oder SSD nach sicherem Löschen oder einem Trim sind daher viel schneller als SSD nach einiger Zeit der Nutzung da man dann keine teilweise belegte Blocks hat.
Trim wird durch das Betriebssystem geleistet. Das kann nur gut geschehen wenn keine sonstige Schreib-Last anliegt. Bei dauerhaftem Schreiben geht das nicht sonderlich gut. Datacenter SSD sind darauf optimiert und haben einen großen reservierten Bereich (oft 10-20% der SSD) um auch ohne Trim Unterstützung dauerhaft schnell zu sein. Die Hintergrund Optimierung (Garbage Collection) der SSD selber (ohne dass Trim beteiligt ist) arbeitet da besonders gut.
Desktop SSD sind da nicht so gut und haben keinen oder nur eine geringe Reservierung für diese Optimierungen und werden daher auch wenn man Trim aktiviert schnell langsam bei längerem Schreiben,
Solid-State Drive – Thomas-Krenn-Wiki
Ein Solid-State Drive (SSD) ist ein nicht-flüchtiger Datenspeicher ähnlich einer Festplatte. Im Unterschied zu einer Festplatte hat eine SSD keine beweglichen Teile. Die Daten speichert eine SSD in Flash-Bausteinen (SLC oder MLC). In diesem Artikel erfahren Sie wie SSDs intern funktionieren und...
Zuletzt bearbeitet:
Ok, vielen Dank für die Antwort. Ich muss jetzt mal etwas laut nachdenken und bitte da mal um Feedback. Im Grunde wird es ja folgender Workload sein:
1) Ich hole mir z.B. 500GB Daten vom Server herunter.
2) Ich arbeite mit den Daten, sodass da ca. 1-1,5TB an Daten entstehen. Diese Arbeit wird ca. einen Arbeitstag dauern.
3) Ich lösche die Daten wieder von dem Pool, der Pool ist dann komplett leer.
4) Der Pool wird nur für die Arbeit verwendet, der Rechner steht mit leerem Pool zwischendurch ohne Schreibvorgänge auf das Pool.
Dann müsste ich doch eigentlich keine Probleme bekommen?
Und zum Thema SLC-Cache.... Ich komme da ja eh nicht drum herum, oder?
1) Ich hole mir z.B. 500GB Daten vom Server herunter.
2) Ich arbeite mit den Daten, sodass da ca. 1-1,5TB an Daten entstehen. Diese Arbeit wird ca. einen Arbeitstag dauern.
3) Ich lösche die Daten wieder von dem Pool, der Pool ist dann komplett leer.
4) Der Pool wird nur für die Arbeit verwendet, der Rechner steht mit leerem Pool zwischendurch ohne Schreibvorgänge auf das Pool.
Dann müsste ich doch eigentlich keine Probleme bekommen?
Und zum Thema SLC-Cache.... Ich komme da ja eh nicht drum herum, oder?
Über Nacht?
Und dann zurückkopieren (nächste Nacht)?
Wie kritisch sind die Daten?
Ich würde mir ein 10G Netzwerk überlegen und die Daten auf dem Server lassen.
Wenn das nicht gerade ein lahmes lowpower System mit wenig RAM ist, dann ist der Server bei random io eventuell sogar schneller und da man ein vernünftiges Dateisystem hat sind die Daten auch viel sicherer, man hat Snaps (Versionierung) und Schutz vor Ransomware . Zudem fällt der Kopieraufwand weg.
Ja, z.B. Das ist nicht kritisch.
Naja, das Ergebnis sind dann 20-30GB an Daten, die zurückgespielt werden müssen. Die Daten sind wie gesagt nicht kritisch. Kritisch ist die Footage und die "Projektdatei", die wenige MB groß ist. Sie ist quasi die Bauanleitung. Die liegt auf der NVMe des Rechners. Wenn die weg ist, ist die Arbeit eines Tages weg - kann ich im Worst Case verkraften.
Das 10G Netzwerk steht schon und ich habe dort Datenraten von ca. 800MB/s. Also auf das Netzwerk-Share möchte ich keinen Cache schreiben. Ja, ich könnte tatsächlich überlegen, die Footage auf dem Server zu belassen, würde aber nur die ersten 500GB Kopiervorgang einsparen.
Ist ein i3-8100 mit 64GB ECC RAM. Aktuell sind in dem System 3x10TB Platten drin und 5x 4TB. In 1-2 Tagen werde ich es erweitern um eine weitere 10TB Platte und ein paar (muss noch einmal nachschauen) 4TB Platten. ZFS übrigens.
Vor Ransomware & co. habe ich keine Angst. Der Server wird über Nacht auf Band gesichert + zu einem Cloud Cold Storage Anbieter.
sweetchuck
Enthusiast
- Mitglied seit
- 14.08.2014
- Beiträge
- 1.426
5% pro Jahr halte ich für deutlich zu hoch gegriffen. Backblaze hat bei Consumer-HDDs jährliche Ausfallraten von etwa einem Prozent und SSDs sind wegen fehlender Mechanik eher weniger anfällig als HDDs. Vorausgesetzt natürlich, man bleibt innerhalb der TBW-Vorgaben. Und bei einer Ausfallrate von 5% pro SSD hätte man bei 4 SSDs eine Ausfallrate des RAID0 von 18,5% [1-(1-0,05)^4].
Ich nutze als Bootplatte in meinen Servern seit vielen Jahren üblicherweise eine Intel DC. Von denen hatte ich noch nie einen Ausfall. Meine HGST Festplatten sind auch Ultra zuverlässig. Da ist die Fehlerrate auch extrem niedrig, steigt aber auch mit den Jahren deutlich an.
Ich hatte aber auch schon einen Server mit einem Pool aus 3TB Seagate Platten. Nach ca 3 Jahren fingen die Probleme an und in relativ kurzer Zeit waren vielleicht 30% getauscht oder zeigten Probleme bis hin zu einem Fast-Ausfall eines Raid-Z3. Ich habe dann alle (15 Platten) entsorgt.
Von meinen SSD in Rechnerpools sind nach 5 Jahren viele noch in Betrieb, viele aber auch ausgefallen. Problemrate steigt aber nach ein paar Jahren deutlich an. Von manchen SSD habe ich nach 5 Jahren durchaus bei relativ vielen Probleme. Spätestens nach 5 Jahren tausche ich die daher.
Bei neueren und guten Platten würde ich auch eher von <1% Fehlerrate ausgehen. Bei Desktop SSD und einem einzigen Raid-0 wäre ich da vorsichtiger und würde nicht vom Durchschnitt oder best case sondern eher vom worst case ausgehen.
Vermutlich stimmen die 18,5% als mittlere Wahrscheinlichkeit. Im konkreten Einzelfall dann aber entweder 0% oder 100% Ausfallwahrscheinlichkeit innerhalb von 5 Jahren.
@LLOrd
Ein 10G Netz wird wohl nicht langsamer als ein Raid-0 aus 4 Desktop SSD sein. Wäre was anderes wenn man lokal eine schnelle NVMe einsetzen würde. Die könnte aber auch im Server sein und bis auf die maximale Transferrate ähnlich hilfreich sein.
Ich hatte aber auch schon einen Server mit einem Pool aus 3TB Seagate Platten. Nach ca 3 Jahren fingen die Probleme an und in relativ kurzer Zeit waren vielleicht 30% getauscht oder zeigten Probleme bis hin zu einem Fast-Ausfall eines Raid-Z3. Ich habe dann alle (15 Platten) entsorgt.
Von meinen SSD in Rechnerpools sind nach 5 Jahren viele noch in Betrieb, viele aber auch ausgefallen. Problemrate steigt aber nach ein paar Jahren deutlich an. Von manchen SSD habe ich nach 5 Jahren durchaus bei relativ vielen Probleme. Spätestens nach 5 Jahren tausche ich die daher.
Bei neueren und guten Platten würde ich auch eher von <1% Fehlerrate ausgehen. Bei Desktop SSD und einem einzigen Raid-0 wäre ich da vorsichtiger und würde nicht vom Durchschnitt oder best case sondern eher vom worst case ausgehen.
Vermutlich stimmen die 18,5% als mittlere Wahrscheinlichkeit. Im konkreten Einzelfall dann aber entweder 0% oder 100% Ausfallwahrscheinlichkeit innerhalb von 5 Jahren.
@LLOrd
Ein 10G Netz wird wohl nicht langsamer als ein Raid-0 aus 4 Desktop SSD sein. Wäre was anderes wenn man lokal eine schnelle NVMe einsetzen würde. Die könnte aber auch im Server sein und bis auf die maximale Transferrate ähnlich hilfreich sein.
Im Server ist eine NVMe als Cache drin und eine SSD als ZIL-SLOG.
Wenn ich auf Daten zugreife, die irgendwo entfernt liegen, habe ich ja erst einmal den Protokoll-Overhead des Fileservers (Samba) und die Netzwerk-Latenz. Deshalb dachte ich, dass ein Raid-0 lokal mehr Sinn macht, als die Daten übers Netzwerk zu schaufeln.
Trambahner
Urgestein
Greifst Du mit SMB Shares zu? Dann wird das Slog gar nicht verwenet, wenn Du nicht sync=always setzt. SMB ist per default nicht sync und für async-Writes wird das Slog nicht verwendet.
Write-Cache, falls das Deine Intention ist, ist ein Slog auch nicht.
Btw, wenn ein Slog intensiv angesprochen wird, dann sind Consumer SSDs dafür eine sehr schlechte Wahl. Selbst 850pro, bekanntermaßen gute SSDs mit MLC, werden von syncwrites kleinbekommen und können dann durch ihre Latenzen einfach ausbremsen.
Btw, ich nutze einen SSD Pool aus 6 SSD (in 3 Mirrorpärchen), aber halt Server SSDs. Samsung SM863/SM883. Die haben ordentlich TBWs und relativ gute Mindest-IOPS.
Write-Cache, falls das Deine Intention ist, ist ein Slog auch nicht.
Btw, wenn ein Slog intensiv angesprochen wird, dann sind Consumer SSDs dafür eine sehr schlechte Wahl. Selbst 850pro, bekanntermaßen gute SSDs mit MLC, werden von syncwrites kleinbekommen und können dann durch ihre Latenzen einfach ausbremsen.
Btw, ich nutze einen SSD Pool aus 6 SSD (in 3 Mirrorpärchen), aber halt Server SSDs. Samsung SM863/SM883. Die haben ordentlich TBWs und relativ gute Mindest-IOPS.
Ja, ich greife per SMB zu.
Was meinst du denn damit, dass SLOG kein Write Cache ist?
Ich habe mich dabei an dieser Seite hier orientiert und die schreiben: "The ZFS ZIL SLOG is essentially a fast persistent (or essentially persistent) write cache for ZFS storage."
Da ist jetzt eine IronWolf (NAS) SSD drin. kA, ob die Consumer ist oder nicht.
Slog ist definitiv kein Write Cache sondern eine Sicherung des RAM Schreibcaches. STH hat das hier sagen wir mal unglücklich formuliert,
vgl https://forums.servethehome.com/ind...-hyperx-for-os-slog-drives.31223/#post-288942
Ein Slog, wenn man es denn braucht (Datenbanken, VM Storage) muss niedrigste Latenzen haben, dazu hohe dauerhafte write iops,
z.B. Intel Optane 4801 (NVMe, best of all), WD SS 530 (SAS, HA) oder Intel DC 3700 (Sata).
Übliche SSD, selbst Datacenter taugen nicht, Powerloss Protection ist Pflicht.
Wenn man SMB braucht, ist der in ZFS eingebaute (Solarish) meist schneller als SAMBA. Als Alternative kann man per iSCSI ein Zvol anbinden. 800 MByte/s ist aber bei 10G oberes Ende der Fahnenstange. Üblich bei langsameren Rechnern ohne Tuning ist 300-600 MB/s.
Zuletzt bearbeitet:
Also bei mir war bei 819MB/s Schreiben Schluss mit meinem aktuellen Setup. Ist ein Nixos Linux mit Samba.
Macht ein SLOG dann überhaupt Sinn? Nehmen wir mal folgendes Setup an:
4x 10TB als RaidZ1
6x 4TB als RaidZ1
Dann habe ich oben ca. 450MB/s und unten ca. 750MB/s. Und damit liege ich über den 800MB/s des Netzerks. + Die 32GB RAM (64GB hat der Server insg.) als Cache.
Anhänge
Danke für die Info, das war mir so noch nicht bekannt. Hab mich schon gewundert warum mein SLOG nicht beschrieben wird trotz sync=always.
D.h. das SLOG wird erst benutzt wenn der RAM-Cache voll ist ?
Trambahner
Urgestein
Nein, das hat mit Ram-Cache gar nix zu tun.
Vereinfacht:
Bei Async-Zugriffen (also auch default SMB oder iSCSI) erfolgt das "ok" sofort, wenn der Block im Ram-Writecache als "zu Schreiben" liegt und damit auch noch auf den Schreibvorgang wartet.
Stromweg oder Crash => Daten im Ram-Schreibcache sind weg.
Bei Sync-Schreibvorgängen gibt ZFS erst ein "commited" (=ok) an den aufrufenden Prozess zurück, wenn ein Datenblock physikalisch auf die Medien geschrieben ist und Metadaten konsistent sind.
Erst dann kann der Prozess (hier: SMB-Service) weitermachen. D.h. bei Stromausfall oder Crash: Daten sind sicher geschrieben.
=> damit kann Sync sehr langsam werden.
Mit Slog werden dort die zu schreibenden Daten geschrieben, dann gibts ein "ok" von ZFS und dann schreibt ZFS wie bei async den Block weg "wenn es passt".
Stromausfall oder Crash: Daten liegen ja wiederherstellbar am Slog, es ist also nix verloren (sofern Slog eine SSD mit Powerloss protection ist ! ohne dieser kann es entsprechend auch schlecht enden).
Ist dann der Block wirklich am endgültigen Medium geschrieben, wird der Block am Slog wieder freigegeben.
= > d.h. ein Slog wird im Normalzustand nur massivst und rollierend beschrieben, NIE gelesen, sondern nur im Desasterfall.
=> ein Slog ist eben kein Cache, sondern dient nur der Beschleunigung von sicheren Sync-Zugriffen auf maximal das Niveau von Async-Zugriffen (abzüglich etwas Performance wg dem Slog-Verwaltungsoverhead)
=> Schneller als Async wird es nie werden und auch Async nutzt es gar nicht.
=> Write-Cache bei ZFS ist immer RAM. Nix anderes.
Vereinfacht:
Bei Async-Zugriffen (also auch default SMB oder iSCSI) erfolgt das "ok" sofort, wenn der Block im Ram-Writecache als "zu Schreiben" liegt und damit auch noch auf den Schreibvorgang wartet.
Stromweg oder Crash => Daten im Ram-Schreibcache sind weg.
Bei Sync-Schreibvorgängen gibt ZFS erst ein "commited" (=ok) an den aufrufenden Prozess zurück, wenn ein Datenblock physikalisch auf die Medien geschrieben ist und Metadaten konsistent sind.
Erst dann kann der Prozess (hier: SMB-Service) weitermachen. D.h. bei Stromausfall oder Crash: Daten sind sicher geschrieben.
=> damit kann Sync sehr langsam werden.
Mit Slog werden dort die zu schreibenden Daten geschrieben, dann gibts ein "ok" von ZFS und dann schreibt ZFS wie bei async den Block weg "wenn es passt".
Stromausfall oder Crash: Daten liegen ja wiederherstellbar am Slog, es ist also nix verloren (sofern Slog eine SSD mit Powerloss protection ist ! ohne dieser kann es entsprechend auch schlecht enden).
Ist dann der Block wirklich am endgültigen Medium geschrieben, wird der Block am Slog wieder freigegeben.
= > d.h. ein Slog wird im Normalzustand nur massivst und rollierend beschrieben, NIE gelesen, sondern nur im Desasterfall.
=> ein Slog ist eben kein Cache, sondern dient nur der Beschleunigung von sicheren Sync-Zugriffen auf maximal das Niveau von Async-Zugriffen (abzüglich etwas Performance wg dem Slog-Verwaltungsoverhead)
=> Schneller als Async wird es nie werden und auch Async nutzt es gar nicht.
=> Write-Cache bei ZFS ist immer RAM. Nix anderes.
Danke dir für die ausführliche Beschreibung! Bist mein Held des Tages, da du mir (und anderen hier) sehr viel weiter geholfen hast zu verstehen, was ein SLOG ist. Ich habe jetzt noch eine Zusatzfrage an dich, um das Risiko eines Datenverlustes tatsächlich verstehen zu können:
Wenn ich es richtig verstanden habe, hat ZFS ja Copy-on-Write (CoW) als Feature. Das bedeutet, wenn ich eine Datei schreibe, wird die neue Datei irgendwo anders abgelegt und erst dann, wenn der Schreibvorgang erfolgreich erledigt wurde, wird die Metainformation über die Stelle, an der sich die Datei befindet, aktualisiert und damit die Daten der alten Datei zum Überschreiben freigegeben.
Jetzt nehmen wir mal an, ich würde eine 10GB Datei per Samba auf das ZFS-Dateisystem speichern. Dann verstehe ich es so, dass die Daten erst einmal schnell im RAM landen werden, da asynchron (wie oben gelernt). Während die Daten ins RAM geschrieben werden, werden die Daten bereits an neue Positionen auf die Platten verteilt geschrieben. Jetzt sagen wir mal, die 10GB wurden übers Netzwerk übertragen, dann bekommt das OS des Client-Rechners die Meldung "Daten gespeichert" - richtig? Obwohl diese noch nicht auf die Platten geschrieben wurden.
Und jetzt gibt es in dem Moment einen Stromausfall. Dann verstehe ich ZFS und CoW so, dass ich jetzt immer noch die alte Datei auf der dem Dateisystem habe.
Nein
CoW arbeitet nicht dateibasiert sondern auf Basis der ZFS Datenblöcke. Ändert man z.B. in einer Textdatei Haus in Hans so wird bei älteren Dateisystemen eventuell nur das "u" zu "n" geändert. Bei ZFS wird der ganze Datenblock (bis zu 1M) der betroffen ist, neu geschrieben. Ist das erfolgreich werden die neuen Metadaten wirksam. Der alte Datenblock bleibt auf Wunsch als Snap verfügbar oder ist frei für erneutes Beschreiben. Stürzt der Rechner hier ab, bleibt der alte Datenblock aktiv. Es gibt damit per Design kein korruptes Dateisystem und kein fschk/chkdsk zum Reparieren der Metadaten im Gegensatz zu alten Dateisystemen bei denen ein Absturz nach Ändern der Daten und vor dem dann nötigen Aktualisieren der Metadaten zu einem korrupten Dateisystem führt.
Stürzt der Rechner beim Schreiben einer Datei ab, bleibt daher ZFS immer valide (keine korrupten Metadaten). Die betroffene Datei ist aber im Zweifel genau wie bei alten Dateisystemen auch korrupt. Dagegen hilft nur z.B. bei Word ein lokales tmp-File.
Der RAM-Schreibcache dient dazu, kleine langsame Schreibaktionen zu sammeln und als große schnelle Schreibaktion zu schreiben. Der RAM-Cache ist per default 10% des RAM, also z.B. 6GB bei 64GB RAM. Ist der halb voll wird der Inhalt auf Platte geschrieben, der Rest macht Cache für neue Daten.
Stürzt der Rechner ab, ist der Inhalt des Schreibcaches der noch nicht auf Platte ist verloren. Wegen CoW ist das bis auf den Datenverlust kein Problem für ZFS. Hat man aber transaktionale Datenbanken oder VMs so kann da nicht für deren Gültigkeit oder Konsistenz garantiert werden (z.B. Metadaten falsch). Die betroffenen Anwendungen gehen nämlich davon aus das ein bestätigter Schreibvorgang auf Platte ist und nicht im ZFS Cache verlorengeht.
Mit aktiviertem Sync wird daher jeder bestätigte Schreibvorgang zusätzlich zum normalen Schreibvorgang protokolliert ob er tatsächlich bereits auf Platte ist. Wenn nicht wird er beim nächsten Reboot nachgeholt. Damit bedeutet ein write commit dann tatsächlich, auch für VMs dass die Daten auf Platte sind.
CoW arbeitet nicht dateibasiert sondern auf Basis der ZFS Datenblöcke. Ändert man z.B. in einer Textdatei Haus in Hans so wird bei älteren Dateisystemen eventuell nur das "u" zu "n" geändert. Bei ZFS wird der ganze Datenblock (bis zu 1M) der betroffen ist, neu geschrieben. Ist das erfolgreich werden die neuen Metadaten wirksam. Der alte Datenblock bleibt auf Wunsch als Snap verfügbar oder ist frei für erneutes Beschreiben. Stürzt der Rechner hier ab, bleibt der alte Datenblock aktiv. Es gibt damit per Design kein korruptes Dateisystem und kein fschk/chkdsk zum Reparieren der Metadaten im Gegensatz zu alten Dateisystemen bei denen ein Absturz nach Ändern der Daten und vor dem dann nötigen Aktualisieren der Metadaten zu einem korrupten Dateisystem führt.
Stürzt der Rechner beim Schreiben einer Datei ab, bleibt daher ZFS immer valide (keine korrupten Metadaten). Die betroffene Datei ist aber im Zweifel genau wie bei alten Dateisystemen auch korrupt. Dagegen hilft nur z.B. bei Word ein lokales tmp-File.
Der RAM-Schreibcache dient dazu, kleine langsame Schreibaktionen zu sammeln und als große schnelle Schreibaktion zu schreiben. Der RAM-Cache ist per default 10% des RAM, also z.B. 6GB bei 64GB RAM. Ist der halb voll wird der Inhalt auf Platte geschrieben, der Rest macht Cache für neue Daten.
Stürzt der Rechner ab, ist der Inhalt des Schreibcaches der noch nicht auf Platte ist verloren. Wegen CoW ist das bis auf den Datenverlust kein Problem für ZFS. Hat man aber transaktionale Datenbanken oder VMs so kann da nicht für deren Gültigkeit oder Konsistenz garantiert werden (z.B. Metadaten falsch). Die betroffenen Anwendungen gehen nämlich davon aus das ein bestätigter Schreibvorgang auf Platte ist und nicht im ZFS Cache verlorengeht.
Mit aktiviertem Sync wird daher jeder bestätigte Schreibvorgang zusätzlich zum normalen Schreibvorgang protokolliert ob er tatsächlich bereits auf Platte ist. Wenn nicht wird er beim nächsten Reboot nachgeholt. Damit bedeutet ein write commit dann tatsächlich, auch für VMs dass die Daten auf Platte sind.
Zuletzt bearbeitet:
