News Dateisystem: ZFS für Linux gilt als produktionsreif

Mal eine Frage: Wo steht BTRFS im Vergleich zu ZFS?
 
Bogeyman schrieb:
... eine Prüfsumme deutlich weniger Bit hat als der Block ... Bei einem Mirror aus 2 Platten haste also insgesamt 4mal dieselbe Prüfsumme.
Die Anzahl der Bits ist so lange irrelevant, wie sie nicht den Informationsgehalt reduziert. Ich schrieb ja auch, dass Du das Problem schon angedeutet, es aber eben nicht ausgeführt hattest, was aber für das Verständnis all derer, die hier nur mal so im Forum Infos sammeln, wichtig sein kann bzw. wichtig ist. Wie ich in meinem Post und Du dann auch in Deinem zweiten richtig schriebst, gibt es eben noch mehr Stellen, die der Gegenprüfung dienen, wenn man die aber einfach unter den Tisch fallen lässt, wie in Deinem ersten Post getan, dann wird das ganze ziemlich sinnfrei. (Nicht für mich und wohl auch nicht für Dich, aber für die, die das Hintergrundwissen nicht haben).


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
Nö, LDM oder Storage Spaces nennt sich das für Windows und unter Linux macht das gleiche der LVM. Beide sind über mehrere HW-Geräte spawnbar.

Ein Dateisystem überlebt für gewöhnlich auch zig Generationen von Betriebssystemen. Ich wüsste daher nicht welchen Sinn so etwas haben sollte.
Unter Linux aber auch für BSD&Co. ist es am ehesten einsichtig. Die unterstützen von Haus aus verschiedene Dateisysteme, da wäre eine Implementierung direkt in jedes dieser Dateisysteme einer Sisysphosarbeit gleichgekommen und wohl heute noch nicht beendet. Du hast also mehrere unterstützte Dateisysteme mglw. auch noch parallel im Betrieb, willst aber trotzdem das Volume Management nicht auf eines dieser Dateisysteme beschränken. Letzteres ginge ja auch bei Solaris bzw. war bei Linux lange notwendig, da ZFS nicht bootbar war.

Wie schon geschrieben, bestand das Problem für Sun nicht, da sie ZFS als Alternative bzw. next-generation-FS ihres Biotops sahen. Letztendlich baut ja auch ZFS mit seinen zpools auf eine ähnliche Architektur auf, wobei ich einfach nicht sagen kann, ob und wie gut sich diese vom eigentlichen FS trennen lassen würden.


Durch fehlenden ECC Ram wird nix "deaktiviert". Sorry aber das ist Schwachsinn.
Lies einfach noch mal langsam, denn ich schrieb über das "Deaktivieren von Features des FS". Dann musst Du nicht so einen "Schwachsinn" schreiben.

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
Ein HW-RAID dagegen muss die ganze Platte scannen, weil es nichts über die Strukturen darunter weiß, hat aber dafür an anderer Stelle Vorteile. Aber HW Controller braucht man auch sonst nicht, und auch jedes andere SW-RAID stellt nur Daten wieder her und keine unbelegten Bereiche. Und indem man LVM und auch RAID vom eigentlich FS trennt greift sogar das Journaling voll. Bei ZFS hat man das halt alles in einem Topf verrührt und hat so gesehen eine nahezu unglaubliche und auch hervorragende Arbeit geleistet.
 
Zuletzt bearbeitet:
Ein Nachteil von ZFS wurde allerdings ausgeklammert:
Es ist empfohlen bei Nutzung von ZFS ECC-Ram zu verwenden, da viele Operationen bevor sie auf der Festplatte durchgeführt werden zunächst im Ram realisiert werden. - Hatte mich im Zuge von FreeNAS etwas damit beschäftigt und war schlussendlich der Grund, weshalb ich auf FreeNAS mit ZFS verzichtet habe...
 
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.

Dieses Problem hat jedes Filesystem.
 
Moinsen!

Ein Vorteil wurde überraschenderweise noch gar nicht genannt für den Heimbereich:

Der "Raid" ist auf den Platten gespeichert. Wenn man die Platten einfach ausbaut und beliebig wieder in das System steckt, braucht man nur einen Import zu machen und der Pool ist wieder da. Hab das schon zweimal gebraucht und es sehr geil gefunden.

Was die ECC-Sache angeht: Im privaten Umfeld benötigt ZFS genauso ECC-Ram wie NTFS oder irgendwas anderes. Jedes Dateisystem muss mal mehr mal weniger warten bis die Daten aus dem RAM auf der Platte sind.

Fakt ist aber, dass durch die Möglichkeiten von ZFS und dem eigentlichen Einsatzfeld in Unternehmen die Ansprüche bei den privaten Usern gestiegen sind und jetzt auch professioneller werden wollen. Kann man verstehen muss man nicht. Ich für meinen Teil habe einen ZFS-Pool seit Freenas 0,7 im Einsatz und habe in den letzten Jahren bei den ganzen Scrubs (Prüfung des Dateisystems inkl. Reparatur) erst einmal überhaupt einen Fehler in EINER Datei gehabt, der auch prompt repariert wurde. Dies mal als Anhaltspunkt wie wichtig ECC im Heimbereich wirklich ist. Würde es eher als eine Art Sahnehäubchen in Sachen Sicherheit sehen.

Bis denne!

PS: Wäre es nicht der Hammer, wenn Microsoft das Dateisystem lizenzieren würde und neben NTFS als Option für die Datenplatten anbietet? DAS wäre mal richtig geil, jedenfalls besser als deren eigene Lösung...
 
Ich habe das jetzt so verstanden, dass bei den aktuellen Filesystemen der RAM deutlich weniger belastet wird und die ECC Funktionalität somit zu vernachlässigen sei. Bei ZFS hingegen werden alle Daten erstmal in den RAM geschrieben, deren Prüfziffern dort vorgehalten und dann erst auf die jeweilige Platte geschrieben.

Ich bin ebenfalls wegen dem selben Grund von _ALU_ von Nas4free auf ein Softwareraid 5 umgestiegen.
Wenn selbst die Moderatoren davor warnen und der Meinung sind, dass in der Hinsicht ein Softwareraid besser wäre, warum sollte man denen nicht glauben. Ich glaube schon, dass die das besser beurteilen können als ich. ;)
Gut und der zweite Grund war das OMV einen Debianunterbau hat und man somit den Rechner auch für Plex und Co. einsetzen kann ohne, dass man am System stark rumfummeln muss.
 
CvH schrieb:
Hat das ganze für den Heimanwender im z.B. NAS irgendeinen Vorteil gegenüber einen aktuellen btrfs ?

Warum sollte man Btrfs benutzen wenn man mit FreeNAS native ZFS bekommt.

Ein FreeNAS mini von iXSystems ist optimiert in hardware & software, die CPU kann die Verschlüsselung des Dateisystems AES-NI & LZ4 Kompremierung.

ECC Ram ist auch drin ...

Alle Aktualisierungen kommen zuerst bei FreeNAS dann bei den anderen BSD's zu Tage.

FreeNAS Mini - Network Attached Storage (Diskless)
http://www.amazon.com/FreeNAS-Mini-Network-Attached-Diskless/dp/B00EQJ1BTU/

FreeNAS Mini Read Cache (L2ARC) Upgrade
http://www.amazon.com/FreeNAS-Mini-Cache-L2ARC-Upgrade/dp/B00LVA9E5A/
Ergänzung ()

freak01 schrieb:
zu NTFS, Windows und Prüfsummen:
ReFS sollte zumindest einen Teil der Funktionen von Btrfs und ZFS beherrschen:

Hier ist noch der Bericht von Phoronix zu ReFS
Microsoft's ReFS File-System: Competitor To Btrfs?
http://www.phoronix.com/scan.php?page=news_item&px=MTA0NDA
 
Der Artikel ließt sich so als ob ZFS on Linux ein Project sei das einen technologie Transfer rund um ZFS von Linux zu anderen Betriebssystemen ermöglichen würde. Die Wahrheit ist wohl genau der umgekehrte Fall. Nachdem Oracle Sun geschluckt hatte lebte die Entwicklung von ZFS vor allem in BSD und Solaris artigen Betriebssystemen weiter. Linux lief lange einfach nur hinterher, erst in letzter Zeit beginnt man aufzuschließen.
 
_Alu_ schrieb:
Ein Nachteil von ZFS wurde allerdings ausgeklammert:
Es ist empfohlen bei Nutzung von ZFS ECC-Ram zu verwenden, da viele Operationen bevor sie auf der Festplatte durchgeführt werden zunächst im Ram realisiert werden. - Hatte mich im Zuge von FreeNAS etwas damit beschäftigt und war schlussendlich der Grund, weshalb ich auf FreeNAS mit ZFS verzichtet habe...
Und bei anderen Systemen wird der Ram nicht genutzt? ECC wird benutzt weil bei Servern Daten oft über längere Zeit im Ram liegen (Tage/Wochen/Monate) und es da dann zu Fehlern kommen "kann".
Die Daten die aber erst in den Ram geschrieben werden werden nach 5 Sekunden auf die Platte geschrieben. Sprich sie sind gar nicht lange dort.

Ich bin ebenfalls wegen dem selben Grund von _ALU_ von Nas4free auf ein Softwareraid 5 umgestiegen.
Wenn selbst die Moderatoren davor warnen und der Meinung sind, dass in der Hinsicht ein Softwareraid besser wäre, warum sollte man denen nicht glauben. Ich glaube schon, dass die das besser beurteilen können als ich.
Gut und der zweite Grund war das OMV einen Debianunterbau hat und man somit den Rechner auch für Plex und Co. einsetzen kann ohne, dass man am System stark rumfummeln muss.

Was Qualifiziert einen Moderator jetzt besonders? Ich persönlich glaub da den Entwicklern und was sie in ihrem Blog geschrieben haben. Die werden wohl mehr Ahnung von Filesystemen haben als irgendein Moderator irgendeine Forum.
Außerdem ging es bei ZFS um Datensicherheit, hatte oberste Priorität, du meinst also man hätte bei der Entwicklung solche ekletanten Fehler gemacht die damals von keinem erkannt wurden aber jetzt von irgendwelchen "Mods" ?

Du verlierst mehr als du dazu gewinnst in Hinblick auf Sicherheit der Daten wenn von ZFS auf Softwareraid umsteigst. Dass ein Softwareraid sicherer ist sowas halte ich für absoluten Schwachsinn. Gäb es die Lizenzschwierigkeiten nicht hätte man sicherlich schon seit langem natives ZFS in Linux.

PS: Wäre es nicht der Hammer, wenn Microsoft das Dateisystem lizenzieren würde und neben NTFS als Option für die Datenplatten anbietet? DAS wäre mal richtig geil, jedenfalls besser als deren eigene Lösung...

Man muss aber auch bedenken dass ZFS und der CIFS/SMB Server in Solaris und Co. die einzig wirklichen Vorteile gegenüber Linux noch sind. Wenn sie das abgeben bleibt nicht mehr viel was für Solaris sprechen würde.


Wie schon geschrieben, bestand das Problem für Sun nicht, da sie ZFS als Alternative bzw. next-generation-FS ihres Biotops sahen. Letztendlich baut ja auch ZFS mit seinen zpools auf eine ähnliche Architektur auf, wobei ich einfach nicht sagen kann, ob und wie gut sich diese vom eigentlichen FS trennen lassen würden.
Jetzt aber nochmal die Frage welchen Sinn das denn haben sollte? Du kannst bei Linux doch problemlos ZFS neben ext4 weiter benutzen. Man kann auch mit virtuellen Festplatten und Containern arbeiten falls man unbedingt mal einen Bereich mit nem anderen Dateisystem brauchst.
Wenn du das ganze trennst stehst du quasi wieder da wo du am Anfang auch standest.

Wie ich in meinem Post und Du dann auch in Deinem zweiten richtig schriebst, gibt es eben noch mehr Stellen, die der Gegenprüfung dienen, wenn man die aber einfach unter den Tisch fallen lässt, wie in Deinem ersten Post getan, dann wird das ganze ziemlich sinnfrei. (Nicht für mich und wohl auch nicht für Dich, aber für die, die das Hintergrundwissen nicht haben).

Die Informationen kann sich aber jeder selbst zusammen suchen. Ich mein wenn man jetzt erklären würde wie es genau technisch umgesetzt wurde alles wäre das wohl zu viel. Es ist auch kein Geheimnis es gibt zu dem Thema verdammt viel im Internet. Wen es interesiert soll sich halt schlaumachen.
 
Danke, gute Infos hier. eine Frage: Wie sieht es mit Erweiterbarkeit aus? Also am liebsten Platten tauschen/dazustecken ohne viel zu konfigurieren?
 
Marco^^ schrieb:
Warum sollte man Btrfs benutzen wenn man mit FreeNAS native ZFS bekommt.

Warum sollte man ZFS benutzen wenn man Btrfs-Unterstützung in _jedem_ Linux-Kernel bekommen kann statt nur in ausgewählten (und vielleicht nächstes Jahr nicht mehr verfügbaren) Distributionen?

Die Frage ist ernst gemeint, ich habe sie heute morgen schon einmal gestellt: Wie steht Btrfs im verhältnis zu Zfs heute da? Wo hakt es, wo sind die Vorteile?
 
Kenneth Coldy schrieb:
Warum sollte man ZFS benutzen wenn man Btrfs-Unterstützung in _jedem_ Linux-Kernel bekommen kann statt nur in ausgewählten (und vielleicht nächstes Jahr nicht mehr verfügbaren) Distributionen?

Die Frage ist ernst gemeint, ich habe sie heute morgen schon einmal gestellt: Wie steht Btrfs im verhältnis zu Zfs heute da? Wo hakt es, wo sind die Vorteile?

Ich wuerde btrfs zur Zeit noch keine wichtigen Daten anvertrauen.

"Is btrfs stable?

Short answer: No, it's still considered experimental."
Quelle: https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable.3F

Bei ZFS fuer Linux habe ich jedoch auch Bedenken und verwende deshalb weiterhin auf meinen Servern FreeBSD.
 
phi schrieb:
Danke, gute Infos hier. eine Frage: Wie sieht es mit Erweiterbarkeit aus? Also am liebsten Platten tauschen/dazustecken ohne viel zu konfigurieren?

Platten kannst du nur gegen größere tauschen, keine kleineren. Und die Erweiterung mit mehr Platten läuft anders ab: Du kannst einen bestehenden Pool nur durch ein weiteres vdev erweitern.
Ein Pool kann aber aus mehreren vdev bestehen. Du kannst aber kein vdev entfernen oder nachträglich die Plattenanzahl ändern.

Sprich wenn du ein vdev mit 3 Platten mit RaidZ1/Raid5 hast und du brauchst mehr Platz musst du die Platten entweder durch größere tauschen oder du hängst ein zweites vdev dran. Das vdev sollte dann aber redundant sein, denn wenn es ausfällt sind die Daten weg.

Also vdev1: 3 Platten mit RaidZ1, und dann nen weiteres vdev2 adden bestehend aus nur einer Platte geht schon. Du hast dann den Platz von 3 vollen Platten. Aber da dein vdev2 keine Redundanz hat darf es nicht ausfallen.
 
Zuletzt bearbeitet:
Bogeyman schrieb:
Oder halt fertig Systeme wie den T20 von Dell oder HP Microserver

Mit den bekannten Nachteilen, aber ja, richtig.

Wanderer101 schrieb:
Ich für meinen Teil habe einen ZFS-Pool seit Freenas 0,7 im Einsatz und habe in den letzten Jahren bei den ganzen Scrubs (Prüfung des Dateisystems inkl. Reparatur) erst einmal überhaupt einen Fehler in EINER Datei gehabt, der auch prompt repariert wurde. Dies mal als Anhaltspunkt wie wichtig ECC im Heimbereich wirklich ist. Würde es eher als eine Art Sahnehäubchen in Sachen Sicherheit sehen.

Das ist aber nicht zwingend ein Fehler im RAM gewesen, sondern wahrscheinlich Bit Rot, also ne Festplatte, die lokal Daten verliert. Machen sie alle, prophezeit (bei mäßigem Auftreten) noch keinen Plattenausfall. Fällt aber nur beim Scrub auf, denn Windows-chkdsk und Linux-fsck prüfen nur die generelle Struktur, ob innerhalb der Datei Bits flippen, fällt denen nicht auf. ZFS schon, denn genau dafür werden Hashes angelegt.

Bogeyman schrieb:
Platten kannst du nur gegen größere tauschen, keine kleineren. Und die Erweiterung mit mehr Platten läuft anders ab: Du kannst einen bestehenden Pool nur durch ein weiteres vdev erweitern.[...]

Oder in Nicht-ZFS-Sprech: Du tauscht entweder reihum deine 2TB-Platten gegen z.B. 4TB-Platten und erlaubst danach den autoexpand, dann rödelts kurz, und dein Array hat plötzlich deutlich mehr Kapazität. Eben so viel, wie die kleinste Platte erlaubt. Falls du also ne 3TB mit eintauschst, wird auf allen übrigen Platten auch nur je 3TB genutzt.
Alternativ baust du ein ähnliches Array dazu, also wenn du schon 5 Platten im RAIDZ hast, dann hängst du 5 weitere dazu und baust daraus ein weiteres RAIDZ. Dieses wird dann als Stripe angehängt, sodass du in klassischen RAID-Begriffen sowas wie ein RAID50 hast.
Du kannst natürlich auch nen Mirror, ein Z3, oder irgendwas anderes anhängen, aber das bringt weder in Sachen Geschwindigkeit noch Datensicherheit einen Vorteil, da hier immer der schwächste Stripe limitiert.
 
Marco^^ schrieb:
Warum sollte man Btrfs benutzen wenn man mit FreeNAS native ZFS bekommt.

Ein FreeNAS mini von iXSystems ist optimiert in hardware & software, die CPU kann die

Danke für deine Werbung mit 0 Inhalt. Warum muss ich ein Sparten Unix nehmen ? Mir wäre ein FS weit lieber was in jedem Linux Kernel geht.
Bzw es gibt auch sowas wie OpenMediaVault, mir ist Debian weit lieber wie BSD.



Wander schrieb:
Ich wuerde btrfs zur Zeit noch keine wichtigen Daten anvertrauen.

"Is btrfs stable?

Das ist ein Statement von 2012 - Kernel 3.6 , mittlerweile sind wir fast bei 3.17. Ich bezweifle das sich da nichts getan hat.


Zu der Frage warum kein btrfs weiß wohl keiner etwas genaueres :(
 
CvH schrieb:
Das ist ein Statement von 2012 - Kernel 3.6 , mittlerweile sind wir fast bei 3.17. Ich bezweifle das sich da nichts getan hat.

Zu der Frage warum kein btrfs weiß wohl keiner etwas genaueres :(

Wenn die Entwickler ihre Meinung diesbezueglich geaendert haben sollten sie das auch so kommunizieren.
 
Das ist aber nicht zwingend ein Fehler im RAM gewesen, sondern wahrscheinlich Bit Rot, also ne Festplatte, die lokal Daten verliert. Machen sie alle, prophezeit (bei mäßigem Auftreten) noch keinen Plattenausfall. Fällt aber nur beim Scrub auf, denn Windows-chkdsk und Linux-fsck prüfen nur die generelle Struktur, ob innerhalb der Datei Bits flippen, fällt denen nicht auf. ZFS schon, denn genau dafür werden Hashes angelegt.
Ich wüsste auch nicht wie man jetzt Fehler im Ram erkennen sollte. Selbst bei ECC gibts da ja keine Meldung dass ein Fehler korrigiert wurde. Außerdem ist der Ram DEUTLICH kleiner als ein Pool, daher ist auch die Warscheinlichkeit dass ein Bit kippt deutlich geringer.

Aber das Problem wo manche hier die Pferde scheu machen ist keines.
 
Bogeyman schrieb:
Ich wüsste auch nicht wie man jetzt Fehler im Ram erkennen sollte. Selbst bei ECC gibts da ja keine Meldung dass ein Fehler korrigiert wurde. Außerdem ist der Ram DEUTLICH kleiner als ein Pool, daher ist auch die Warscheinlichkeit dass ein Bit kippt deutlich geringer.

a) Selbst Windows meldet korrigierte ECC-Fehler im Syslog. Wie man Fehler dort erkennt? ECC hat zusätzlichen Speicher für ne Checksumme. Ich hoffe, es klingelt.

b) Äpfel mit Birnen. DRAM ist kein "dauerhafter" magnetischer Speicher, sondern in kürzester Zeit flüchtig. Der benötigte Refreshzyklus liegt in der Größenordnung 10-100ms. Fällt der aus, kommt zur falschen Zeit und wird nicht korrekt durchgeführt, ist die Temperatur zu hoch oder die Spannung zu niedrig, flippt irgendwo mal eben ein Bit. Klar, die Menge an RAM ist massiv kleiner als die Menge an Plattenspeicher, aber es ist eben der Arbeitsspeicher, durch den fast jede verarbeitete Information durchgeschoben wird. Laufende Rechner mit teildefekten Platten gibts viele, aber mit defektem RAM? Fällt auf, innerhalb kürzester Zeit.
 
CvH schrieb:
Klingt erstmal nicht übel http://www.phoronix.com/scan.php?page=news_item&px=MTc2Njk,
"In a nutshell, while Btrfs is still experimental, it is usable in production environment for its core features."

Als zuhause NAS FS sollte das ja mehr als genug sein.

Warum sollte ich das Risiko eingehen? Es ist ja nicht so, dass ich btrfs nicht regelmaeßig teste, es laeuft sogar auf allen meinen Entwicklungsmaschinen, auch dieser hier, aber bisher hatte ich frueher oder spaeter immer Probleme damit. Im Gegensatz dazu laeuft ZFS seit Jahren ohne Probleme bei noch viel hoeheren Anforderungen.
 

Ähnliche Themen

Zurück
Oben