BTRFS vs ZFS?
BTRFS vs ZFS?
Hallo liebe Community!
Seit etwa 3 Jahren betreibe ich meinen Server nun zufriedenstellend mit ZFS, jedoch gibt es ja mit dem neuen 5.x Kernel nun massive Probleme was die ZoL angeht.
Ausserdem bereitet es mir oft massive Probleme, weil ich beim Kernel Update oft ohne Daten da stehe, da der neuste Kernel oft nicht direkt supportet wird.
Wie sollte ich am besten vorgehen?
Ich habe schon einiges zu BRTFS gelesen, aber kann man es als "ebenbuertig" zu ZFS einstufen?
Wenn ja wuerde ich tatsaechlich gerne umsteigen.
Aktuell betreibe ich mit 4x 2TB Platten einen RAID 10 bzw. einen Zraid und bei einer 1 TB SSD einen einfachen Zpool.
Deduplizierung und Komprimierung nutze ich nicht.
Seit etwa 3 Jahren betreibe ich meinen Server nun zufriedenstellend mit ZFS, jedoch gibt es ja mit dem neuen 5.x Kernel nun massive Probleme was die ZoL angeht.
Ausserdem bereitet es mir oft massive Probleme, weil ich beim Kernel Update oft ohne Daten da stehe, da der neuste Kernel oft nicht direkt supportet wird.
Wie sollte ich am besten vorgehen?
Ich habe schon einiges zu BRTFS gelesen, aber kann man es als "ebenbuertig" zu ZFS einstufen?
Wenn ja wuerde ich tatsaechlich gerne umsteigen.
Aktuell betreibe ich mit 4x 2TB Platten einen RAID 10 bzw. einen Zraid und bei einer 1 TB SSD einen einfachen Zpool.
Deduplizierung und Komprimierung nutze ich nicht.
- heisenberg
- Beiträge: 3567
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: BRTFS vs ZFS?
Es gibt einen guten Wiki-Artikel zu btrfs hier bei df.de: https://wiki.debianforum.de/Btrfs
Persönliche Meinung:
Es ist wohl sehr stabil(Siehe Artikel!). Ich nutze es selbst aktuell nicht. In der Berechnung des freien Speichers finde ich es verwirrend. Was mir ansonsten nicht gefällt ist die Tatsache, das Checksummen nicht immer beim lesen automatisch geprüft werden wie bei ZFS, sondern nur, wenn man manuell einen Check durchführt.
Kompression wäre für mich mal ein sehr wichtiges Feature(Erhöht die Kapazität und steigert die Performance).
Persönliche Meinung:
Es ist wohl sehr stabil(Siehe Artikel!). Ich nutze es selbst aktuell nicht. In der Berechnung des freien Speichers finde ich es verwirrend. Was mir ansonsten nicht gefällt ist die Tatsache, das Checksummen nicht immer beim lesen automatisch geprüft werden wie bei ZFS, sondern nur, wenn man manuell einen Check durchführt.
Kompression wäre für mich mal ein sehr wichtiges Feature(Erhöht die Kapazität und steigert die Performance).
Jede Rohheit hat ihren Ursprung in einer Schwäche.
Re: BRTFS vs ZFS?
Das sehe ich ein wenig anders.heisenberg hat geschrieben:14.05.2019 13:36:30Kompression wäre für mich mal ein sehr wichtiges Feature(Erhöht die Kapazität und steigert die Performance).
Die Kompression beim schreiben und die Dekompression beim Lesen kosten nicht unerheblichen Rechenaufwand. Bei einem NAS mag das egal sein, denn die CPU im NAS hat sonst nichts zu tun. Bei einem Arbeitsplatzrechner geht die Kompression direkt von der CPU ab, verlangsamt das System also.
Die Kapazitätssteigerung hängt auch sehr stark von den Daten ab, die man auf der Platte verwaltet. Mediendateien (JPG-Bilder, MPG1/2/3/4-Filme) sind bereits komprimiert und lassen sich nicht weiter eindampfen. Das gleiche gilt für Archivdateien wie .tgz, .zip, .bz2 etc. Natürlich kann man viel gewinnen, wenn man hauptsächlich ASCII-Dateien auf der Platte speichert, die machen aber nicht den Großteil der Daten aus.
Meiner Erfahrung nach ist Kompression im Dateisystem keine gute Idee, weil sie in meinen Einsatzfällen die Performance zerstört und in der Regel nur wenig mehr als 10% Platzersparnis bringt.
- heisenberg
- Beiträge: 3567
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: BRTFS vs ZFS?
@MSfree:
Stimmt alles, was Du sagst. Bis auf Deine Schlußfolgerung:
Natürlich muss man schauen, ob man die CPU-Resourcen dafür hat oder nicht. Gerade bei schwachbrüstigen NAS wäre ich da auch eher vorsichtig. Im Zweifelsfall kommt es auf die Einschätzung der Situation und einen Versuch an. Knogle hatte das ja wohl schon mal aktiv und hat es wieder ausgeschaltet.
Stimmt alles, was Du sagst. Bis auf Deine Schlußfolgerung:
Nach Deiner Aussage hängt das von der Art der Daten ab. Ich hatte auch schon Steigerung der Kapazität auf das Doppelte durch Kompression bei ZFS. Und das mit den Kompressionsresourcen kann man ja einstellen(lz4,gzip,...). Auf einem Server der ungenutzte CPU-Resourcen hat, ist Potential da. Auch dort wo der Schwerpunkt mehr auf lesen als auf schreiben ist, ist, da die Dekompression viel weniger CPU-Aufwand benötigt, ein möglicher Performancegewinn. Ein Desktopsystem ist natürlich etwas anders.Meiner Erfahrung nach ist Kompression im Dateisystem keine gute Idee, weil sie in meinen Einsatzfällen die Performance zerstört und in der Regel nur wenig mehr als 10% Platzersparnis bringt.
Natürlich muss man schauen, ob man die CPU-Resourcen dafür hat oder nicht. Gerade bei schwachbrüstigen NAS wäre ich da auch eher vorsichtig. Im Zweifelsfall kommt es auf die Einschätzung der Situation und einen Versuch an. Knogle hatte das ja wohl schon mal aktiv und hat es wieder ausgeschaltet.
Jede Rohheit hat ihren Ursprung in einer Schwäche.
Re: BRTFS vs ZFS?
Im Server habe ich einen Ryzen R7 1700 am laufen.
Jedoch habe ich nur 16GB RAM und das Teil kam bei der Übertragung vom 1000MB/s über die 10GBit Karte mit Dedup und Kompressiok extrem an die Grenzen.
Da ist die Rate teils auf 100MB/s eingebrochen.
Nutze für die 1TB SSD eine NVMe Variante, mein PC verbunden mit Punkt zu Punkt LC Verbindung ebenfalls mit NVMe SSDs ausgestattet.
Daher auch das RAID 10 für maximale Performance.
Jedoch habe ich nur 16GB RAM und das Teil kam bei der Übertragung vom 1000MB/s über die 10GBit Karte mit Dedup und Kompressiok extrem an die Grenzen.
Da ist die Rate teils auf 100MB/s eingebrochen.
Nutze für die 1TB SSD eine NVMe Variante, mein PC verbunden mit Punkt zu Punkt LC Verbindung ebenfalls mit NVMe SSDs ausgestattet.
Daher auch das RAID 10 für maximale Performance.
Re: BRTFS vs ZFS?
heisenberg hat geschrieben:14.05.2019 14:36:30Im Zweifelsfall kommt es auf die Einschätzung der Situation und einen Versuch an.
![Thumbs Up :THX:](./images/smilies/thumbup.gif)
Re: BRTFS vs ZFS?
ich hatte vor kurzem meinen kollegen mal meine Erfahrungen zu btrfs geschildert.. hier nochmal die Mail (ist von Ende Februar)
Da du anscheinend immer den aktuellsten Kernel verwenden willst und diesen evtl sogar selbst kompilierst (warum eigentlich immer den neusten?) dann würde ich dir vorschlagen mal einen Blick auf bcachefs zu werfen..Hallo IT'ler
wir möchten euch mit dieser Mail an unserer Erfahrung am btrfs-Dateisystem teilhaben lassen.
Was wir erreichen wollten, war ohne einen (Hardware)RAID-Controller mit Snapshots ein RAID-1 für unser /-root Filesystem. Ausgangspunkt ist ein Server mit 2 SSD (je 240GB) und der Absicherung, dass wenn eine der beiden Platten (egal welche) ausfällt, der Server weiterläuft und auch nach einem reboot wieder von der noch intakten Platte startet. Eine Benachrichtigung über den Fehlerfall soll natürlich gemeldet werden. (syslog,... o.ä.)
Zum einen meine Erwartungen an ein RAID1:
- wenn eine Platte ausfällt, der Betrieb ohne Probleme weiter geht und ich im Idealfall benachrichtigt werde, oder aber syslog oder ähnliches gemeldet wird dass da was nicht stimmt. In der Paxis sieht es aber eher so aus, dass wenn eine Platte entfernt wird und der Server während dessen anbleibt, es kein Problem gibt und auch keines gemeldet wird. Aber wenn man den Server neu bootet, ein 'missing device' bemängelt wird und ein Systemstart fehlschlägt.
==>um das zu beheben kann man in der /etc/fstab und in grub die option 'degraded ' setzen - was aber auch nicht unbedingt (als Standard) empfohlen wird.
- Wenn eine Platte länger braucht zum initialisieren und das nicht innerhalb von X Sekunden passiert, bootet er weiter (vorausgesetzt die Option 'degraded' wurde gewählt) und startet normal. Wenn später aber die defekte Platte dann wieder dazu kommt, wird es vom btrfs nicht automatisch eingehangen und gebalanced.
- Wenn man die Platte tauscht muss das rebalance erfolgreich durchlaufen bevor man den Server neu starten kann. Ansonsten kann dies zu unerwünschten Effekten führen, zum Beispiel dass das FS nur noch Read-Only gemountet werden kann.
merkwürdiges Verhalten in btrfs:
- Ein mconvert/dconvert sorgt noch längst nicht dafür das _alle_ Single-Daten in RAID1 überführt werden, einREst bleibt da noch, um wirklich alles in RAID1 zu überführen muss man 'btrfs balance start -dusage=0 -musage=0' ausführen
- Nach dem eine Platte entfernt wurde und der Server zum ersten Boot hochfuhr trat auch auf, dass das btrfs zum "Read-only Filesystem" wurde ohne das man etwas weiter konfigurieren konnte. Ein zweiter reboot führte dann meist zu einem 'initramfs...file not found Fehler ' und die Installation war kaputt.
Davon abgesehen haben wir noch festgestellt, dass ein RAID10 kein echtes RAID10 ist sondern eher ein RAID01. D.h. es darf also nur _eine_ Platte ausfallen, zudem kann man nicht bestimmen wie die Aufteilung sein soll (wie bei ZFS zum Beispiel) und das es sehr langsam agiert.
Unser Fazit:
Das btrfs Dateisystem sollte man nur nutzen wenn man unbedingt Snapshots und/oder Checksummen braucht, oder man es als single Disk-Dateisystem nutzen möchte (vor allem im Desktop-Segment), ansonsten nehmen wir erstmal Abstand davon.
PS: meine aktuelle Hoffnung liegt in bcachefs (https://bcachefs.org/), liest sich auf dem Papier erstmal sehr gut.
Debian-Nutzer ![Very Happy :D](./images/smilies/icon_biggrin.gif)
ZABBIX Certified Specialist
![Very Happy :D](./images/smilies/icon_biggrin.gif)
ZABBIX Certified Specialist
Re: BRTFS vs ZFS?
Kannst du diese Probleme benennen? ZFS-0.7.x und ZFS-0.8-rcX lassen sich ohne Probleme benutzen. Evtl. Design-Änderungen im Kernel, die zu Anpassungen in der Entwicklung von ZFS führen, wird es immer wieder mal geben, einen Grund zur Panik ist das nicht.Knogle hat geschrieben:14.05.2019 12:59:36Hallo liebe Community!
Seit etwa 3 Jahren betreibe ich meinen Server nun zufriedenstellend mit ZFS, jedoch gibt es ja mit dem neuen 5.x Kernel nun massive Probleme was die ZoL angeht.
Nun du verwendest Debian, ergo „gut gereifte Software“, dann bleibe doch mit Kernel und ZFS auch bei den Debian-Paketen oder gibt es einen Grund warum du Kernel 5.x benutzen musst?Ausserdem bereitet es mir oft massive Probleme, weil ich beim Kernel Update oft ohne Daten da stehe, da der neuste Kernel oft nicht direkt supportet wird.
BTRFS ist leider keinesfalls mit ZFS auf gleicher Höhe.Ich habe schon einiges zu BRTFS gelesen, aber kann man es als "ebenbuertig" zu ZFS einstufen?
- heisenberg
- Beiträge: 3567
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: BRTFS vs ZFS?
Kannst Du das genauer ausdrücken? In der Verallgemeinerung bringt es recht wenig Erkenntnis.bluestar hat geschrieben:14.05.2019 21:15:14BTRFS ist leider keinesfalls mit ZFS auf gleicher Höhe.
Jede Rohheit hat ihren Ursprung in einer Schwäche.
Re: BRTFS vs ZFS?
Wenn ich von Stretch ausgehe, dann sieht das wie folgt aus:heisenberg hat geschrieben:15.05.2019 06:58:20Kannst Du das genauer ausdrücken? In der Verallgemeinerung bringt es recht wenig Erkenntnis.
* Raid5 Code noch nicht stabil
* Raid1 Ausfall einer HDD kann zu dauerhaftem Read-Only führen
* BTRFS kennt keine Volumes(vgl. zvol), lediglich Dateisystem
* Die Tools zpool und zfs sind deutlich angenehmer vom Handling her, versuche mal den Status eines RAIDs und der zugehörigen Devices herauszufinden...
* BTRFS hat nur den Vorteil „Bestandteil“ des Kernels zu sein
Mein persönlicher Wunsch wäre eine ZFS-Reimplementation unter GPL als fester Kernelbestandteil, das würde BTRFS obsolet machen.
-
- Beiträge: 5529
- Registriert: 30.12.2004 15:31:07
- Wohnort: Wegberg
Re: BRTFS vs ZFS?
Hallo
Nachtrag zu @bluestar
Ich finde die snapshotfunktion incl. rekursiver snapshots wesentlcih besser, als snpshots unter btrfs.
Ich habe auf einem kleinen fileserver mit freebsd + zfs foilgendes schema bei einem zfs mirror:
--data (eingehängt in /data)
--------data-vol1 (heißt im original anders
--------data-vol2
--------data-vol3
--------data-vol4
afaik kann ich bei so einer Anordnung unter btrfs keinen snapshot von data erstellen.
unter zfs kann ich jetzt mit zfs -r snapshot @data% (weiß jetzt aus dem Kopf nicht ob das jetzt @data, oder @data% heißt) snapshots für @data und die 4 "subvolumes" erstellen, das geht unter btrfs nur mit einem Script.für mehr als 1 subvolume.
mfg
schwedenmann
Nachtrag zu @bluestar
Ich finde die snapshotfunktion incl. rekursiver snapshots wesentlcih besser, als snpshots unter btrfs.
Ich habe auf einem kleinen fileserver mit freebsd + zfs foilgendes schema bei einem zfs mirror:
--data (eingehängt in /data)
--------data-vol1 (heißt im original anders
--------data-vol2
--------data-vol3
--------data-vol4
afaik kann ich bei so einer Anordnung unter btrfs keinen snapshot von data erstellen.
unter zfs kann ich jetzt mit zfs -r snapshot @data% (weiß jetzt aus dem Kopf nicht ob das jetzt @data, oder @data% heißt) snapshots für @data und die 4 "subvolumes" erstellen, das geht unter btrfs nur mit einem Script.für mehr als 1 subvolume.
mfg
schwedenmann
Re: BRTFS vs ZFS?
MSfree hat geschrieben:14.05.2019 14:09:25Die Kompression beim schreiben und die Dekompression beim Lesen kosten nicht unerheblichen Rechenaufwand.
Quatsch
Wir hatten das ja zu genüge bei Crpyto: Die fälle dass deine CPU ausgelastet ist und gleichzeitig geschrieben wird, dürfte sich alles zusammen auf ein paar Millisekunden im Jahr addieren. Und das ist noch nicht die Zeit die du verloren hast, sondern die, bei der du Performanceeinbusen hast. Dem gegenüber stehen die deutlich kürzeren Schreib und Lesezeiten, weil du weniger Daten schreiben musst. Moderate Kompression bringt dir Performancezuwächse. Gerade bei den üblicherweise extrem überdimensionierten PC-CPUs.Bei einem Arbeitsplatzrechner geht die Kompression direkt von der CPU ab, verlangsamt das System also.
Mit was hast du das den gemessen? Das ist hanebüchener Quatsch. Bei jedem PC bringt Kompression deutlich mehr Gewinne an Performance, weil die SSD viel häufiger das Bottleneck ist als die CPU.MSfree hat geschrieben:14.05.2019 14:09:25Meiner Erfahrung nach ist Kompression im Dateisystem keine gute Idee, weil sie in meinen Einsatzfällen die Performance zerstört
Das sieht bei extrem schmal dimensionierten NAS oder Servern mit viel CPU-Last möglicherweise anders aus. Aber bei privat PCs hast du da keine Chance negativ raus zu kommen.
Und vor allem sieht es mit ZFS anders aus. Die deduplication zieht wirklich CPU-Performance und vor allem RAM. Aber das LZO im btrfs da kommst du selbst mit nem Ryzen 3 single core an die 20GByt/s. Deine SSD macht im normalfall <<6GBit/s lesend. Selbst wenn du auf die mit full speed liest, hast du gerade mal 7% CPU-Auslastung durch die Kompression. (Dein Overhead an Systcalls zum Schreiben macht vermutlich mehr aus.) Dafür gewinnst du 10% weil du weniger schreiben musst. Selbst so ist das ein Performance-Gewinn. Problem: Wenn du gerade liest wartest du in 99% der Zeit und die CPU idelt eh. Dass volle CPU-Auslastung auf IO trifft kommt bei Desktops so gut wie nicht vor. Das übliche Pattern ist, dass zuerst I/O gemacht wird und wenn überhaupt dann gerechnet. In 99% sieht so ein Desktop eigentlich nur im Benchmark Auslastung aller Cores und idelt sonst nur rum.
Damit hast du aber bei Privatpersonen recht:
Mittlerweile sind 90% der Daten, die auf so nem PC liegen schlicht komprimierte Bilder in irgend einer Form. Viel zu holen ist da nicht.Die Kapazitätssteigerung hängt auch sehr stark von den Daten ab, die man auf der Platte verwaltet. Mediendateien (JPG-Bilder, MPG1/2/3/4-Filme) sind bereits komprimiert und lassen sich nicht weiter eindampfen. Das gleiche gilt für Archivdateien wie .tgz, .zip, .bz2 etc.
[…]
n der Regel nur wenig mehr als 10% Platzersparnis bringt.
Wie oben schon angemerkt Deduplication bewegt sich in ganz anderen Größenordnungen wie Kompression. Und der LZ vom ZFS ist auch ne andere nummer als der LZO vom btrfs. (Sowohl was Kompressionsraten wie auch was CPU-Verbrauch angeht.)Karte mit Dedup und Kompressiok extrem an die Grenzen.
Alle von dir beschriebenen Mängel sind Einstellungssache. Vor allem was den Vergleich mit RAIDS angeht kannst du da sogar gar nicht wählen sondern meist nur die andere Variante fahren. Dass btrfs auf Fehler aufmerksam macht und ro mounted, die man in einem RAID gar nicht erst bemerkt hätte finde ich jetzt ganz und gar nicht als Nachteil. Wenn du auf deine Daten scheißt kannst du halt degraded dran hängen. Dann hast du das RAID-Verhalten in etwas besser. Du hast im Fehlerfall halt ein read-Only System statt einem Kaputten System, dass dann mit fehelrhaften Daten bootet.Das btrfs Dateisystem sollte man nur nutzen wenn man unbedingt Snapshots und/oder Checksummen braucht, oder man es als single Disk-Dateisystem nutzen möchte (vor allem im Desktop-Segment), ansonsten nehmen wir erstmal Abstand davon.
Letzteres ist doch nur für die HA-Statistik toll.
Wenn du dir keine zusätzlichen Platten leisten kannst auf die du kopieren kannst solltest du hoffentlich keine HA Versprechungen machen. Die Wahrheit ist eher dass am Ende deine Programme abschmieren, und du kaputte unwiederherstellbare Daten hast statt ein paar Minuten Downtime. Kann mir kein Szenario vorstellen, wo dass von Vorteil ist.
Ich sehe das anders: ZFS ist und bleibt immer ein absoluter Fremdkörper im System. Wenn man aus der Solaris-Welt kommt, mag das angenehm sein aber in den aller meisten Fällen ist es einfach nur anders wie alle anderen Dateisysteme. Nicht besser oder schlechter sondern schlicht anders. Das finde ich äußerst nervig.* Die Tools zpool und zfs sind deutlich angenehmer vom Handling her, versuche mal den Status eines RAIDs und der zugehörigen Devices herauszufinden...
Eklatantestes Beispiel finde ich das Speichern der Konfiguration inklusive mountpoints im Dateisystem. Das ist nur bescheuert. Wenn ich eine Platte in ein anderes System stecke (z.B. weil ein diskless rettungssystem bootet will ich natürlich völlig andere Eeigenschaften haben.) Auch voll Dateibasierten Attribute finde ich eigentlich intuitiver. Nachträgliche Kompression für einzelne Dateien oder snapshots auf Ordner sind intuitiver wie die Device-Eigenschaften, die halt am ende das gleiche können.
Daneben gilt, dass alle Tools halt die /etc/fstab parsen. Nur für ZFS funktioniert das nicht. Genau wie das anlegen eines Daeisystems überall weitestgehend gleich funktioniert. Nur ZFS will Extrawürste. Es ist bei weitem nicht nur die Lizenz, die bei ZFS nicht in die Rest-Infrastruktur passen.
Aber natürlich hast du damit recht:
Letzteres sehe ich nicht wirklich als Nachteil. Es passt so viel besser in die Infrastruktur. Dank LVM und losetup gibt es keinen Grund warum man sowas haben will.* Raid5 Code noch nicht stabil
* Raid1 Ausfall einer HDD kann zu dauerhaftem Read-Only führen
* BTRFS kennt keine Volumes(vgl. zvol), lediglich Dateisystem
Eine saubere RAID -Implementierung in btrfs würde ZFS überflüssig machen. Man kann sich jetzt aussuchen, was man für wahrscheinlicher hält. Wahrscheinlich gibt es in absehbarer Zeit was ganz anderes. Verteilte Systeme wie Ceph oder Gluster gehen völlig anderen Ansätzen nach und kommen am Ende auf ähnliche Features. Da hapert es noch etwas an der Performance aber prinzipiell ist da Luft nach Oben.Mein persönlicher Wunsch wäre eine ZFS-Reimplementation unter GPL als fester Kernelbestandteil, das würde BTRFS obsolet machen.
Als weitere Punkte für ZFS Kann man noch nennen:
- Keine vergleichbare Kompression
- Keine deduplication
- In einigen Spezialfällen deutlich schlechtere Performance
rot: Moderator wanne spricht, default: User wanne spricht.
Re: BRTFS vs ZFS?
Mässige deine Ausdrucksweise, erst Recht als Moderator.
Und sorry, wenn ich das so klar sagen muß, über die Performancebremse Kompression in meinem Anwendungsbereich hast du absolut keine Ahnung. Ich bleibe dabei, es ist, um dich zu zitieren, hanebüchener Quatsch, Kompression allgemein zu empfehlen. Es kommt hier tatsächlich auf Versuche an, ob sie was bringt.
Re: BTRFS vs ZFS?
Ich muss muss bei der Performance Diskussion mal kurz nachhaken:
Erster Ansatz: HDDs durch NVME-SSDs austauschen.
Dann über die Performance über 10GBit bei 100MB/sek
Da würde ich doch mal ernsthaft nachfragen: Klassische HDDs in einem RAID10 und 10GBit Ethernet und geringe Performance ???
Erster Ansatz: HDDs durch NVME-SSDs austauschen.
- heisenberg
- Beiträge: 3567
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: BTRFS vs ZFS?
Ich wäre jetzt mal vorsichtig, beim aktuellen Fall eine korrekt eingestellte ZFS-Konfiguration zu erwarten.
Jede Rohheit hat ihren Ursprung in einer Schwäche.
- heisenberg
- Beiträge: 3567
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: BTRFS vs ZFS?
btrfs führt für mich, so wie ich das hier in dem Thread sehe, erhöhte Komplexität ein(Anzeige freier Speicher, Rebalancing Notwendig, Festplattentausch fragiler, RAID-Level nicht so klar und einfach wie man das erwartet(habe ich bereits auch an anderer Stelle gelesen.)).
Meine Erwartungshaltung ist der von Colttt ziehmlich ähnlich.
Auch trotz der zu recht bemängelten Punkte von wanne ist für mich die ZFS-Administration sehr einfach. Ich hatte bisher bis auf den einen oder anderen Bug(der zum Zeitpunkt des Auftretens bereits in einer neueren Version behoben war) keinen Streß mit ZFS. Datenverlust noch nie.
Andere Sachen wie z. B. dass die Platte nach X Sekunden Nicht-Reaktion nicht eingehängt wird, sehe ich als "ist halt noch nicht fertig". Fände ich gut, wenn man dafür einen Bugreport aufmachen würde.
Das ZFS aufgrund der Lizenzproblematik nicht in den Kernel kommt und dass es auch keine einfache Integration in die Installation gibt ist natürlich sehr unangenehm.
Meine Erwartungshaltung ist der von Colttt ziehmlich ähnlich.
Auch trotz der zu recht bemängelten Punkte von wanne ist für mich die ZFS-Administration sehr einfach. Ich hatte bisher bis auf den einen oder anderen Bug(der zum Zeitpunkt des Auftretens bereits in einer neueren Version behoben war) keinen Streß mit ZFS. Datenverlust noch nie.
Andere Sachen wie z. B. dass die Platte nach X Sekunden Nicht-Reaktion nicht eingehängt wird, sehe ich als "ist halt noch nicht fertig". Fände ich gut, wenn man dafür einen Bugreport aufmachen würde.
Das ZFS aufgrund der Lizenzproblematik nicht in den Kernel kommt und dass es auch keine einfache Integration in die Installation gibt ist natürlich sehr unangenehm.
Jede Rohheit hat ihren Ursprung in einer Schwäche.
Re: BTRFS vs ZFS?
AAuch trotz der zu recht bemängelten Punkte von wanne ist für mich die ZFS-Administration sehr einfach.
Sorry aber nen btrfs zu warten ist schlicht um Größenordnungen einfacher als ein ZFS. Alle "Mängel", die hier angesprochen wurden gelten 1:1 auch für ZFS. Sie resultieren einfach aus den Eigenschaften eines COW-Dateisystems und verwirren User die das noch nie gesehen haben.
Wenn du ein ZFS Volume ohne passende Konfiguration in deine fstab schreibst passiert da schlicht gar nichts. Nicht irgend welche unerwarteten defaults, die objektiv betrachtet in den meisten Fällen sinnvoll sind, sondern schlicht nichts.heisenberg hat geschrieben:15.05.2019 17:56:37btrfs führt für mich, so wie ich das hier in dem Thread sehe, erhöhte Komplexität ein(Anzeige freier Speicher, Rebalancing Notwendig, Festplattentausch fragiler, RAID-Level nicht so klar und einfach wie man das erwartet(habe ich bereits auch an anderer Stelle gelesen.)).
Auch ein RAID Z1 verhält sich auch nicht wie ein RAID 1. Da sind beide Systene 100% äquivalent. Wer mit der Erwartung ran geht, dass es genau gleich wie ein RAID funktioniert fliegt halt auf die Fresse.
Auch deine Speicherangaben kannst du bei ZFS dank deduplication komplett vergessen. btrfs liefert wenigstens Werte, die man interpretieren kann. ZFS bietet das schlicht nichts.
Besonders lustig finde ich das muss für einen manuellen rebalace. Dir ist schon klar dass ZFS das schlicht gar nicht kann? Ohne löschen und neu schreiben, hast du keine Chance.
Lediglich das Festplattentausch ist unter ZFS tatsächlich etwas smoother.
Kannst du den Bug dann auch für ext4 aufmachen oder für XFS?Andere Sachen wie z. B. dass die Platte nach X Sekunden Nicht-Reaktion nicht eingehängt wird, sehe ich als "ist halt noch nicht fertig". Fände ich gut, wenn man dafür einen Bugreport aufmachen würde.
Das ist halt der default von Systemd. Für alle Daeisysteme – Außer für ZFS. Das ist das was ich meine mit Integration das verhält sich halt wie alle anderen Dateisysteme auch. Gleiches gilt für caching. Da hält sich btrfs auch an die global gesetzten Regeln. Kann man jetzt bemängeln dass man die defaults von ZFS besser findet. Aber am ende ist es halt Zusatzaufwand, dass ein Dateisystem nochmal alles anders macht.
rot: Moderator wanne spricht, default: User wanne spricht.
Re: BTRFS vs ZFS?
ist ja lustig was hier abgeht..
Aber ich wiederhole mich..
![Very Happy :D](./images/smilies/icon_biggrin.gif)
RAID z1 ist etwas zfs spezifisches und sagt im Grunde das es ein RAID5 ist. Als normalo würde ich mich über das 'z' im Namen wundern und würde schnell auf ein Ergebnis kommen, wenn ich jedoch unter btrfs ein RAID10 einrichte, dann gehe ich davon auch aus das ich mehr als 1Platte verlieren kann, was aber nicht der Fall ist, ich kann nur 1(!!!!!!!!!!!!!!!!!!!) Platte dort verlieren, es entspricht also eher einem RAID01, warum wird das in btrfs dann auch nicht so genannt, zudem ist diese Info nur sehr schwer zu finden und habe diese eindeutig nur auf der Mailingliste finden können. Auch kann ich die RAID1 Verteilung in einem btrfs-System nicht einstellen sondern muss einfach damit leben was btrfs da macht, ich kann somit die Platten nicht über JBODs verteilen, was in größeren Umgebungen schon durchaus Sinn macht.Auch ein RAID Z1 verhält sich auch nicht wie ein RAID 1.
Aber ich wiederhole mich..
Debian-Nutzer ![Very Happy :D](./images/smilies/icon_biggrin.gif)
ZABBIX Certified Specialist
![Very Happy :D](./images/smilies/icon_biggrin.gif)
ZABBIX Certified Specialist
- heisenberg
- Beiträge: 3567
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: BTRFS vs ZFS?
Persönliche Anmerkung zur Diskussion
- Die Diskussion kippt hier gerade hin zu viel Emotionalität und Hitzigkeit. Entspannt Euch Mal etwas.
- Es gibt nicht nur eine richtige Lösung, eine Meinung ein Szenario, sondern von allem 1000.
- Das Ziel der Diskussion ist es, tatsächliche Probleme anzuerkennen und nicht wegzureden und sich über diese Probleme konstruktiv auszutauschen
- Zuhören und Verstehen aller Positionen ist eine zentrale Fähigkeit einer gelungenen Diskussion
Zuletzt geändert von heisenberg am 16.05.2019 12:18:19, insgesamt 1-mal geändert.
Jede Rohheit hat ihren Ursprung in einer Schwäche.
- heisenberg
- Beiträge: 3567
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: BTRFS vs ZFS?
Ich bin mir nicht sicher, ob ich verstanden habe, was Du meinst. Deswegen male ich es nochmal auf:Colttt hat geschrieben:Wenn ich jedoch unter btrfs ein RAID10 einrichte, dann gehe ich davon auch aus das ich mehr als 1Platte verlieren kann, was aber nicht der Fall ist, ich kann nur 1 Platte dort verlieren, es entspricht also eher einem RAID01...
RAID-10 mit 4 Platten
Code: Alles auswählen
/---- Disk-1
/---- RAID-1 ----- Disk-2
RAID-0
\---- RAID-1 ----- Disk-3
\---- Disk-4
RAID-10 mit 6 Platten
Code: Alles auswählen
/--- Disk-1
/---- Disk-2
/---- RAID-1 ----- Disk-3
RAID-0
\---- RAID-1 ----- Disk-4
\---- Disk-5
\--- Disk-6
RAID-01 mit 4 Platten
Code: Alles auswählen
/---- Disk-1
/---- RAID-0 ----- Disk-2
RAID-1
\---- RAID-0 ----- Disk-3
\---- Disk-4
RAID-01 mit 6 Platten
Code: Alles auswählen
/--- Disk-1
/---- Disk-2
/---- RAID-0 ----- Disk-3
RAID-1
\---- RAID-0 ----- Disk-4
\---- Disk-5
\--- Disk-6
D. h. Du meinst, dass für RAID-01 Verbünde aus >4 Platten in der RAID-Subgruppe nur eine Platte ausfallen darf?
---
Das verstehe ich auch nicht. Kannst Du das nochmal erläutern?Auch kann ich die RAID1 Verteilung in einem btrfs-System nicht einstellen sondern muss einfach damit leben was btrfs da macht, ich kann somit die Platten nicht über JBODs verteilen, was in größeren Umgebungen schon durchaus Sinn macht.
Jede Rohheit hat ihren Ursprung in einer Schwäche.
Re: BTRFS vs ZFS?
Nein. Ein RAID5 ist mit eine Fehlerhaften (nicht ausgefallenen) platte kaputt und produziert nur noch Datenmüll. Deswegen willst du sowas nicht verwenden.Colttt hat geschrieben:16.05.2019 10:27:20RAID z1 ist etwas zfs spezifisches und sagt im Grunde das es ein RAID5 ist.
Das ist vielleicht tatsächlich ein Kritikpunkt den man machen kann. btrfs ist kein Software-Raid und auch kein LVM. Dass sie da einige Namen recycelt haben ist vielleicht etwas verwirrend.Colttt hat geschrieben:16.05.2019 10:27:20Als normalo würde ich mich über das 'z' im Namen wundern und würde schnell auf ein Ergebnis kommen, wenn ich jedoch unter btrfs ein RAID10 einrichte, dann gehe ich davon auch aus das ich mehr als 1Platte verlieren kann, was aber nicht der Fall ist, ich kann nur 1(!!!!!!!!!!!!!!!!!!!) Platte dort verlieren, es entspricht also eher einem RAID01, warum wird das in btrfs dann auch nicht so genannt
Aber: raid10 ist keine weiter standardisierter Name. Abseits von 4 platten macht da jeder was er für gut und richtig hält. Völlig offensichtlich das man sich da irgend wie erkundigen muss. Ich hätte genau das erwartet. Bei den meisten Herstellern ist es ein RAID0 aus vielen RAID1 mit je drei platten. Die drei ist aber willkürlich. Könnte auch eine 2 sein, was dann ziemlich genau dem was btrfs macht entspricht. mdraid verhält sich per default (also ohne Angabe von n,f,o) glaube ich auch auch exakt so wie btrfs so abwegig scheint das nicht zu sein.
Im RAID bereich eigentlich ziemlich üblich dass jeder seinen eigenen Scheiß macht.
Außer halt in der ersten Anlaufstelle, wo der übliche Linux-User nachguckt: In der man page zu mkfs.btrfs ist sogar extra eine super übersichtliche Tabelle. Schöner geht eigentlich nicht. Nie irgend was vergleichbares zu irgend welchen Hardwareeinstellungstools gefunden.zudem ist diese Info nur sehr schwer zu finden und habe diese eindeutig nur auf der Mailingliste finden können.
Wer maximale performance bei minimaler Datensicherheit haben will ist bei allen COW-Dateisystemen falsch. Die sind für wirklich große Umgebungen designend wo Flexibilität und Datesnsicherheit deutlich wichtiger ist als Performance.Colttt hat geschrieben:16.05.2019 10:27:20Auch kann ich die RAID1 Verteilung in einem btrfs-System nicht einstellen sondern muss einfach damit leben was btrfs da macht, ich kann somit die Platten nicht über JBODs verteilen, was in größeren Umgebungen schon durchaus Sinn macht.
Ich sehe bei den Diskussionen zu btrfs immer zwei Parteien:Das Ziel der Diskussion ist es, tatsächliche Probleme anzuerkennen und nicht wegzureden und sich über diese Probleme konstruktiv auszutauschen
a) Die neuen Leute, die weitestgehend überrascht von der Andersartigkeit sind. Denen kann man wirklich helfen aber nicht indem man möglichst intensiv nach Problemen sucht, sondern indem man darauf Aufmerksam macht, dass da ein paar Sachen ein bisschen anders Funktionieren und man mit etwas angepasster Vorgehensweise deutlich produktiver sein kann als mit den Klassischen Varianten. Das heißt aber eben vor allem die Stolpersteine zu umgehen.
b) Die Leute die von ZFS kommen und immer meinen dass das das einzig Stabiele COW-Dateisystem wäre und alles andere Müll. Die stören mich so langsam wirklich ein bisschen weil meine Erfahrung das absolute Gegenteil ist: Während die btrfs-Systeme bei uns ohne Probleme ihre Arbeit verrichten sind die ZFS-Systeme dauernd unbenutzbar. Das sind dann tatsächlich immer Gründe die nicht an ZFS direkt liegen alla der neue Linux-Treiber ist inkompatibel zum alten oder in einer neueren Version wäre das Problem schon gefixt oder da habe ich jetzt den boot-Prozess Verkackt. Am Ende sehe ich halt dass man da eine Menge Fallstrike hat, die btrfs nicht hat.
Für den Fall btrfs sind die meisten Probleme:
- Nutze niemals ein degraded btrfs. Im Notfall ein downgrade auf den single Mode. (Was dann wieder eine aktive Migration auf ein RAID verlangt.) Für HA brauchst du eigentlich dreifache Redundanz im Notfall wenigstens ein Hotspare.
- Mache niemals Kopieen von einem btrfs. Nutze die passenden snapshot und Sende funktionen. Ich sehe das wirklich als Bug an. Die Entwickler leider nicht.
- Nehme nicht an, dass das ein Performance-Wunder wird. Die stärke von btrfs ist Flexibilität und geringer Wartungsaufwand. Wenn du maximale Geschwindigkeiten haben willst geh wo anders hin.
- Guck dir an, welche Features stabil sind. Aktuell sollte man vor allem einen Bogen um RAID5/6 machen.
- Wenn du irgend welche btrfs-Kommandos nutzt, guck in die Manpage was die machen.
rot: Moderator wanne spricht, default: User wanne spricht.
Re: BTRFS vs ZFS?
Ich finde deine Erfahrungen interessant, bei unseren Systemen sieht es genau umgekehrt aus. Wir haben mit unseren ZFS-Systemen keine Probleme, dafür sind die BTRFS-Systeme allesamt ein problematisch und bedeuten erhöhten Supportaufwand.
Re: BTRFS vs ZFS?
aber gerne doch.. ich kann mit btrfs sowas hier nicht bauen: https://www.thomas-krenn.com/de/wiki/Ne ... 9_abfangenheisenberg hat geschrieben:16.05.2019 12:05:32Das verstehe ich auch nicht. Kannst Du das nochmal erläutern?Auch kann ich die RAID1 Verteilung in einem btrfs-System nicht einstellen sondern muss einfach damit leben was btrfs da macht, ich kann somit die Platten nicht über JBODs verteilen, was in größeren Umgebungen schon durchaus Sinn macht.
evtl ist mein englisch auch einfach nur schlecht (was ich definitiv nicht ausschliessen möchte).. aber man sagt hier das nur eine platte ausfallen darf:Außer halt in der ersten Anlaufstelle, wo der übliche Linux-User nachguckt: In der man page zu mkfs.btrfs ist sogar extra eine super übersichtliche Tabelle. Schöner geht eigentlich nicht. Nie irgend was vergleichbares zu irgend welchen Hardwareeinstellungstools gefunden.
später wird sogar gesagt eher ein RAID-1Ehttps://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg84731.html hat geschrieben: Btrfs raid10 really should not be called raid10. It sets up the wrong
user expectation entirely. It's more like raid0+1, except even that is
deceptive because in theory a legit raid0+1 you can lose multiple
drives on one side of the mirror (but not both); but with Btrfs raid10
you really can't lose more than one drive. And therefore it does not
scale. The probability of downtime increases as drives are added;
whereas with a real raid10 downtime doesn't change.
btrfs auf eine Platte würde ich empfehlen, aber sobald ums RAID geht, egal welches, würde ich ein bogen darum machen
Debian-Nutzer ![Very Happy :D](./images/smilies/icon_biggrin.gif)
ZABBIX Certified Specialist
![Very Happy :D](./images/smilies/icon_biggrin.gif)
ZABBIX Certified Specialist
Re: BTRFS vs ZFS?
Sehe ich im Prinzip auch so. Aber ich würde es anders formulieren: btrfs ersetzt keine klassischen RAIDs.Colttt hat geschrieben:17.05.2019 15:15:41btrfs auf eine Platte würde ich empfehlen, aber sobald ums RAID geht, egal welches, würde ich ein bogen darum machen
Es arbeitet aber hervorragend mit ihnen zusammen: Ein btrfs-RAID auf Klassischen RAIDS bringt dir eine Datensicherheit, die kein anderes RAID zusichern kann. (Weil es eben auch gegen Bitrot etc. schützt.) Aber eben nicht als Ersatz um HA bereitzustellen.
Ansonsten ist die single-Variante ist den Linear-Varianten ebenbürtig. Bei sehr vielen Devices kann es durchaus sinnvoll sein, nicht über alle Devices zu stripen. Dann kann man sich auch sowas auf klassischen RAIDs überlegen.
Auch dem stimme ich zu. Trotzdem: Wie gesagt: Defakto versteht jeder mit dem ich geredet habe etwas anderes unter einem RAID10. btrfs hat da jetzt nochmal eine Variante hinzugefügt. Ich würde weiter gehen und sagen: Niemand mehr sollte irgend was RAID10 nennen. Der Name ist verbrannt.Btrfs raid10 really should not be called raid10.
rot: Moderator wanne spricht, default: User wanne spricht.
- heisenberg
- Beiträge: 3567
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: BTRFS vs ZFS?
Was ich im Moment verstanden habe(man möge mich korrigieren, wenn ich Unrecht habe), tut es das gerade nicht, weil es Bitfehler ja nur bei einem Scrub erkennt. Wenn also nun ein Bitfehler auftritt, dann wird mit den kaputten Daten erst einmal weiter gearbeitet. Erst beim nächsten Scrub fällt der Bitfehler auf. Das ist jetzt nicht gerade das, was ich Datenintegrät nenne. Man kann sich darüber streiten, wie viel Performance das frißt, wenn man bei jedem lesen die Prüfsumme verifiziert, aber in Sachen Integrität ist das mal deutlich besser als das die Feststellung beim manuellen Scrub.wanne hat geschrieben:Es arbeitet aber hervorragend mit ihnen zusammen: Ein btrfs-RAID auf Klassischen RAIDS bringt dir eine Datensicherheit, die kein anderes RAID zusichern kann. (Weil es eben auch gegen Bitrot etc. schützt.)
Besser als gar keine Prüfsumme: Ja.
Hinsichtlich der Datenintegrität ist das prüfen(bzw. berichtigen aus einer korrekten Redundanzkopie) bei jedem Lesevorgang aber um Welten sicherer.
Edit: Ich habe nicht Jehova gesagt!
Jede Rohheit hat ihren Ursprung in einer Schwäche.