News Dateisystem: ZFS für Linux gilt als produktionsreif

Hallo, mir erschliesst sich bis heute nicht der Vorteil von ZFS. Wenn mir die Daten wichtig sind, wird man doch einen hochwertigen Raid-Controller verwenden? Wo ist der Vorteil bei einem hochkomplexen Softraid?
 
RAID hat keine Prüfsummen. ZFS sichert gleichzeig auch die Konsistenz der Daten.
 
Eben WENN mir Daten wichtig sind benutze ich keinen RAID-Controller.

Geht der Controller kaputt, und habe ich keinen exakt gleichen Ersatzcontroller kann mir niemand garantieren daß ich meine Platten noch lesen kann. Der Controller bringt eigentlich nur Geschwindigkeit, da er die CPU entlastet. Die Sicherheit gegen Stromausfall gibt mir eine USV auch ohne Controller, so können alle Schreibvorgänge korrekt beendet und das System heruntergefahren werden (ZFS aber ist nicht einmal darauf angewiesen).

Will ich also Geschwindigkeit, dann nehm ich einen Controller. Will ich Sicherheit pfeiff ich auf den Controller und bin eben unter Umständen langsamer unterwegs. Man kann nicht alles haben.

Gerade ZFS hat aber schon einige Vorteile wenn man Wert auf Datensicherheit legt. Prüfsummen für Datenblöcke, so daß fehlerhafte Schreibvorgänge sofort erkannt werden, oder bei Langzeitarchivierung wreden gekippte Bits erkannt. Wer hat noch nie auf eine uralte Datei zugegriffen die er schon ewig irgendwo mitzieht, die sich nicht mehr richtig oder gar nicht offnen lässt? Kann mit ZFS nicht so leicht passieren. Das Dateisystem bleibt auch bei Stromausfällen konsistent und muß danach nicht komplett geprüft werden. Man kann problemlos sofort Snapshots des Dateisystems erstellen. Deduplikation ermöglicht es Speicherplatz zu sparen (Blöcke die gleich sind werden nicht mehrfach geschrieben, nur ein Querverweis auf den bereits vorhandenen Block). Habe ich also z. B. aus welchem Grund auch immer eine Datei zweimal oder öfter auf dem Volume benötige ich nur den einfachen Platz. Allerdings muß es sich damit diese Funktion greift nicht um eine komplette Datei handeln.

Der einzige Nachteil von ZFS ist daß je nachdem welche Funktionen man davon nutzt das ganze schon hardwarelastig werden kann. Für Deduplikation z. B. wird so grob empfohlen glaub ich 1 GB RAM pro TB Plattenkapazität. Man kann den Speicherbedarf dafür auch auf eine SSD auslagern, geht aber dann auf Kosten der Geschwindigkeit.
 
Zuletzt bearbeitet:
Man kann den Speicherbedarf dafür auch auf eine SSD auslagern, geht aber dann auf Kosten der Geschwindigkeit.
Nein zumindest für die DDT geht das soweit ich weiß nicht, die MUSS im Ram stehen. Man kann aber mit ner SSD Cachen nur die DDT bleibt aber im RAM.

1 GB RAM pro TB Plattenkapazität.
Irgendnen Entwickler hatte das mal durchgerechnet: Geht man bei 1TB vom Worstcase ist die DDT 5GB groß. Allerdings darf die DDT nur 25% des Rams einnehmen was dann schon 20GB RAM pro 1TB bedeutet.

Für 99,9% der Leute dürfte es daher billiger kommen einfach mehr HDD Speicher zu kaufen.

Hat auch nix mit schlechter Programmierung zu tun sondern dass ich ganz einfach der Preis von Echtzeit Dedup.

Der einzige Nachteil von ZFS ist daß je nachdem welche Funktionen man davon nutzt das ganze schon hardwarelastig werden kann.
Ich finde der einzige Nachteil von ZFS mal abgesehen vom ZoL Projekt ist der dass es das sonst nur unter FreeBSD und Solaris, OmnisOS etc gibt. Und es für diese Betriebsysteme nicht soviel Software gibt wie für Linux.

Wenn mir die Daten wichtig sind, wird man doch einen hochwertigen Raid-Controller verwenden? Wo ist der Vorteil bei einem hochkomplexen Softraid?
ZFS ist mehr als Raid. Raid ist out und Raid wurde auch nur erfunden um alte Dateisystem weiterhin verwenden zu können.

Wenn du unter Windows bist und NTFS benutzen willst musst du NTFS ein großes Volume vorgaukeln.
ZFS geht halt einen komplett anderen/neueren und kleverern Weg.

Du hast nur Vorteile: Kommst überall an deine Daten brauchst nur genug SATA Ports und keinen Baugleichen Controller. Du hast kein Write Hole. Du sparst dir nen Hardware Controller samt BBU. Du kannst sämtliche Systemrssourcen zum Cachen nutzen nicht nur die 512MB des Raidcontrollers. Bist also nur dadurch Limitiert wieviel Ram dein Mainboard aufnehmen kann.

Es ist eigentlich allem anderen was man so hat deutlich überlegen.
 
Zuletzt bearbeitet:
phi schrieb:
Hallo, mir erschliesst sich bis heute nicht der Vorteil von ZFS.

Dein Windows ... "verliert" einfach Daten und kann es auch nicht mit einem Duplikat vergleichen.

ZFS kann das, man nehme an, Du hast 2 Festplatten, das wäre dann RAID-Z (1) Spiegelung/mirror

Dies bedeutet, das ein Duplikat von jeder Datei auch auf der 2. Festplatte geschrieben wird.

Wenn die Prüfsumme von Datei A falsch ist, dann schaut ZFS auf der 2. Festplatte nach und nimmt die Datei mir der korrekten Prüfsumme.

Es giebt zig Vorträge bei YouTube zu ZFS und sogar Videos wie Festplatten mit Absicht zerstört werden, um die "Selbstheilung" des Dateisystems zu veranschaulichen.

Benutze PC-BSD mit 2 Festplatten RAID1 oder 4 im RAIDZ2, dabei können ganze 2 Festplatten ausfallen ohne das Du Daten verlierst !

http://de.wikipedia.org/wiki/RAID#RAID-Z_im_Dateisystem_ZFS

http://www.pcbsd.org/en/about/

http://iso.cdn.pcbsd.org/10.1-RELEASE/amd64/
Ergänzung ()

NobodysFool schrieb:
Man kann den Speicherbedarf dafür auch auf eine SSD auslagern, geht aber dann auf Kosten der Geschwindigkeit.

Das ist im Installer von PC-BSD scon seit längerem möglich ...

Je nachdem wie viele Festplatten od. SSD's Du hast, kannst Du je eine SSD als Zwischenspeicher benutzen. L2ARC

http://open-zfs.org/wiki/Main_Page
http://open-zfs.org/wiki/Documentation
http://de.wikipedia.org/wiki/ZFS_(Dateisystem)#Eigenschaften
https://wiki.freebsd.org/ZFSTuningGuide L2ARC discussion
 
Zuletzt bearbeitet:
NobodysFool schrieb:
Deduplikation ermöglicht es Speicherplatz zu sparen (Blöcke die gleich sind werden nicht mehrfach geschrieben, nur ein Querverweis auf den bereits vorhandenen Block). Habe ich also z. B. aus welchem Grund auch immer eine Datei zweimal oder öfter auf dem Volume benötige ich nur den einfachen Platz. Allerdings muß es sich damit diese Funktion greift nicht um eine komplette Datei handeln.

Richtig, denn das geht auf Blockebene, nicht auf Dateiebene. Für den typischen User zuhause (was nie ZFS-Zielgruppe war, aber mit ZOL irgendwie wird) täts oft auch Deduplizierung auf Dateiebene, also eine reine Erkennung von kompletten Duplikaten, was dann massiv RAM für die Dedup-Table sparen würde. So braucht man für jeden Block (bis 128K?) etwas über 300 Bytes für die Verwaltung des Hashwerts dieses Blocks. Das klingt nicht viel, läppert sich über hunderte GB oder gar TB aber schon deutlich zusammen.
Davon abgesehen frisst die Prüfsummenberechnung extrem viel Leistung, was die Sun-/Oracle-Maschinen mit ner Hardwarebeschleunigung kompensieren (ähnlich AES-NI für hardwarebeschleunigte AES-Verschlüsselung), aber auf den Consumerkisten hat man das ja nicht. Oder noch nicht. Ergo ist Dedup heute leider meist ne schlechte Idee. Dedup auf Dateiebene wär für mich ein deutlicher Anreiz, vom Oracle-ZFS auf ZOL oder die Implementierungen in Illumos zu wechseln...kann mich aber eigentlich nicht beklagen, läuft fein und hat schon so einige kritische Situationen ohne großes Gemecker oder gar Datenverlust gemeistet:daumen:


Marco^^ schrieb:
Benutze PC-BSD mit 2 Festplatten RAID1 oder 4 im RAIDZ2, dabei können ganze 2 Festplatten ausfallen ohne das Du Daten verlierst !

Naja, die Anzahl Platten ist nicht ganz das Jagdgebiet von RAIDZx. Für ganz hochverfügbare Sachen kann man Triple-Mirrors erstellen, bei denen drei Platten den selben Inhalt haben, und eben zwei davon ausfallen dürfen. Z1 bietet sich für 5 oder 9 Platten an, Z2 für 6, 10, und Z3 eben für 7 und 11. Die Konfiguration mit effektiven 2 Datenplatten und der Rest für Parität ist halt ein wenig verschwenderisch. Aber klar, geht alles. Ich hab ja auch ein Z2 mit 8 Platten, also ner krummen Aufteilung.
 
Zuletzt bearbeitet:
DaBzzz schrieb:
Für den typischen User zuhause (was nie ZFS-Zielgruppe war, aber mit ZOL irgendwie wird) täts oft auch Deduplizierung auf Dateiebene, also eine reine Erkennung von kompletten Duplikaten, was dann massiv RAM für die Dedup-Table sparen würde.

https://wiki.freebsd.org/ZFSTuningGuide#Deduplication


Ich benutze 8 GB an RAM ohne Probleme zu haben, allerdings mache ich ja auch nicht viel oder kopiere mehrere kleine Dateien.

Laptop & home PC mit PC-BSD ist brauchbar ohne Probleme.
 
Marco^^ schrieb:
Das ist im Installer von PC-BSD scon seit längerem möglich ...

Je nachdem wie viele Festplatten od. SSD's Du hast, kannst Du je eine SSD als Zwischenspeicher benutzen. L2ARC

Die Nutzung von SSDs gibt meines Wissens nach nur einen größeren ARC, daher auch die Bezeichnung L2ARC (= Level 3 Adaptive Replacement Cache). Davon profitieren andere Features von ZFS, insbesondere Deduplikation also nicht.
Das Nutzen von SSDs um den Speicherbedarf decken zu können entspricht ganz normalem Swapen, ist also ohne speziellen ZFS Mechanismus möglich (wenn man ZFS dazu überredet kriegt, mehr RAM zu verwenden als man hat).
 
das L2ARC beschleunigt den Zugriff auf die häufig genutzten Dateien hier schon und mit folgendem Patch:
https://github.com/zfsonlinux/zfs/pull/2672
überlebt der cache auch einen Reboot ;)

wenn man für die Prüfsummen sha256 benutzt, lässt sich das ganze bereits schön mit avx or avx2 beschleunigen:
https://github.com/zfsonlinux/zfs/pull/2351
hatte bis jetzt keine Probleme damit, wie das ganze mit Dedup ausschaut möchte ich mir aber nicht antun :lol:


hatte bis jetzt noch keinen Datenverlust, Crash, Datenkorruption, oder Ähnliches mit ZoL - und es wird alle paar Wochen performanter & noch "stabiler" wenn man die aktuelle Liste an ausstehenden Pulls betrachtet:
https://github.com/zfsonlinux/zfs/pulls?q=is:open+is:pr

und die aktuellen Änderungen seit 0.6.3:
https://github.com/zfsonlinux/zfs/commits/master




zu NTFS, Windows und Prüfsummen:
ReFS sollte zumindest einen Teil der Funktionen von Btrfs und ZFS beherrschen:
http://www.infotechguyz.com/windowsserver8/WindowsServer8ResilientFileSystemExplained.html
http://en.wikipedia.org/wiki/ReFS
http://betanews.com/2014/01/15/windows-storage-spaces-and-refs-is-it-time-to-ditch-raid-for-good/
http://theithollow.com/2014/01/microsofts-resilient-file-system-refs/

wie das ganze in der Praxis ausschaut, muss sich entweder zeigen bzw. muss ich erst noch Berichte dazu finden :evillol:
 
so wie ich das verstanden habe nimmt der ZFS-port auf Linux teils eine Vorreiterrolle ein (z.B. mit den Checksummen hier) und falls es etwas gibt, was es auf den anderen Platformen bzw. Betriebssystemen noch nicht gibt, sollte dies nachgeholt werden - an sich soll aber Illumos die Referenz-Platform sein, wo es die meisten Funktionen gibt: https://www.illumos.org/issues/3525

ist korrekt: diese Fähigkeit fehlte wohl aber noch und wird dann überall nachgereicht


Derzeit fehlen noch 18 Funktionen des Originals, die aber bereits jetzt zum Teil per Workaround realisierbar sind.

ZoL is close to feature parity with ZFS on other platforms.
Sharing a common code base with other Open ZFS platforms has given ZFS on Linux the opportunity to rapidly implement features available on other Open ZFS platforms. At present, Illumos is the reference platform in the Open ZFS community and despite its ZFS driver having hundreds of features, ZoL is only behind on about 18 of them. Let’s break these 18 features not currently in ZoL in 3 categories:

Quelle: https://clusterhq.com/blog/state-zfs-on-linux/


ist eigentlich alles bei http://open-zfs.org/wiki/Main_Page und http://open-zfs.org/wiki/Features beschrieben und aus den/der Tabelle(n) ersichtlich
 
Was sagen eigentlich die Spezialisten dazu, dass im Falle eines defekten RAM's die Daten auf der Festplatte geschrottet werden könnten? Dies behaupten zumindest die Moderatoren vom Nas4free Forum und raten zu ECC Speicher um dieses eventuelle Problem zu umgehen.
 
Wenn ich defekten RAM habe, besteht immer die Gefahr, daß ich Müll auf die HDD schreibe.
Ergänzung ()

Durch das transaktionale Filesystem werden nach dem Ausfall, beim anschließenden Resync nur die fehlenden Transaktionen nachgezogen.
Die früheren Mirroring-Verfahren arbeiteten eine Stufe tiefer und mußten das komplette Device neu aufbauen, weil der RAID-Controller keine Ahnung hat, was für Daten auf einem Volume liegen. Wegen der langen Resync-Zeit war es auch sehr riskant, nur 2 Spiegel zu betreiben.

ZFS hat aber auch 2 große Nachteile:

1. Wir der ARC-Pool nicht limitiert (was gedankenlose Admins gerne unterlassen), bekommten manche Programme keinen RAM mehr zugewiesen, bzw. erst nach mehrmaliger Anforderung. Der RAM wird theoretisch "sofort" freigegeben, in der Praxis klappt das aber nur stark zeitverzögert.

2. Fragmentierung: Da nicht direkt überschrieben wird, sondern copy-and-write Anwendung findet, werden die Daten über das gesamte Volume verteilt, was nach wenigen Monaten die Performance in den Keller zieht. Lesegeschwindigkeiten von <15MB/s sind keine Freude für den Anwender. Die derzeit einzige Lösung ist, die Daten sichern, den Pool neu aufzubauen und Backup wiederherstellen.

Mal so in die Runde gefragt, was habt ihr so für Leseleistungen (MB/s) incl. der jeweils gewählen Blocksize ?
 
Was gibts daran nicht zu glauben? Die tollste Prüfsumme taugt nix, wenn sie durch defekten RAM unterwegs verändert wird. Sollte dann nicht noch ne weitere Prüfsumme darüber liegen, ergibt sich eine wem-glaub-ich-jetzt-Situation. Man kann knobeln, welche(s) Bit(s) von Hash oder Datenpaket man verändern muss, damit wieder alles passt. Da dürfen sich Mathematiker dran auslassen, was wahrscheinlicher ist. Hat man aber ne Kopie der Hashsumme woanders (und ZFS hasht gerne viel und redundant), und sind beide identisch (aber falsch), dann glaubt man wohl dem und modifiziert den korrekten Datenblock dann entsprechend...

Sagen wirs anders: Da steckt man hunderte Euro in CPU, RAM, Controller, Festplatten, Gehäuse, Kühler, Lüfter und andere Spielereien, und dann spart man sich wegen 5€ pro Riegel die ECC-Funktionalität? Ganz klassisch am falschen Ende gespart. Das heißt, wenn man AMD-User auf AM3/+ ist. Auf den APUs gibts das leider nicht, was im Hinblick auf die FirePro eigentlich erschreckend ist. Intel sieht es als $$$-Serverfeature an, und deaktiviert auf vielen CPUs (übrig bleiben viele Celerons und Pentiums..yay!) und allen Consumer-Chipsätzen die ECC-Unterstützung. Ende vom Lied: Man braucht für ein ECC-Build einen Serverchipsatz, was dann Boardkosten von 200€+ nach sich zieht. Für mich einer von vielen Anreizen, einen FX-6300 auf ein Asus-Board zu pflanzen und ihm 2x8GB DDR3-ECC zu spendieren. Alles andere hätte massiv mehr gekostet, aber keine Mehrleistung im Betrieb erbracht.

@Kowa: Solangs nicht zu kleiner Kram ist, hab ich Auslastung von ner Gigabitleitung zwischen Intelkarte im Server und Intelchip im Laptop, also irgendwas bei 100 MB/s. Bei Bedarf kann ich das mal benchen.
 
Suxxess schrieb:
Was sagen eigentlich die Spezialisten dazu, dass im Falle eines defekten RAM's die Daten auf der Festplatte geschrottet werden könnten? Dies behaupten zumindest die Moderatoren vom Nas4free Forum und raten zu ECC Speicher um dieses eventuelle Problem zu umgehen.
Haste bei anderen Systemen genauso daher ist es kein wirkliches "Problem". Selbst ohne ECC ist ZFS immer noch sicherer.

2. Fragmentierung: Da nicht direkt überschrieben wird, sondern copy-and-write Anwendung findet, werden die Daten über das gesamte Volume verteilt, was nach wenigen Monaten die Performance in den Keller zieht. Lesegeschwindigkeiten von <15MB/s sind keine Freude für den Anwender. Die derzeit einzige Lösung ist, die Daten sichern, den Pool neu aufzubauen und Backup wiederherstellen.
Zumindest erstmal ein theoretisches Problem. Kommt aber auch sehr drauf an wie man seinen Pool nutzt. Wenn quasi als Datengrab mit jede Menge Filme dürfte das Problem eher relativ egal sein.

Man braucht für ein ECC-Build einen Serverchipsatz, was dann Boardkosten von 200€+ nach sich zieht
Oder halt fertig Systeme wie den T20 von Dell oder HP Microserver
 
Zuletzt bearbeitet:
Marco^^ schrieb:
Wenn die Prüfsumme von Datei A falsch ist, dann schaut ZFS auf der 2. Festplatte nach und nimmt die Datei mir der korrekten Prüfsumme.
Das ist immer nur ein Spiel mit Statistik, nicht mehr aber auch nicht weniger. Für SW und HW gibt es keinen Weg herauszufinden, welche Daten korrekt sind und welche nicht. Dein Beispiel deutet das schon an. Eine Datei mit nur einfachen Prüfsummen ist toll, aber eigentlich Quatsch, weil niemand genau sagen kann, ob Daten oder Prüfsummen falsch sind. Wenn ich jetzt noch Sektor-Prüfsummen auf der HW heranziehe, habe ich schon 3 Prüfsummen vs. einen Datensatz. Gleiches trifft auf die Spiegelung zu, welche allein auch keine Aussagen zulässt. Auch hier habe ich zwar wieder Prüsummen, die aber gemeinsam erstellt wurden. Wenn da oder bei der Übertragung was schief läuft (ECC) ist das alles für die Katz. Die Sicherheit ließe zwar sich noch mal drastisch durch write & verify erhöhen, das ist aber zu leistungsintensiv, da es die bei komplexen Dateisystemen sowieso nicht so hohe Schreibleistung mal locker halbiert und auch parallele Lesezugriffe beeinflusst.


Bogeyman schrieb:
Raid wurde auch nur erfunden um alte Dateisystem weiterhin verwenden zu können.
RAID stammt vom Ende der 80er Jahre. Für welche wichtigen Dateisysteme aus der Zeit davor (also 60er, 70er bis Mitte der 80er) sollte denn Deiner Meinung nach durch Entwicklung des RAID der Weitereinsatz gewährleistet werden?


Haste bei anderen Systemen genauso daher ist es kein wirkliches "Problem". Selbst ohne ECC ist ZFS immer noch sicherer.
Mit seinem Featureset ist es eben gerade ein Problem bei ZFS. Wenn ich einen Großteil dessen aber deaktiviere, dann ist ebenso sicher wie jedes andere FS.


Kommt aber auch sehr drauf an wie man seinen Pool nutzt. Wenn quasi als Datengrab mit jede Menge Filme dürfte das Problem eher relativ egal sein.
Welches Feature prädestiniert gerade ZFS für die simple Speicherung von Filmen auf einem NAS?


Wenn du unter Windows bist und NTFS benutzen willst musst du NTFS ein großes Volume vorgaukeln. ZFS geht halt einen komplett anderen/neueren und kleverern Weg.
Das ist Jacke wie Hose auf welcher Ebene Du etwas vorgaukelst, solange es nur tief genug angesiedelt ist. Und die Trennung von Pool und FS bei NTFS hat ebenso Vorteile, weil z.B. Probleme unabhängig voneinander gelöst werden können, und auch weil die Entwicklung unabhängig voneinanderweitergetrieben werden kann. Diese Unabhängigkeit hat u.a. zur Folge, dass Du auf dem selben Pool einfacher ein anderes Dateisystem aufsetzen kannst, bei ZFS wäre eine komplette Neuentwicklung notwendig.
Ein komplett "neuer" Weg ist logisch, ist das FS doch um die 20 Jahre jünger, "anders" sollte wohl auch so sein. Aber clever ist immer relativ, soll heißen, dass sich bei genauem Hinschauen immer Vor- und auch Nachteile auf beiden Seiten finden lassen.

p.s. Ein klever Weg wäre es nur dann, wenn man es nach der Art der Leute aus Kleve machen würde. ;)
 
Zuletzt bearbeitet:
Das ist immer nur ein Spiel mit Statistik, nicht mehr aber auch nicht weniger. Für SW und HW gibt es keinen Weg herauszufinden, welche Daten korrekt sind und welche nicht. Dein Beispiel deutet das schon an. Eine Datei mit nur einfachen Prüfsummen ist toll, aber eigentlich Quatsch, weil niemand genau sagen kann, ob Daten oder Prüfsummen falsch sind.

Du weißt schon dass eine Prüfsumme deutlich weniger Bit hat als der Block, wenn du schon mit Warscheinlichkeit argumentierst? Du weißt sicherlich auch dass bei ZFS Prüfsummen im Vergleich zu den Daten doppelt vorhanden sind (selbst ohne Spiegelung oder irgendwelche "Raid" Level, sprich bei einem Pool aus nur einer Platte).
Bei einem Mirror aus 2 Platten haste also insgesamt 4mal dieselbe Prüfsumme. Es gibt außerdem auch noch Prüfsummen von den Blöcken mit den Prüfsummen. ZFS kann daher durchaus feststellen ob Prüfsumme oder der entsprechene Block mit den Daten falsch ist. Man war damals ja auch net blöd..

RAID stammt vom Ende der 80er Jahre. Für welche wichtigen Dateisysteme aus der Zeit davor (also 60er, 70er bis Mitte der 80er) sollte denn Deiner Meinung nach durch Entwicklung des RAID der Weitereinsatz gewährleistet werden?
Welche "modernen" Dateisysteme können denn mit mehreren Platten umgehen? NTFS? ext3,4 ? Können sie es? Kein anderes Dateisystem beherscht es, auch 2014 bekommst man NTFS mit mehreren Platten nur ans Laufen über Raid

Diese Unabhängigkeit hat u.a. zur Folge, dass Du auf dem selben Pool einfacher ein anderes Dateisystem aufsetzen kannst, bei ZFS wäre eine komplette Neuentwicklung notwendig.
Und das braucht man? Wo sind die Leute die FAT32 und NTFS parallel einsetzen wollen auf einem Array?

Ein Dateisystem überlebt für gewöhnlich auch zig Generationen von Betriebssystemen. Ich wüsste daher nicht welchen Sinn so etwas haben sollte.

Mit seinem Featureset ist es eben gerade ein Problem bei ZFS. Wenn ich einen Großteil dessen aber deaktiviere, dann ist ebenso sicher wie jedes andere FS.
Durch fehlenden ECC Ram wird nix "deaktiviert". Sorry aber das ist Schwachsinn. Selbst ohne ECC ist es sicherer als andere Dateisysteme. Es sind nur Fehler im Ram nicht erkennbar. Tja aber ohne ECC haben das alle Systeme und darüberhinaus können sie unabhängig von ECC Fehler auf den Platten nicht erkennen, die ZFS erkennen kann.

Welches Feature prädestiniert gerade ZFS für die simple Speicherung von Filmen auf einem NAS?
Es ist billiger, denn ich brauche keinen Hardwarecontroller. Nochdazu ist es sicherer als Raid, denn ich habe kein Write Hole. Ich muss bei einem HDD Ausfall nicht das gesamte Array Widerherstellen sondern nur die Bereiche wo überhaupt Daten gespeichert wurde, ergo deutliche Zeitersparnis und weniger Belastung für die HDD und so weiter, werd jetzt nicht alles aufzählen dass kann man sich selber raussuchen falls man Interesse dran hat..
 
Zuletzt bearbeitet:
Zurück
Oben