BTRFS vs ZFS?

[Knogle]

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.

[heisenberg]

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).

[MSfree]

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.

[heisenberg]

@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.

[Knogle]

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]

Im Zweifelsfall kommt es auf die Einschätzung der Situation und einen Versuch an.

[Colttt]

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..

[bluestar]

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.

[heisenberg]

BTRFS ist leider keinesfalls mit ZFS auf gleicher Höhe.

Kannst Du das genauer ausdrücken? In der Verallgemeinerung bringt es recht wenig Erkenntnis.

[bluestar]

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]

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]

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.

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.

[MSfree]

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.

[bluestar]

Ich muss muss bei der Performance Diskussion mal kurz nachhaken:

Aktuell betreibe ich mit 4x 2TB Platten einen RAID 10

Dann über die Performance über 10GBit bei 100MB/sek

Da ist die Rate teils auf 100MB/s eingebrochen.

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.

[heisenberg]

Ich wäre jetzt mal vorsichtig, beim aktuellen Fall eine korrekt eingestellte ZFS-Konfiguration zu erwarten.

[heisenberg]

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.

[wanne]

Auch trotz der zu recht bemängelten Punkte von wanne ist für mich die ZFS-Administration sehr einfach.

A
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.

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.)).

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.
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.

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.

Kannst du den Bug dann auch für ext4 aufmachen oder für XFS?
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.

[Colttt]

ist ja lustig was hier abgeht..

Auch ein RAID Z1 verhält sich auch nicht wie ein RAID 1.

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.

Aber ich wiederhole mich..

[heisenberg]

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

[heisenberg]

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...

Ich bin mir nicht sicher, ob ich verstanden habe, was Du meinst. Deswegen male ich es nochmal auf:

RAID-10 mit 4 Platten

Code: Alles auswählen

                    /---- Disk-1
       /---- RAID-1 ----- Disk-2
RAID-0              
       \---- RAID-1 ----- Disk-3
                    \---- Disk-4

2 Platten können ausfallen ohne Datenverlust: Eine aus der Gruppe Disk-1/2 und zusätzlich eine aus der Gruppe Disk-3/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

4 Platten können ausfallen ohne Datenverlust: Zwei aus der Gruppe Disk-1/2/3 und zusätzlich zwei aus der Gruppe Disk-4/5/6.

RAID-01 mit 4 Platten

Code: Alles auswählen

                    /---- Disk-1
       /---- RAID-0 ----- Disk-2
RAID-1
       \---- RAID-0 ----- Disk-3
                    \---- Disk-4

2 Platten können ausfallen ohne Datenverlust: Eine aus der Gruppe Disk-1/2 und zusätzlich eine aus der Gruppe Disk-3/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

2 Platten können ausfallen ohne Datenverlust: Eine aus der Gruppe Disk-1/2/3 und zusätzlich eine aus der Gruppe Disk-3/4/5.

D. h. Du meinst, dass für RAID-01 Verbünde aus >4 Platten in der RAID-Subgruppe nur eine Platte ausfallen darf?

---

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.

Das verstehe ich auch nicht. Kannst Du das nochmal erläutern?

[wanne]

RAID z1 ist etwas zfs spezifisches und sagt im Grunde das es ein RAID5 ist.

Nein. Ein RAID5 ist mit eine Fehlerhaften (nicht ausgefallenen) platte kaputt und produziert nur noch Datenmüll. Deswegen willst du sowas nicht verwenden.

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

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.
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.

zudem ist diese Info nur sehr schwer zu finden und habe diese eindeutig nur auf der Mailingliste finden können.

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.

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.

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.

Das Ziel der Diskussion ist es, tatsächliche Probleme anzuerkennen und nicht wegzureden und sich über diese Probleme konstruktiv auszutauschen

Ich sehe bei den Diskussionen zu btrfs immer zwei Parteien:
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.

[bluestar]

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.

[Colttt]

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.

Das verstehe ich auch nicht. Kannst Du das nochmal erläutern?

aber gerne doch.. ich kann mit btrfs sowas hier nicht bauen: https://www.thomas-krenn.com/de/wiki/Ne ... 9_abfangen

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.

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:

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.

später wird sogar gesagt eher ein RAID-1E

btrfs auf eine Platte würde ich empfehlen, aber sobald ums RAID geht, egal welches, würde ich ein bogen darum machen

[wanne]

btrfs auf eine Platte würde ich empfehlen, aber sobald ums RAID geht, egal welches, würde ich ein bogen darum machen

Sehe ich im Prinzip auch so. Aber ich würde es anders formulieren: btrfs ersetzt keine klassischen RAIDs.
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.

Btrfs raid10 really should not be called raid10.

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.

[heisenberg]

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.)

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.

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!