News Dateisystem: ZFS für Linux gilt als produktionsreif

[mensch183]

ZFS ist mehr als Raid. Raid ist out und Raid wurde auch nur erfunden um alte Dateisystem weiterhin verwenden zu können.
...
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.

Zu dem angeblichen "nur Vorteile": ZFS teilt sich mit sämtlichen anderen raidartigen Lösungen, die die Haupt-CPU des Rechners die Verwaltungsarbeit machen lassen, durchaus einen dicken Nachteil ggü. klassischen extra Raidcontrollern:
* Das Bussystem des Rechners wird _viel_ mehr belastet bzw. wirkt eher begrenzend, da sämtliche reads/writes aufs Plattensystem mehrfach darüber übertragen werden müssen.

Deshalb findet man ZFS niemals (modulo Sandkasten) direkt dort, wo der eigentliche Job des Rechners schon I/O-lastig ist. Dort, wo RAM für den eigentlichen Job wichtig ist, auch nicht. Es werden dedizierte Fileserver (oder "Storage Server" oder wie man die Sau gerade nennt, wo sich die Bytes stapeln) hingestellt, womit funktional eine ähnliche "Auslagerung" geschieht wie bei Raidcontrollern. Bei Raidcontrollern wird innerhalb eines Rechners Arbeit an ein Stück Zusatzhardware delegiert, beim ZFS-Einsatz (außerhalb des Sandkastens) wird Arbeit gleich an weitere Rechner delegiert.

Ja, ZFS tut nebenbei viel mehr als ein klassisches Raid. Vollkommen richtig. Nur ändert sich durch ein noch so cleveres Filessystem an der Grundaufgabe, Bytes aus dem RAM über I/O-Busse auf Platten zu schieben und zurückzuholen nichts. Auch ZFS kann die Daten nicht von A nach B beamen sondern muß sie durch die doofe, immer zu lahme Hardware lotsen.

Dein o.g. Caching-Argument halte ich übrigens für ziemlich Banane. Der (kleine) Cache auf klassischen Raidcontrollern hindert das OS nicht daran, trotzdem den Hauptspeicher als Cache für Files zu nutzen. Von mehr RAM profitierten beide Lösungen.

 

[fuyuhasugu]

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,

Das 5s-Argument ist aber nun mal wirklich so was von an den Haarne herbeigezogen. Die Fehlerhäufigkeit steigt einfach mit der genutzten RAM-Menge, vollkommen unabhängig davon wie lange die Daten da stehen. Wenn man sich z.B. anschaut, was z.B. bei Simulationsrechnungen für Unterschiede in den Ergebnissen auftreten, abhängig davon ob man HW ohne ECC oder eben HW mit benutzt... Und auch wenn so eine Simulation schon mal ein paar Wochen läuft, lange im RAM stehen die Daten keineswegs.

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 hättest ja mal versuchen können, von Sun, wo die Entwickler gearbeitet haben, ein System ohne ECC zu ordern oder versuchen gleiches jetzt bei Orakel zu tun.

Erst mit der Öffnung von ZFS für andere Plattformen ergab sich dieses Problem, wobei das auch keines der ursprünglichen Entwickler ist, da die i.a. nichts mit Consumer-HW am Hut haben.

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.

Seit wann gibt es keine ECC-Fehlermeldungen mehr? Maximal auf Low-End-HW, die man vielleicht als bastelserver für Zuhause einsetzt gibt es das nicht. Schau einfach mal auf den Supportseiten von IBM etc. nach.

Außerdem ist der Ram DEUTLICH kleiner als ein Pool, daher ist auch die Warscheinlichkeit dass ein Bit kippt deutlich geringer.

Und welche der Speichervarianten ist auf vielerlei Weise anfälliger für Fehler? Dagegen hilft der Größenvergleich auch nicht.

 

[Bogeyman]

Dein o.g. Caching-Argument halte ich übrigens für ziemlich Banane. Der (kleine) Cache auf klassischen Raidcontrollern hindert das OS nicht daran, trotzdem den Hauptspeicher als Cache für Files zu nutzen

Macht nur zB windows nicht und man braucht extra Software. Bei ZFS ist es schon alles mit dabei weil integriert.

Du hättest ja mal versuchen können, von Sun ein System ohne ECC zu ordern oder versuchen gleiches jetzt bei Orakel zu tun.

Erst mit der Öffnung von ZFS für andere Plattformen ergab sich dieses Problem, wobei das auch keines der ursprünglichen Entwickler ist, da die i.a. nichts mit Consumer-HW am Hut haben.

Du brauchst kein ECC Ram wo liegt das Problem? Selbst ohne ECC hat man immer noch viel mehr Vorteile als Nachteile. Du kannst Fehler abdecken die du mit NTFS nicht abdecken kannst.

Man brauch kein ECC. Gilt aber für Windows, Linux, SOlaris gleichermaßen. Ich verwende es dennoch, weil ichs hab.

Das 5s-Argument ist aber nun mal wirklich so was von an den Haarne herbeigezogen. Die Fehlerhäufigkeit steigt einfach mit der genutzten RAM-Menge, vollkommen unabhängig davon wie lange die Daten da stehen.

Die Zeit ist irrelevant? Sorry kauf ich dir nicht ab. Die Menge und die Zeit erhöht die Fehlerwarscheinlichkeit

 

[fuyuhasugu]

Die Zeit ist irrelevant? Sorry kauf ich dir nicht ab. Die Menge und die Zeit erhöht die Fehlerwarscheinlichkeit

Klar ist die Zeit relevant. In der Zeit, in der keine Infos in Teilen des RAM stehen, führen natürlich dort auftretende Fehler auch nicht zu Problemen.

 

[Marco^^]

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?

ZFS hat send & receive, damit kann man ganze partitionen senden als backup.

manpage ZFS(8) FreeBSD 10-RELEASE

manpage ZFS(8) FreeBSD 11-CURRENT hat die aktuellen Funktionsumfpang

hinzu kommt noch die diagnostischen Funktionsumpfang über die HDD's und Dateisystem

manpage ZPOOL(8) FreeBSD10-RELEASE

manpage ZPOOL(8) FreeBSD11-CURRENT

 

[Sensei21]

Mal eine Frage: Wo steht BTRFS im Vergleich zu ZFS?

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.

hab euch beiden Mal eine ganze Liste an Threads von der Mailing Liste rausgepickt, lest sie durch und entscheidet selbst, ob das Dateisystem "stabil wirkt":

# http://marc.info/?l=linux-btrfs&m=140444839700882&w=2 OOM bei scrub, normaler Btrfs-Nutzung [wohl noch nicht gelöst] - aha wird das nicht auch als K.O. genannt bei ZFS ?

# http://marc.info/?l=linux-btrfs&m=138404092003407&w=2 scrub OOM

# http://marc.info/?l=linux-btrfs&m=141052533001603&w=2 fs corruption (hatte das in der Vergangenheit auch, das Dateisystem hat sich spontan zerlegt)

# http://marc.info/?l=linux-btrfs&m=141045062408666&w=2 deadlock (system hängt total), mittlerweile gefixt 3.15.10

# http://marc.info/?l=linux-btrfs&m=141052139632322&w=2 degraded raid10, kein Platz mehr frei [wohl ENOSPC oder Ähnliches]

# http://marc.info/?l=linux-btrfs&m=141021294920920&w=2 send, receive dauert ewig

# http://marc.info/?l=linux-btrfs&m=140978568725103&w=2 Hänger, Verlangsamung während starkem i/o z.B. mit rsync [hab das auch, tritt immer noch auf, trotz diverser Fixes]

# http://marc.info/?l=linux-btrfs&m=140975654211700&w=2 detto

# http://marc.info/?l=linux-btrfs&m=140949968406711&w=2 detto, Fix, hilft bei mir auch (leider) nicht

# http://marc.info/?l=linux-btrfs&m=140893259624159&w=2 konstantes Schreiben auf die Platte (wohl gefixt mit http://marc.info/?l=linux-btrfs&m=141032514627232&w=2 )

# http://marc.info/?l=linux-btrfs&m=140879940727916&w=2 Datenkorruption, Datenverlust nach Resets, hardlocks, etc., wenn nicht ordnungsgemäß heruntergefahren wurde (hatte das auch - ist bis jetzt nach dutzenden solcher Fälle mit ZFS noch nicht aufgetaucht)

# http://marc.info/?l=linux-btrfs&m=140894330626031&w=2 Datenkorruption

# http://marc.info/?l=linux-btrfs&m=141021808322499&w=2 system hängt sich auf, nachdem eine leere Datei auf das Dateisystem geschrieben wurde und nicht mehr ansprechbar

# http://marc.info/?l=linux-btrfs&m=141030143520993&w=2 ENOSPC auf fast leerem Dateisystem [sollte durch http://marc.info/?l=linux-btrfs&m=141054952212096&w=2, theoretisch behoben sein]

# fand den Thread jetzt nicht, mit aktuellen Kerneln (3.16.1 oder 3.16.2) kein Zugriff & mounten von Subvolumes möglich




Anmerkung: erst vor ein paar Tagen wurden zwei hauptsächliche Probleme (zumindest theoretisch) behoben, die es schon seit Geburt von Btrfs gibt

http://marc.info/?l=linux-btrfs&m=141054952212096&w=2 [ENOSPC]
http://marc.info/?l=linux-btrfs&m=141032514627232&w=2 [das teils auftretende permanente Schreiben auf die Platte "ohne Grund"]


Ich nutze Btrfs selbst als Systemplatte und für die Portage-Partition, mehr aber auch nicht

keine Subvolumes, kein Raid - keine "fancy features"


Bei Versuchen es anderweitig zu nutzen (als zusätzliche Backup-Platte) treten immer wieder die Hänger/Verlangsamung mit rsync auf, ENOSPC gab es auch schonmal - auch dass das System nach längeren Stunden (rsync) nicht mehr richtig aufwachen ließ (nur Magic SYSRQ Key ging und dann gab es keine Auskunft in dmesg)


Btrfs frisst übrigens mehr RAM als ZFS, wenn ich nach den Daten von slabtop gehe ...


Fazit:

warum sollte ich also dieses ZFS vorziehen, wenn die ganzen tollen Funktionen nicht gehen ?

momentan setze ich es nur ein, weil die Prüfsummen wirklich essentiell sind und ich darauf wert lege, dass alles seine Integrität hat - ext4, xfs bieten das ja nicht für alle Strukturen (bin vor kurzem auf einen Rechner mit ECC-Speicher + Xeon umgestiegen)

 

[Miuwa]

Macht nur zB windows nicht und man braucht extra Software.

Hast du das mal getestet bzw. hast du ne Quelle? Würde mich doch sehr wundern.

 

[Bogeyman]

Wenn Microsoft selbst schon sagt man soll dafür Drittsoftware benutzen, was soll ich da "testen" ?

Es gibt keinen ARC in Windows.

 

[Miuwa]

Für was genau soll man 3rd Party Sw nutzen? Quelle?
Ich weiß zwar nicht, welche Caching Strategie Windows verwendet, aber laut taskmanager wird mein RAM sehr wohl als Filecache verwendet. Wieso sollte das bei Nutzung eines HW Raid Controllers nicht auch der Fall sein? Oder redest du von was anderem?

 

[Bogeyman]

Zum schreiben mit aktiviertem wbc vllt aber einen arc wie bei zfs, also einen lesecache gibt es da nicht. Naja ein hw Controller hat eh seinen eigenen RAM wenn gleich hier zfs den Vorteil hat dass es nicht auf dedizierten RAM angewiesen ist sondern alles benutzen kann was das System zur Verfügung stellt. Daher ist es ja auch so schnell bei Blöcken die oft angefordert werden weil Kopien davon im RAM liegen.

 

[MountWalker]

@ ECC-Notwendigkeit "weil Daten so lange im RAM sind"

Lasst euch da mal nicht in Panik versetzen. Die selbe Panik hatte es schon seit Portierung von XFS auf Linux gegeben, weil XFS ganz prinzipiell den kompletten freien RAM als Schreibcache benutzt und wenn andere Prozesse grad die Festplatte beschäftigen, kann es auch mal länger dauern, bis die Daten auf der Platte gespeichert werden. Diese Horrormeldung von 2000/2001 war so ein krasser Weltuntergang, dass zumindest Windows mit NTFS diese Praxis übernommen hat - wer weiß, vielleicht konfigurieren die meisten Distros auch Ext-Volumes automatisch so, dass sie RAM als Schreibcache nutzen.

 

[Marco^^]

Hier ist noch ein Hinweis zur Sendung LAS 330 vom 14.09.2014
http://www.jupiterbroadcasting.com/66657/switching-ubuntu-to-gnome-las-330/

Ich werde weder ZoL noch F2FS benutzen, weil es in den Installationsmedien nicht angeboten wird.
OpenSuSe sagt zwar hier man kann es für SSD's benutzen, doch der installer von OpenSuSe-NET bietet es nicht an.

http://www.youtube.com/watch?v=KiWg1-Ph1GY&hd=1&t=25m28s

 

[Tuxman]

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.

FreeBSD hat mehr Programme im Repository als zum Beispiel Debian Linux.

 

[Bogeyman]

Naja aber was für Programme. So serverzeugs wie apache bekommt man halt überall relativ einfach aber bei so Multimedia Sachen sind die Server os halt oft draußen

 

[Tuxman]

Welches Multimediaprogramm, das es in deinem Linuxrepository gibt, gibt es unter FreeBSD konkret nicht?

 

[MountWalker]

Ich find ja der einzige Nachtei von ZFS ist, dass es keine B+ Bäume benutzt, weshalb die anachronistisch anmutende Namensbezeichnung für Oracles Next Gen Linux Dateisystem so lustig ist. Seit den 90ern nutzen alle neuen Dateisysteme für HDD B+ Bäume, nur ZFS nicht.

 

[Ilsan]

Es werden dedizierte Fileserver (oder "Storage Server" oder wie man die Sau gerade nennt, wo sich die Bytes stapeln) hingestellt, womit funktional eine ähnliche "Auslagerung" geschieht wie bei Raidcontrollern. Bei Raidcontrollern wird innerhalb eines Rechners Arbeit an ein Stück Zusatzhardware delegiert, beim ZFS-Einsatz (außerhalb des Sandkastens) wird Arbeit gleich an weitere Rechner delegiert.

Ein Rechner hat allerdings deutlich mehr Ressourcen als nur ein Raidcontroller. Du kannst das nicht 1:1 vergleichen. Es steht dir ja auch frei auf einer Hardware das NAS zu virtualisieren und ZFS nur soviel Ressourcen zu geben wie man möchte.

Ich mein zeig mir einen Raidcontroller der 32GB und mehr an Ram hat, der einen adaptiven Lesecache hat. Noch dazu ist ZFS gratis.

Durch einen Raidcontroller bist du auch performancetechnisch eben an diesen gebunden. Ich würde da eher ne CPU ne Nummer oder 2 größer kaufen und/oder mehr Arbeitsspeicher anstatt eines Hardwareraidcontrollers.
Die CPU und Ram kann ich viel flexibler nutzen dank Virtualisierung.

Hab zum Beispiel den Microserver mit HP mit ZFS als NAS. Ich hätte hier doch absolut keinen Vorteil mit einem Hardwareraid. Auch brauchste bei nem Hardwarecontroller wieder ne BBU, bzw solltest eine haben. Kostet auch wieder Geld und muss auch kontrolliert und gewechselt werden irgendwann.
Bei ZFS kommt keine Hardware dazu, was nicht da ist kann auch nicht kaputt gehen und muss auch nicht gewartet und kontroliert werden.

Selbst Microsoft ist ja an was ähnlichem dran. Hardwareraid wird daher auf kurz oder lang wohl verschwinden

 

[phi]

Ich denke nicht das die Controller verschwinden werden, unternehmen dürften auf jeden Fall Interesse an frickelfreien ZFS-Hardwarelösungen haben.

 

[Marco^^]

FreeBSD hat mehr Programme im Repository als zum Beispiel Debian Linux.

~25.000 Programme

Das wurde mal in einem Video bei YT erklärt. (weis nicht mehr wo ...)

Open BSD versus Linux - Daniel Seuffert klärt auf (deutsch)
www.youtube.com/watch?v=Ln7jaBDqu_E&hd=1

Ergänzung (19. September 2014)

Ich find ja der einzige Nachtei von ZFS ist, dass es keine B+ Bäume benutzt, weshalb die anachronistisch anmutende Namensbezeichnung für Oracles Next Gen Linux Dateisystem so lustig ist. Seit den 90ern nutzen alle neuen Dateisysteme für HDD B+ Bäume, nur ZFS nicht.

Also ich wüsste jetzt nicht wo der Vor & Nachteil ist ...

http://de.wikipedia.org/wiki/Copy-On-Write
http://de.wikipedia.org/wiki/Btrfs#Eigenschaften
http://de.wikipedia.org/wiki/ZFS_(Dateisystem)#Kritik.2C_Nachteile

 

[MountWalker]

@ Marco^^

Was COW ist weiß ich, das hat aber auch mit B+ Bäumen versus Tabellen nichts zu tun. B+ Bäume (oder bei Reiser4 B* Bäume) verwendet man für Verzeichnisstrukturen in Dateisystemen - ZFS benutzt dafür eine Tabelle. Ob das in der Praxis bei der derzeitigen Langsamkeit eines COW-FS eine Rolle spielt, weiß ich nicht, hat aber auch noch niemand öffentlich untersucht. Ext2/3 hatte auch jahrelang behauptet, die Verzeichnistabelle wäre kaum ein Nachteil, bis dann plötzlich noch für Ext3 die HTree-Verzeichnisstruktur eingeführt wurde. Seit Ende der 80er waren Verzeichnisbaumstrukturen ein wichtiges Thema bei den Dateisystemen, deswegen finde ich es merkwürdig, dass bei ZFS niemand mal erklärt, warum ZFS darauf verzichten kann.