BTRFS vs ZFS?

Probleme mit Samba, NFS, FTP und Co.
Knogle
Beiträge: 272
Registriert: 06.05.2016 19:29:00
Lizenz eigener Beiträge: GNU General Public License

BTRFS vs ZFS?

Beitrag von Knogle » 14.05.2019 12:59:36

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.

Benutzeravatar
heisenberg
Beiträge: 1542
Registriert: 04.06.2015 01:17:27

Re: BRTFS vs ZFS?

Beitrag von heisenberg » 14.05.2019 13:36:30

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).
Die Welt und die Menschen brauchen Dich! Engagiere Dich für den Klimaschutz!

MSfree
Beiträge: 4552
Registriert: 25.09.2007 19:59:30

Re: BRTFS vs ZFS?

Beitrag von MSfree » 14.05.2019 14:09:25

heisenberg hat geschrieben: ↑ zum Beitrag ↑
14.05.2019 13:36:30
Kompression wäre für mich mal ein sehr wichtiges Feature(Erhöht die Kapazität und steigert die Performance).
Das sehe ich ein wenig anders.

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.

Benutzeravatar
heisenberg
Beiträge: 1542
Registriert: 04.06.2015 01:17:27

Re: BRTFS vs ZFS?

Beitrag von heisenberg » 14.05.2019 14:36:30

@MSfree:

Stimmt alles, was Du sagst. Bis auf Deine Schlußfolgerung:
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.
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.

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.
Die Welt und die Menschen brauchen Dich! Engagiere Dich für den Klimaschutz!

Knogle
Beiträge: 272
Registriert: 06.05.2016 19:29:00
Lizenz eigener Beiträge: GNU General Public License

Re: BRTFS vs ZFS?

Beitrag von Knogle » 14.05.2019 14:48:48

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.

MSfree
Beiträge: 4552
Registriert: 25.09.2007 19:59:30

Re: BRTFS vs ZFS?

Beitrag von MSfree » 14.05.2019 15:01:49

heisenberg hat geschrieben: ↑ zum Beitrag ↑
14.05.2019 14:36:30
Im Zweifelsfall kommt es auf die Einschätzung der Situation und einen Versuch an.
:THX:

Colttt
Beiträge: 2869
Registriert: 16.10.2008 23:25:34
Wohnort: Brandenburg
Kontaktdaten:

Re: BRTFS vs ZFS?

Beitrag von Colttt » 14.05.2019 16:33:54

ich hatte vor kurzem meinen kollegen mal meine Erfahrungen zu btrfs geschildert.. hier nochmal die Mail (ist von Ende Februar)
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.
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..
Debian-Nutzer :D

ZABBIX Certified Specialist

Benutzeravatar
bluestar
Beiträge: 1062
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: BRTFS vs ZFS?

Beitrag von bluestar » 14.05.2019 21:15:14

Knogle hat geschrieben: ↑ zum Beitrag ↑
14.05.2019 12:59:36
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.
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.
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.
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?
Ich habe schon einiges zu BRTFS gelesen, aber kann man es als "ebenbuertig" zu ZFS einstufen?
BTRFS ist leider keinesfalls mit ZFS auf gleicher Höhe.

Benutzeravatar
heisenberg
Beiträge: 1542
Registriert: 04.06.2015 01:17:27

Re: BRTFS vs ZFS?

Beitrag von heisenberg » 15.05.2019 06:58:20

bluestar hat geschrieben: ↑ zum Beitrag ↑
14.05.2019 21:15:14
BTRFS ist leider keinesfalls mit ZFS auf gleicher Höhe.
Kannst Du das genauer ausdrücken? In der Verallgemeinerung bringt es recht wenig Erkenntnis.
Die Welt und die Menschen brauchen Dich! Engagiere Dich für den Klimaschutz!

Benutzeravatar
bluestar
Beiträge: 1062
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: BRTFS vs ZFS?

Beitrag von bluestar » 15.05.2019 07:32:53

heisenberg hat geschrieben: ↑ zum Beitrag ↑
15.05.2019 06:58:20
Kannst Du das genauer ausdrücken? In der Verallgemeinerung bringt es recht wenig Erkenntnis.
Wenn ich von Stretch ausgehe, dann sieht das wie folgt aus:
* 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.

schwedenmann
Beiträge: 4375
Registriert: 30.12.2004 15:31:07
Wohnort: Wegberg

Re: BRTFS vs ZFS?

Beitrag von schwedenmann » 15.05.2019 08:16:46

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

wanne
Moderator
Beiträge: 5988
Registriert: 24.05.2010 12:39:42

Re: BRTFS vs ZFS?

Beitrag von wanne » 15.05.2019 15:11:03

MSfree hat geschrieben: ↑ zum Beitrag ↑
14.05.2019 14:09:25
Die Kompression beim schreiben und die Dekompression beim Lesen kosten nicht unerheblichen Rechenaufwand.

Quatsch
Bei einem Arbeitsplatzrechner geht die Kompression direkt von der CPU ab, verlangsamt das System also.
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.
MSfree hat geschrieben: ↑ zum Beitrag ↑
14.05.2019 14:09:25
Meiner Erfahrung nach ist Kompression im Dateisystem keine gute Idee, weil sie in meinen Einsatzfällen die Performance zerstört
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.
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:
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.
Mittlerweile sind 90% der Daten, die auf so nem PC liegen schlicht komprimierte Bilder in irgend einer Form. Viel zu holen ist da nicht.
Karte mit Dedup und Kompressiok extrem an die Grenzen.
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.)
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.
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.
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.
* Die Tools zpool und zfs sind deutlich angenehmer vom Handling her, versuche mal den Status eines RAIDs und der zugehörigen Devices herauszufinden...
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.
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:
* Raid5 Code noch nicht stabil
* Raid1 Ausfall einer HDD kann zu dauerhaftem Read-Only führen
* BTRFS kennt keine Volumes(vgl. zvol), lediglich Dateisystem
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.
Mein persönlicher Wunsch wäre eine ZFS-Reimplementation unter GPL als fester Kernelbestandteil, das würde BTRFS obsolet machen.
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.
Als weitere Punkte für ZFS Kann man noch nennen:
  • Keine vergleichbare Kompression
  • Keine deduplication
  • In einigen Spezialfällen deutlich schlechtere Performance
Wen die Punkte aber wenig interessieren, der hat mit btrfs eine Lösung, die halt einfach ohne zusätzliche Konfiguration tut.
rot: Moderator wanne spricht, default: User wanne spricht.

MSfree
Beiträge: 4552
Registriert: 25.09.2007 19:59:30

Re: BRTFS vs ZFS?

Beitrag von MSfree » 15.05.2019 15:48:02

wanne hat geschrieben: ↑ zum Beitrag ↑
15.05.2019 15:11:03
Quatsch ... hanebüchener Quatsch
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.

Benutzeravatar
bluestar
Beiträge: 1062
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: BTRFS vs ZFS?

Beitrag von bluestar » 15.05.2019 16:45:10

Ich muss muss bei der Performance Diskussion mal kurz nachhaken:
Knogle hat geschrieben: ↑ zum Beitrag ↑
14.05.2019 12:59:36
Aktuell betreibe ich mit 4x 2TB Platten einen RAID 10
Dann über die Performance über 10GBit bei 100MB/sek
Knogle hat geschrieben: ↑ zum Beitrag ↑
14.05.2019 14:48:48
Da ist die Rate teils auf 100MB/s eingebrochen.
Knogle hat geschrieben: ↑ zum Beitrag ↑
14.05.2019 14:48:48
Daher auch das RAID 10 für maximale Performance.
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.

Benutzeravatar
heisenberg
Beiträge: 1542
Registriert: 04.06.2015 01:17:27

Re: BTRFS vs ZFS?

Beitrag von heisenberg » 15.05.2019 16:50:46

Ich wäre jetzt mal vorsichtig, beim aktuellen Fall eine korrekt eingestellte ZFS-Konfiguration zu erwarten.
Die Welt und die Menschen brauchen Dich! Engagiere Dich für den Klimaschutz!

Antworten