eigener Homeserver/NAS

Mal auf die letzten Beiträge bezogen: Wenn auf irgendeiner HW kein FreeBSD laufen kann und deshalb nicht ZFS geht, ist das ein absolutes Ausschluss-Argument. Deshalb sind fertige Systeme und viel oder weniger GNU/Linux mit irgendwelchen Gimmicks nicht das Entscheidende. Wichtig ist: geht ZFS darauf?
 
Warum? Was bietet dir ZFS, was MD RAID mit btrfs darüber nicht auch kann?
ich rede mal von mir und tatsächlich hatte ich btrfs nicht mehr auf den Schirm. Es kann sehr wohl eine Alternative zu ZFS sein und es gibt ja auch ZFS für Linux, was ich oben auch einfach unterschlagen hatte.
als ich mir btrfs mal kurz angesehen hatte, fand ich das schön, aber bei weitem nicht so gut nutzbar, wie ZFS udn das lag wohl auch vor allem an der Dokumentation. Seit es dann ZFS auch für Linux gibt, hielt ich btrfs eigentlich für abgesagt.

Also, die Konstruktionen mittels eines md gibt es ja auch für FreeBSD und ich halte davon nicht viel. Gleich nach nach HW-Raid. Das mag sehr gut funktionieren, macht es aber doch recht schwierig, einen Pool in einem anderen System zu importieren.
Den konstruierten Fall angenommen, alle HW macht plötzlich die Grätsche, außer eben die Festplatten, dann kann ich die einfach in meinen PC einbauen und den Pool importieren und gut ist. Bei einem btrfs ist das sehr viel schwieriger, vor allem, wenn es auf md-Geräten verteilt ist. Ich habe damit selbst unter reinen GNU/Linux-Umgebungen schon beliebig Schiffbruch erlitten und möchte das nicht mehr haben.


edit: PS: das würde vielleicht dann auch besser hier passen: https://www.bsdforen.de/threads/gerede-über-dateisysteme.35352/
 
Ich formuliere das villeicht noch mal ein bisschen anders:

Ich schreibe auch nicht in ein Elektronikbastelforum das es ja Verstärkerschaltkreise auch schon fertig zu kaufen gibt ;)
 
Moin pit234a,

Mal auf die letzten Beiträge bezogen: Wenn auf irgendeiner HW kein FreeBSD laufen kann und deshalb nicht ZFS geht, ist das ein absolutes Ausschluss-Argument. Deshalb sind fertige Systeme und viel oder weniger GNU/Linux mit irgendwelchen Gimmicks nicht das Entscheidende. Wichtig ist: geht ZFS darauf?
Ist ZFS so wichtig?
Ist GMirror mit UFS keine Option? Backup auf ein externes Medium musst Du auch bei einem NAS machen, weil auch ein NAS mal kaputt gehen kann.

Schöne Grüße
 
Den konstruierten Fall angenommen, alle HW macht plötzlich die Grätsche, außer eben die Festplatten, dann kann ich die einfach in meinen PC einbauen und den Pool importieren und gut ist.
Dann nimmst du mdadm --assemble und los gehts. Anschließend kannst du das btrfs mounten. :)

ich mag ZFS auch und nutze es sehr gerne, aber so tun als gäbe es keine Alternativen mag ich nicht ;)
 
Als NAS hatte ich eigentlich immer alte durchgereichte PCs genommen, erst mit Linux, dann OpenSolaris bestückt - da ich mit Solaris und ZFS damals beruflich zu tun hatte und begeistert war - die letzte jetzt seit Jahren mit FreeNAS als OS.

Drin ist Supermicro-Board mit IPMI, um es remote an- und abschalten zu können, 16 Gig RAM, und 7 Platten. Das Ding läuft seit Jahren ohne Probleme - und einfacher/komfortabler als mit der FreeNAS Oberfläche kann man das ganze Konglomerat mit ZFS, Shares, Cifs, iSCSI usw fast ned einstellen, schön auf ner Weboberfläche welche stimmig ausschaut und auch funktioniert.

Von den fertig-NAS Synology und QNAP und wie sie alle heißen hört man eigentlich immer "läuft, aber teuer und Support ist grottig) - ich denke es muss jeder selber entscheiden, ob ihm so ne fertig-NAS das Geld wert ist - unter dem Gesichtspunkt, dass ggf "durchgereichte" Hardware noch vorhanden ist, und eigentlich nur mit RAM und Plattenplatz aufgemöbelt werden müsste, was so gesehen günstiger kommt, und bei Synology eh nur ein Linux und bei QNAP ein FreeBSD(?) drunter läuft, also nichts, was man nicht selber handeln könnte.
 
ich mag ZFS auch und nutze es sehr gerne, aber so tun als gäbe es keine Alternativen mag ich nicht ;)

Ich kenne ZFS noch aus SUN Zeiten (btrfs gabs damals zwar schon, aber spielte noch überhaupt keine Rolle) - und damals wars definitiv "the last word in File Systems" wie von SUN beworben...
Wann immer ich kann, nutze ich es heute noch - gerade in FreeBSD macht es Spass, weil es sich fast so wie in Solaris anfühlt :D
Vielleicht hatte ich deswegen nie das Verlangen, einmal BTRFS auszuprobieren, wer weiss.

Nutze aber auch XFS und ext (3/4) standardmäßig - und könnte über keins dieser FS was negatives sagen - die paar Probleme welche ich je hatte (beruflich wie privat) waren immer auf Hardwareprobleme und PEBKAC zurückzuführen, nie vom FS selber...
 
Moin pit234a,


Ist ZFS so wichtig?
Ist GMirror mit UFS keine Option? Backup auf ein externes Medium musst Du auch bei einem NAS machen, weil auch ein NAS mal kaputt gehen kann.

Schöne Grüße

Lass mich mal so sagen: mit ZFS braucht man einige Klimmzüge nicht zu machen und bekommt daher die gewünschten Resultate recht einfach und zuverlässig. Es ist außerdem gut anpassbar an eigene Bedürfnisse, kann locker Raids mit einer oder mehreren Platten Redundanz, ohne dafür noch viel Gedanken zu investieren, es ist bei FreeBSD schon dabei und es erlaubt mit zfs send|receive auch inkrementelle Backups, was natürlich mit rsync auch geht (ich mache das immer noch mit rsync).
In den letzten Jahren lernte ich ZFS mehr und mehr zu vertrauen und dieses Vertrauen wurde bislang nicht enttäuscht. Ganz im Gegenteil wurde ich mehrfach angenehm überrascht, wie gut und leicht man damit umgehen kann. Platten ersetzen, Pool spiegeln, in anderer HW importieren, ich weiß nicht, was ich noch anführen soll: alles einfach mit ZFS. Aus einem Guss, stabil, zuverlässig, leicht zu handhaben und wie gesagt, schon in FreeBSD mitgeliefert.
Mein aktuelles System auf dem PC, den ich gerade nutze, entstand auf anderer HW und wurde dann der Bequemlichkeit halber übers Netz mit zfs send|receive auf die neue HW gespielt. Gut, das hätte ich natürlich auch neu installieren können, es war mehr ein Test. Ich wollte halt mal sehen. Aber das fand ich schon beeindruckend: ein System zum Arbeiten gebootet, auf das andere überspielt, über Netz noch einige Konfigurationen angepasst, neues System gebootet, Monitor und Maus um-gestöpselt und dort weiter gearbeitet. Quasi. Also schon geil.

Ich wollte das auch nicht so verstanden wissen, dass alles, was nicht ZFS ist automatisch technisch schlechter ist (obwohl ZFS einfach der Platzhirsch ist, woran auch BTRFS nichts ändert), sondern, weil es Nutzern das Leben so viel leichter macht, aus Bequemlichkeit für mich gesetzt ist und ich dem deshalb ganz hohe Priorität gebe.
Nein, es muss nicht sein und ja, es gibt viele Alternativen. Aber wenn ich nativ ZFS haben kann, brauche ich diese Alternativen ja gar nicht.
 
hi

sorry wenn ein hersteller auf ein filesystem , in kombination mit lvm fuer raid , setzt welches selbst von den entwicklern
, ganz oder in teilen , nicht fuer produktive umgebungen geegnet eingestuft wird .

so sollte man die fingen von solchen produkten lassen .

hinzukommt dieses vollkommen überladene Closed source OS versionen mit bugs ohne ende,

sorry samba und nfs samt Freebsd ist in 1-2 Stunden eingerichtet.

NAS hardware von hier schon genannten hersteller oder z.b. der HP McroServer sind auch nur , weitgehend ,,
standard komponente.

und mit zfs kannst du alles in einen haben, da benötigst du fuer die raid level keine weiteren tools ala gmirror.

gjournal ist auch nicht nötig , bei verwendung mit zfs.


einzigst geli kann sinn machen ( kommt auf den anwendungszweck an )


holger
 
hi

sorry wenn ein hersteller auf ein filesystem , in kombination mit lvm fuer raid , setzt welches selbst von den entwicklern
, ganz oder in teilen , nicht fuer produktive umgebungen geegnet eingestuft wird .

so sollte man die fingen von solchen produkten lassen .


holger

Hört doch mal auf mit diesem BTRFS Bashing, oder liefert belastbare Quellen. Die einzigen Fälle wo ich von Datenverlust nachvollziehbar gelesen habe, war wenn Leute Raid5/6 eingesetzt haben, und das auf einem eher alten Rhel6/7 Kernel. Und sowohl RHEL als auch die BTRFS-Leute haben davon abgeraten.
Und ja, dieses Feature ist als experimentel gekennzeichnet. Daher verwendet Synology wohl den Linux MD Raid 5 als Unterbau wenn man Raid5/6 möchte. Finde ich durchaus legitim.
SUSE, Facebook und viele andere setzen stark auf BTRFS, von deren Seite gibt es auch viel Entwicklungsarbeit am Code.

In ZoL gabs Mitte letzten Jahres (also 2018) einen gravierenden Bug der zu Datenverlust führen konnte. Jetzt daraus zu schließen alle ZFS Implementierungen sind (auch 1.5 Jahre später noch) anfällig für Datenverlust wäre ebenso absurd.
 
Hört doch mal auf mit diesem BTRFS Bashing
BTRFS ist mir sowas von egal!

Bevor ich meinen Standpunkt als unbedarfter Endanwender weiter erkläre, möchte ich aber meine Erfahrungen mit BTRFS kurz beschreiben.
Ich habe es bisher zwei Mal in einem GNU/Linux testweise benutzt und war absolut beeindruckt!
Sau gute Performance, selbst auf altem P4 mit 500MB RAM mehr als flüssig und super stabil. Mit guter Kompression. Alles was Recht ist: einfach begeistert.

Aber: die Dokumentation ist an sich bereits ziemlich mies und dann laufen die Entwicklungen im Linux-Land derart schnell, dass alle Dokumentation dauernd überholt zu sein scheint. Letztlich hat es mir deshalb keinen Spaß gemacht und mich nicht motiviert, weiter dabei zu bleiben und mehr Erfahrungen zu machen.
Irgendwie glaubte ich schon, dass BTRFS die Zukunft aller Dateisysteme sein würde.
Andererseits ist ZFS nur deshalb nicht genommen worden, weil die Lizenzen nicht zu Linux passten! Was für ein Krampf!
Anstatt sich wegen solcher Details gegenseitig das Leben schwer zu machen, sollte man eher zusammen an OpenSource arbeiten. Was für mich wieder ein Grund mehr für FreeBSD ist, weil dessen Lizenz einfach viel Freier ist, als bei GNU.
Würden alle SW Entwickler nur noch mit GPL(3) entwickeln, wäre natürlich auch gut.

Also, ob wir nun BTRFS mit GPL oder ZFS mit einer anderen Lizenz haben, ist mir eigentlich egal.
Inzwischen ist das Problem aber wohl vom Tisch, denn es gibt ZFS auch Frei (OpenZFS oder so) und schließlich dadurch auch für Linux. Wie ich das sehe ist ZFS-On-Linux der einzig wirklich entwickelte Zweig, zumindest im OpenSource-Feld und es ist auch das, was FreeBSD nutzt.
Da sei mir denn die Frage gestattet: was soll denn da noch BTRFS?

Also absolut kein Bashing von meiner Seite, was die Performance, Stabilität und Einsetzbarkeit angeht.
Aber doch die Frage nach dem Sinn, wenn man doch ZFS haben kann.
 
Also absolut kein Bashing von meiner Seite, was die Performance, Stabilität und Einsetzbarkeit angeht.
Aber doch die Frage nach dem Sinn, wenn man doch ZFS haben kann.

Hey war nicht auf den Post von dir bezogen, sondern auf das von mark05. Deinem Text kann ich nur zustimmen, wobei BTRFS sicher auch ein paar Macken hat.
 
Letztendlich sind sie doch beide warzig. ZFS war zwar nicht das erste Dateisystem mit integriertem Volume Manager, aber das erste Dateisystem, was es auf dieses Niveau getrieben hat. Damit hat es das klassische "Hinterher ist man immer schlauer"-Problem. Vor allem sind ZFS Datenstrukturen rückblickend gesehen viel zu statisch, was es schwer bis unmöglich macht vdev effizient durch das Hinzufügen und Entfernen von Laufwerken zu vergrößern und zu verkleinern. Oder auch der ARC, Das Ding ist mächtig, aber wirklich in den Griff bekommen hat man seinen Ressourcenhunger nie. Außerdem geht ZFS nun auch schon langsam auf die 20 zu, die Welt hat sich seitdem weiterentwickelt und viele Dinge sind später mal hässlich reingefrickelt worden. Mein Lieblingsbeispiel ist das zortsetzbare 'zfs send'.

btrfs war am Anfang ein reines Me-Too Produkt, unter der Federführung von Oracle. Vom Hype getragen sammelte es in den ersten Jahren viel zu viele Features an, bevor die Grundlagen korrekt implementiert wurden. Dann kaufte Orace Sun auf, hatte Zugriff auf das Original und verlor das Interesse an btrfs. Beides hat, ganz unabhängig vom heutigen Stand, den Ruf des Dateisystems nachhaltig ruiniert.

Ich finde bcachefs sehr interessant: https://bcachefs.org/ Weil es alle sinnvollen von ZFS implementiert, dabei aber die Erfahrungen aus ZFS mit einbezieht. Unter anderem nutzt es dynamischere Datenstrukturen und nutzt Linux normalen Dateisystemcache. Und das mit Fokus auf Stabilität statt Features entwickelt wird. Vielleicht wird es dieses Jahr in Linux Mainline aufgenommen. In FreeBSD werden wir es aber aufgrund der GPL eher nicht sehen.
 
es geht nicht um bashing ... siehe

https://btrfs.wiki.kernel.org/index.php/Status

btrfs moechte das sein was zfs ist ... , bleibt aber ein clone.

holgr

Eine Seite die dir aufzeigt, welche Features (eigentlich nur Raid56) du noch nicht produktiv verwenden solltest. Ist doch gut? Oder was willst du mir damit sagen? Und natürlich hatte BTRFS ZFS als Vorbild. Und? *BSD hatte Unix als Vorbild?



Ansonsten muss ich Yamagi mal wieder Zustimmen, bis auf den bcachefs Teil, was das betrifft bin ich doch eher Skeptisch.
Ja es sieht am Papier gut aus, aber es ist eigentlich nur eine Privatperson dahinter, und die will irgendwie eine Dateisystementwicklung über Patreon finanzieren. Das ist mir etwas suspekt. Da muss erstmal mehr zu sehen sein, vorallem von den "interessanten" Features, bevor ich mich da ernsthaft darauf freue.
 
Spielt das Dateisystem bei einem Heimeinsatz überhaupt eine große Rolle? Von der Geschwindigkeit sollte es egal sein da ohnehin das Netzwerk langsamer ist als das langsamste Dateisystem. ZFS mit riesigen Pools die sich selbst regenerieren wenn eine Platte ausfällt und getauscht wird ist zwar recht praktisch, aber ich glaube bei einem Heimeinsatz mit vielleicht 5 Festplatten unnütz. Bei riesigen Systemen mit 1.000 Platten oder so natürlich eine andere Sache und vermutlich ein Segen wenn jede Platte zehnfach gespiegelt ist.

Ich denke mir einmal Zuhause wird man selbst als Extremnutzer niemals die Grenzen der aktuellen Dateisysteme erreichen was Größen oder Inhalte betrifft. Daher würde ich eher etwas wählen mit dem ich mich wohlfühle und was stabil ist. Am Desktop nutze ich schon seit vielen Jahren XFS unter Linux, das ist zwar etwas verpönt bei einigen aber bei mir läuft es und wenn mal was ist kenne ich die Funktionsweise der Tools. Wobei Nvidia Treiber und XFS sorgt für eine Kernel Panic ;)
 
Spielt das Dateisystem bei einem Heimeinsatz überhaupt eine große Rolle?
Aber sicher!
Finde ich.
Es gibt derzeit (afaik) zwei Dateisysteme, die quasi eingebaute Stabilität (Datensicherheit) mitbringen. Das sind BTRFS und ZFS.
Alles andere was man noch von früher kennt, ist einfach veraltet. Macht sicher manchmal noch Sinn (wie etwa XFS oder NTFS), aber wenn man ohne Mehraufwand und Kosten etwas haben kann, das deutlich besser ist, dann macht das doch Sinn, auch, wenn es im spürbaren Ergebnis keine Rolle zu spielen scheint.

Und was ZFS angeht kann ich sagen, dass es sich auch bei wenigen Platten super toll bewährt und einfach zu handhaben ist.
Ich nehme mal dein Beispiel mit XFS.
Das muss ein System ja erst mal können. Dann kann XFS nur Dateisysteme, es ist nicht zugleich auch LVM, wie eben ZFS. Das bedeutet, wenn du mit XFS einen Platten-verband aufbauen möchtest, brauchst du zusätzliche SW und "Klimmzüge". ZFS werfe ich einfach die Platten hin und sage, ich will da nun einen Raid mit zwei Platten Redundanz out of five und es erledigt das! Ich lege einen Pool an und bestimme Datasets mit Eigenschaften, exportiere die womöglich gleich (NFS), nutze Kompression, kann Snapshots machen und die auch archivieren.

Also, ich habe mich selbst viele Jahre gegen ZFS gewehrt und dann nur auf meinem Fileserver benutzt, nicht für den Desktop, weil ich viele viele Argumente dagegen gesehen habe. Es gibt auch wirklich Argumente dagegen. Im Laufe der Jahre machte ich aber mehr und mehr Erfahrungen in die andere Richtung und würde zu einem gläubigen ZFS-Jünger.
Aus meiner Erfahrung heraus denke ich, dass es einfach jeder mal versuchen sollte.
Wobei: man lernt es erst wirklich zu schätzen, wenn man selbst oder seine HW mal so richtig Murks gebaut hat und dann trotzdem Dank ZFS alles ganz einfach wieder zu retten ist. Den schlimmsten Datenverlust hatte ich mal bei einem Zusammenbruch meines Zraid mit einer Platte Platte Redundanz, als eine Platte starb und zwar so, dass dadurch der komplette Pool zerrissen wurde. Spannungseinbrüche und Spitze und Datenstau und so weiter, alles zu Unzeiten, bis die Platte schließlich wirklich ganz gestorben war, richtete sie noch noch sehr viel Unheil an. Im Endeffekt musste ich vier oder fünf Dateien löschen, die nicht wiederhergestellt werden konnten.
Es gibt gerade diesen Beitrag: https://www.bsdforen.de/threads/zfs-überschrieben-und-doch-läuft-es-noch.35361/
der sich ganz ähnlich liest.

Nochmal. Performance ist es nicht. Wobei das ja zwei Seiten hat: die Performance mit den Daten und die im Betrieb, dem Umgang mit dem Pool, der Wartung etc. Auf Datenseite gibt es vielleicht schnellere Alternativen. Aber aus Bequemlichkeit und Überschaubarkeit, Datensicherheit und Zuverlässigkeit, gerade auch in schlechten Zeiten, will man einfach ZFS haben! Oder so etwas in der Art.
 
Es hat gibt sicher gute Gründe, warum Red Hat den Support für btrfs komplett eingestellt hat:
https://access.redhat.com/documenta...4_Release_Notes-Deprecated_Functionality.html
Btrfs has been deprecated

The Btrfs file system has been in Technology Preview state since the initial release of Red Hat Enterprise Linux 6. Red Hat will not be moving Btrfs to a fully supported feature and it will be removed in a future major release of Red Hat Enterprise Linux.
The Btrfs file system did receive numerous updates from the upstream in Red Hat Enterprise Linux 7.4 and will remain available in the Red Hat Enterprise Linux 7 series. However, this is the last planned update to this feature.

Und: https://access.redhat.com/documenta...and-storage_considerations-in-adopting-rhel-8
12.1.1. Btrfs has been removed

The Btrfs file system has been removed in Red Hat Enterprise Linux 8. This includes the following components:

The btrfs.ko kernel module
The btrfs-progs package
The snapper package
You can no longer create, mount, or install on Btrfs file systems in Red Hat Enterprise Linux 8. The Anaconda installer and the Kickstart commands no longer support Btrfs.

Ich weiß, dass btrfs bei SuSE inzwischen das Default Filesystem ist - zu SuSE kann ich nichts sagen.
Aus eigener Erfahrung im Midrange/Enterprise Umfeld kann ich aber berichten, dass wir bei Red Hat mit btrfs schon einige Totalausfälle hatten, mit ZFS unter Solaris in weit über 10 Jahren aber noch keinen einzigen (kein RAID 5/6, nur Stripe oder Mirror).
Wir haben unter Red Hat ziemlich schnell wieder auf die Kombination lvm/XFS gewechselt.
 
Es hat gibt sicher gute Gründe, warum Red Hat den Support für btrfs komplett eingestellt hat:
https://access.redhat.com/documenta...4_Release_Notes-Deprecated_Functionality.html


Und: https://access.redhat.com/documenta...and-storage_considerations-in-adopting-rhel-8


Ich weiß, dass btrfs bei SuSE inzwischen das Default Filesystem ist - zu SuSE kann ich nichts sagen.
Aus eigener Erfahrung im Midrange/Enterprise Umfeld kann ich aber berichten, dass wir bei Red Hat mit btrfs schon einige Totalausfälle hatten, mit ZFS unter Solaris in weit über 10 Jahren aber noch keinen einzigen (kein RAID 5/6, nur Stripe oder Mirror).
Wir haben unter Red Hat ziemlich schnell wieder auf die Kombination lvm/XFS gewechselt.

RHEL hat leider nie die Patches auf ihre Kernel backported, somit war BTRFS auf RHEL immer um Jahre zurück. Daher gab es Probleme mit Raid5/6, beim Rebalance und auch mit vollwerdenen Platten. Alles wurde aber extrem schnell gefixed, nur kam es eben nie in RHEL an.
Dann hat Redhat einen Spezialisten für Deduplication in großen Storagenetzen gekauft und hat komplett das Interesse an BTRFS verlohren. Jetzt machen sie Stratis.


Suse nutzt nicht nur BTRFS, sondern beteiligt sich auch aktiv an der Entwicklung (mit Facebook der größte Contributor). Auch SAP Produkte (was oft nur auf Suse zertifiziert ist) verlangen für einige Featues nach BTRFS.
 
sofern man auch konsequent ECC RAM im Server verwendet

Das ist übrigens bei normalem DDR4 RAM gar nicht mehr sooooo wichtig. Natürlich schützt es nicht vor einem kosmischen Strahl, der dir mit einer Wahrscheinlichkeit von 1:10000000000 bei einem Lesevorgang ein bit flipped. Aber DDR4 hat aber mittels WriteCRC ein Feature was bei Schreibvorgängen prüft, ob die Daten die gerade geschrieben werden sollen auch wirklich so im RAM angekommen sind. D.h. wenn dein RAM kaputt ist, dann wird das bei DDR4 recht schnell ersichtlich.

Und auch ein simpler Bitflip vom RAM wird ZFS nicht gleich zur Katastrophe treiben. Da muss schon eine etwas längere Kette an geflippten Bits auftreten bevor hier wirklich was kaputt geht.
 
.... kosmischen Strahl, der dir mit einer Wahrscheinlichkeit von 1:10000000000 bei einem Lesevorgang ein bit flipped

Ich erinnere mich dunkel, dass ich mal mit SGIs gearbeitet hatte, ich meinte die meldeten einem per Dialog auf dem Screen, wenn im RAM ein Error auftrat und wg des ECC behoben werden konnte - und ja, das kam öfter im Jahr mal vor, auf verschiedenen SGI Maschinen (O2, Octane iI und wie die alle hießen)... könnte aber auch an der Hitze gelegen haben, im Sommer wurden die Octanes unerträglich heiß und lärmten auch ordentlich.

Wobei ECC auch nicht zaubern kann, es können nur single-Bit-Flips erkannt werden usw.

Grade zum Thema "ZFS und ECC - warum?" gibts Lesestoff im Netz, auch von den Autoren von ZFS, zB Matthew Ahrens.
Man kann (und sollte, wenn man seine Daten "liebt") ECC RAM einsetzen, muss aber nicht - zwingt einen ja keiner.

Ohne ECC kann man das wenig dokumentierte Flag "ZFS_DEBUG_MODIFY" (zumindest in der Original-SUN Implementierung von ZFS, ob das bei FreeBSD bereits drin ist, weiss ich nicht) setzen, dann macht ZFS selbst ein Checksumming im (non-ECC) Memory, etwas zusätzliche Sicherheit - hundertprozentige Sicherheit wirds in dem Metier aber eh nie geben.

Den angesprochenen DDR4 RAM mit WriteCRC kannte ich noch gar nicht bzw war mir noch kein Begriff - setzt den jemand hier ausm Forum ein, könnts dazu was (positives) sagen?
 
Ich halte es nach wie vor für fragwürdig ZFS in die alte ECC-Diskussion mit hineinzuziehen. Denn letztendlich macht es keinen praktischen Unterschied, ob man Bitkipper mit einem Dateisystem ohne oder mit integrierter Konsistenzprüfung hat:
  • Bei klassischen Dateisystem muss davon ausgehen, dass die Daten mit gekippten Bits, also inkonsistent, auf die Platte geschrieben wurden. Außerdem können die Metadaten beschädigt sein und bei einem fsck oder Äquivalent können die Metadaten noch weiter zerstört werden. Das geht bis zu dem Punkt, dass das Dateisystem nicht mehr lesbar ist.
  • Bei ZFS wird durch die Prüfsummen erkannt, dass ein Bit gekippt ist. Ob in der Prüfsumme oder in den Daten kann man nicht sagen. Außerdem kann 'zfs scrub' durch weitere Bitkipper korrekte Daten für inkonsistent halten. Das kann soweit gehen, dass keine Datei in dem Pool mehr lesbar ist. Außerdem kann der Pool durch defekte Metadaten zerstört werden.
Bei ECC-RAM geht es nur um die Frage, ob einem die Vorteile von ECC-RAM wie Datenkonsistenz oder die Vermeidung der Nachteile wie höhere Preise, Latenzen und niedrigere Bandbreite wichtiger sind. Und das hängt sehr vom Workload oder ganz allgemein den eigenen Anforderungen ab. Beispielsweise nutze ich diesen Desktop hauptsächlich um Texte zu schreiben, Bilder zu bearbeiten und zu spielen. Dafür brauche ich keinen ECC-RAM, ganz im Gegenteil. Da will ich 3200 MHz Module mit niedrigen Latenzen haben. Als ich seinerzeit über Tage und Nächte perfekte Hashfunktionen gesucht habe, sah die Welt ganz anders aus. Da wollte ich sicher sein, dass das Ergebnis stimmt, also hatte mein damaliger Desktop ECC-RAM drin.
 
Zurück
Oben