BTRFS gegen ZFS?
- Thread starter DocMAX
- Start date
Naja, denkbar ist natürlich alles Mögliche...
Das kann natürlich nur ein Staffmember beantworten.
Solange es ZFS als integrierte Option gibt, bin ich sehr zufrieden.
Das kann natürlich nur ein Staffmember beantworten.
Solange es ZFS als integrierte Option gibt, bin ich sehr zufrieden.
Ich meinte damit könnte man BTRFS mit seinen Möglichkeiten genauso einsetzen wie ZFS?
BTRFS könnte (mich zumindest) zufriedener machen, da ich das Feature vermisse, RAIDZ zu erweitern oder in andere RAIDs zu konvertieren. BTRFS kann das schon, ZFS soll das wohl erst ab v2.3 können (https://github.com/openzfs/zfs/pull/15022).
BTRFS könnte (mich zumindest) zufriedener machen, da ich das Feature vermisse, RAIDZ zu erweitern oder in andere RAIDs zu konvertieren. BTRFS kann das schon, ZFS soll das wohl erst ab v2.3 können (https://github.com/openzfs/zfs/pull/15022).
Last edited:
Mit hoher Wahrscheinlichkeit und gemäß Radio Eriwan: "im Prinzip: ja!"
Aber das, was PVE ausmacht ist die "Middleware", die eben genau diese technischen Möglichkeiten in die BTRFS-Welt umsetzt und realisiert. Und zwar kompatibel zum bisherigen Verhalten der anderen Storage-Backends.
Meine Glaskugel zeigt nicht einmal ein verwaschendes Grau zu diesem Thema; die Implementierung ist bestimmt nicht trivial...
Ich denke das wird nix. Ich persönlich finde das bcachefs Projekt hat mehr Potential als BTRFS. Bei BTRFS sind seit Jahren alle RAID Implementierungen außer Mirror nicht stable und das wird wohl auch nix mehr.
Derzeit gibt es keine echte Alternative zu ZFS wenn man den Enterprise Einsatz betrachtet. Beim Homeeinsatz sieht das natürlich etwas anders aus, aber das ist ja nicht der Hauptfokus.
Derzeit gibt es keine echte Alternative zu ZFS wenn man den Enterprise Einsatz betrachtet. Beim Homeeinsatz sieht das natürlich etwas anders aus, aber das ist ja nicht der Hauptfokus.
Mit 6.7 rechne ich noch dieses Jahr bei Proxmox.
Es wäre schon schöner zum testen, wenn es einfach schon mit dem Kernel kommt.
Es wäre schon schöner zum testen, wenn es einfach schon mit dem Kernel kommt.
btrfs an sich ist schon cool ... wenn man ein paar mehr Platten hat. Mit 2 Platten macht btrfs keinen Spaß - gehen tut das natürlich auch. Aber wenn man da nicht weiß, was man tut, hat man sich ganz schnell das Dateisystem zerstört. (Huhu, eine Platte ist kaputt. Ich fahre mein "RAID1" mal degraded hoch, arbeite damit und merke beim nächsten Reboot, dass das FS irreparabel kaputt ist).
btrfs kann alles im laufenden Betrieb flexibel umkonvertieren (RAID1 -> RAID1C3 -> ... -> single und zurück).
btrfs kann flexibel Datenträger online dazu und wegnehmen. Bei ZFS ist das Essig, sobald man RAIDZ1/2/3-VDEVS hat. Da ist nix mehr mit device-removal. Da geht dass dann nur noch mit der ganz groben Kelle (backup+zpool neu erstellen+restore).
Ja. RAID5/6 gibt's bei btrfs nicht in stabil.
Ja. Encryption kann btrfs auch nicht.
Aufgrund RAIDZ-Device-Removal Einschränkung bin ich bei ZFS da sehr zurückhaltend das überhaupt einzusetzen.
btrfs kann alles im laufenden Betrieb flexibel umkonvertieren (RAID1 -> RAID1C3 -> ... -> single und zurück).
btrfs kann flexibel Datenträger online dazu und wegnehmen. Bei ZFS ist das Essig, sobald man RAIDZ1/2/3-VDEVS hat. Da ist nix mehr mit device-removal. Da geht dass dann nur noch mit der ganz groben Kelle (backup+zpool neu erstellen+restore).
Ja. RAID5/6 gibt's bei btrfs nicht in stabil.
Ja. Encryption kann btrfs auch nicht.
Aufgrund RAIDZ-Device-Removal Einschränkung bin ich bei ZFS da sehr zurückhaltend das überhaupt einzusetzen.
Last edited:
Irgendwie halten sich ZFS und BTRFS Featuremäßig die Waage finde ich. Tendenz geht aber richtung BTRFS. Mit RAID5 gabs bei mir noch nie Probleme. Der flexible RAID Level Switch ist echt super. Habe meine 4x18TB von Single auf RAID5 erfolgreich konvertiert. (Hat aber auch ne Woche gedauert )
)Ceph ist für ein paar wenige Platten ungeeignet. Ceph will meherere Storage Pools. Zu viel für den Haushaltsgebrauch.
Also auch die Maintainer stufen das BTRFS Raid5 als experimentell ein. Ich würde da keine echten Daten drauf legen. Wenn man dem Internet glauben darf gehen die auch gern mal über die Wupper.
Naja 3 SSDs pro Node sollten es schon sein. Für zuhause natürlich etwas viel, aber da reicht in der Regel auch ein Raid1
btrfs - raid5/6 : Ja. Da würde ich auch nochmal genau lesen, bevor ich das einsetzen würde... (Da ich das bisher noch nicht getan habe, fällt das für mich erst mal weg.)
https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid56-status-and-recommended-practices
https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid56-status-and-recommended-practices
Wie gesagt läuft seit Jahren ohne Probleme (hatte bisher aber auch kein power failure). Ausserdem halte ich Metadata in RAID1.
Nochmal ein paar Gedanken zum Thema von mir:
Ceph vs btrfs/ZFS
Wenn man einen ProxmoxVE-Cluster aufbauen möchte, dann ist Ceph imho das Mittel der Wahl, weil es das ist, was man braucht (Replikation, Netzwerkfähigkeit, Redundanz, Flexibilität). Natürlich hat Ceph auch höhere Anforderungen, d. h. ist teuerer von der benötigten Hardware. (Min. 10 GbE Netzwerk. Wahrscheinlich braucht man SSDs, wenn man darauf VMs betreiben will.) Insofern ist Ceph da btrfs/ZFS deutlich überlegen, bzw. es ist einfach etwas Anderes: Netzwerk-Storage vs. Local-Storage. Ein weiterer Vergleich lohnt da nicht. Im Rahmen dieses Beitrages gehe ich da also nicht weiter darauf ein. btrfs/ZFS kommt dann eher für Einzelsysteme in Betracht.
zu btrfs
RAID5/6
Ich habe das jetzt mal gelesen. Da steht: Es wird klar davon abgeraten. Bei einem unsauberen herunterfahren hat man vermutlich Datenverlust. So etwas möchte ich weder geschäftlich produktiv noch privat haben, außer für Daten, die anderweitig leicht neu erstellt werden können. Da sind die zahlreichen positiven Erfahrungsberichte im Internet, dass es ohne Stromausfall oder sonstigen Absturz sauber läuft für mich vollkommen unerheblich.
RAID-Level raid1c3, raid1c4
Diese Raidlevel des mirroring sind das Alleinstellungsmerkmal von btrfs. raid1 speichert Daten 2-fach auf 2 verschiedenen Datenträgern. raid1c3 3-fach auf 3 verschiedenen Datenträgern und raid1c4 4-fach auf 4 verschiedenen Datenträgern. Wer also erhöhte Redundanzwünsche hat, der hat in btrfs das gefunden, was er braucht.
Flexibilität von btrfs
btrfs ist wie schon geschrieben sehr flexibel in der Möglichkeit, Formate und Profile im laufenden Betrieb zu rekonfigurieren. Besonders interessant ist der Rebalance, der möglicherweise bei ZFS zum Problem werden könnte, weil es dort dies Möglichkeit nicht gibt und man darauf angewiesen ist, dass ZFS das selbst im Laufe der Nutzung ausbalanciert bekommt. Aber wirklich bringen tut einem die Flexibilität aus meiner Sicht aktuell noch nichts. Wenn man bei ZFS die Formate RAIDZ1/2/3 weglässt, dann bekommt man Erweiterungen und Reduktionen von Arrays damit auch wunderbar hin, also genau das gleiche, was auch btrfs im Moment bietet.
Weiterhin hat man gerade bei Proxmox VE mit ZFS noch weitere Möglichkeiten für Flexibilität - auch mit RAIDZ1/2/3. Denn hier kann man z. B. virtuelle Maschinen per LiveMigration auf ein anderes Storage ziehen und kann so also u. U. problemlos eine neue RAIDZ-Konfiguration in Betrieb nehmen.
Ein Vorteil von btrfs ist das Verwenden von unterschiedlichen Datenträgergrößen. Das Verständnis von raid1 bei btrfs ist hier nicht: Spiegelung zweier Datenträger, sondern Speicherung von 2 Kopien eines Blockes (Chunk) auf 2 verschiedenen Datenträgern. Das wirkt sich vor allem bei größeren Datenträgerzahlen positiv aus. Hat man nur 2 Festplatten z. B. 4 TB und 8 TB, dann kann man hier mit "raid1" natürlich auch nur 4 TB insgesamt speichern.
Besonderheit von btrfs bei Ausfall von Datenträgern
Die Besonderheit von btrfs ist hier, dass btrfs, wenn es das eingestellte Format nicht mehr erfüllen kann, dass es dann Datenblöcke im Single-Format schreibt. D. h. wenn eine Platte ausfällt, und es sind nicht mehr genügend Platten vorhanden - beispielsweise bei einem raid1 mit 2 Platten, wovon eine ausfällt, dann kann btrfs die Zusicherung von raid1 nicht mehr erfüllen: 2 Kopien der Daten auf unterschiedlichen Datenträgern. Dann schreibt es jetzt halt Single-Blöcke, ohne Redundanz. Führt man den btrfs replace mit der neuen Platte aus, wird dann wieder im raid1-Format weitergeschrieben. Aber: Die während des Ausfalls geschriebenen Single-Blöcke sind immer noch da! D. h. keine Redundanz dafür.
Das sieht man bei der Ausgabe von ...
Das muss man reparieren, z. B. damit:
Wenn man das nicht macht und man tauscht irgendwann mal eine Platte aus, auf der Single-Blöcke sind, dann war's das. Dateisystem verloren - verständlicherweise. Solche multiple block group profiles sollte man unbedingt vermeiden um nicht aus Versehen irgendwann einen Datenverlust zu erleben. Am Besten im Monitoring entsprechende Checks umsetzen.
In der Vergangenheit gab es im Bezug dazu noch einen Bug bzw. eine Entscheidung der Entwickler des Dateisystems, was IMO den Ruf des Dateisystems nachhaltig beschädigt hat, weil sehr viele Personen davon betroffen waren: Wenn ein System beim mounten - wie hier beschrieben - gemischte Formate aufwies, dann haben die btrfs-tools das Dateisystem als unrettbar zerstört angesehen und enstprechend geflaggt. Das Dateisystem wurde somit unwiderruflich read-only gesetzt und konnte somit nur durch backup, mkfs und restore wieder hergestellt werden. Dieser Bug wurde Ende 2017 gefixt. Jetzt kann ein Dateisystem auch mit gemischten Formaten ganz normal eingehängt werden.
Geschwindigkeit
Üblicherweise höre ich von btrfs-Begeisterten, dass btrfs etwas langsamer ist als andere Dateisysteme. Besonders die btrfs-raid10 Variante soll deutlich langsamer als ein tradionelles RAID-10 sein bzw. ein ZFS striped mirror.
Lizenzierung
ZFS ist unter der CDDL lizensiert, während btrfs unter der GPL steht. Alleine deswegen findet ZFS ohne Lizenzänderung vermutlich
niemals Eingang in die großen Linux-Distributionen. Die entsprechende Lücke, ZFS als Root-FS einsetzen zu können, wird hier nur durch den Einsatz von ProxmoxVE geschlossen, die einen entsprechenden Installer zur Verfügung stellen.
Native Integration
btrfs fügt sich in Sachen Konformität als normales Dateisystem ein, so wie auch die anderen Dateisysteme. Eintrag in fstab. Mount-Optionen. Spezifische btrfs-Attribute für Dateien und Verzeichnisse. ZFS ist da ein Fremdkörper, der alles auf seine eigene Art und mit seinen eigenen Tools umsetzt.
Andere Leistungsmerkmale
Was beide, also sowohl ZFS als auch btrfs, können sind Snapshots und Komprimierung. ZFS hat ansonsten noch die Verschlüsselung integriert. Bei btrfs spricht da nichts dagegen, dass man btrfs auf gängigen OSS-Verschlüsselungslösungen (LUKS) aufsetzt. Ebenso unterstützen beide Checksummen. Beide können Unterdateisysteme anlegen.
Persönliches Fazit
Dinge unter btrfs waren in der Vergangenheit mitunter übel, aber sie wurden besser. Aktuell sehe ich noch keinen großen Vorteil dabei, btrfs einzusetzen, es sei denn, man möchte die Formatoptionen für höhere Redundanzlevel nutzen. Ansonsten gibt es für alle Anwendungsfälle bessere Optionen. Trotzdem sehe ich btrfs schon fast gleich auf mit ZFS. Es kann fast für die gleichen Dinge eingesetzt werden, wenn es auch nicht die beste/performanteste Wahl ist.
Ich habe hier auch einige Themen nicht angeschnitten, weil ich diese persönlich nicht nutze (ZVOLs, cp --reflinks, ...).
Insgesamt habe ich bei btrfs ein besseres Bauchgefühls zur Qualität der technischen Umsetzung des Dateisystems. Insofern bin ich bei btrfs optimistischer, was die Zukunft angeht. Ich habe jetzt schon wiederholt erlebt, wie Dinge in btrfs sich gut entwickelt haben, wo ich vorher nur am Kopfschütteln gewesen bin. (btrfs konnte irgendwann dann mal Snapshots - aber keinen Rollback. Aussage ob das irgendwann kommt: keine wahrgenommen. wtf?)
Ceph vs btrfs/ZFS
Wenn man einen ProxmoxVE-Cluster aufbauen möchte, dann ist Ceph imho das Mittel der Wahl, weil es das ist, was man braucht (Replikation, Netzwerkfähigkeit, Redundanz, Flexibilität). Natürlich hat Ceph auch höhere Anforderungen, d. h. ist teuerer von der benötigten Hardware. (Min. 10 GbE Netzwerk. Wahrscheinlich braucht man SSDs, wenn man darauf VMs betreiben will.) Insofern ist Ceph da btrfs/ZFS deutlich überlegen, bzw. es ist einfach etwas Anderes: Netzwerk-Storage vs. Local-Storage. Ein weiterer Vergleich lohnt da nicht. Im Rahmen dieses Beitrages gehe ich da also nicht weiter darauf ein. btrfs/ZFS kommt dann eher für Einzelsysteme in Betracht.
zu btrfs
RAID5/6
Ich habe das jetzt mal gelesen. Da steht: Es wird klar davon abgeraten. Bei einem unsauberen herunterfahren hat man vermutlich Datenverlust. So etwas möchte ich weder geschäftlich produktiv noch privat haben, außer für Daten, die anderweitig leicht neu erstellt werden können. Da sind die zahlreichen positiven Erfahrungsberichte im Internet, dass es ohne Stromausfall oder sonstigen Absturz sauber läuft für mich vollkommen unerheblich.
RAID-Level raid1c3, raid1c4
Diese Raidlevel des mirroring sind das Alleinstellungsmerkmal von btrfs. raid1 speichert Daten 2-fach auf 2 verschiedenen Datenträgern. raid1c3 3-fach auf 3 verschiedenen Datenträgern und raid1c4 4-fach auf 4 verschiedenen Datenträgern. Wer also erhöhte Redundanzwünsche hat, der hat in btrfs das gefunden, was er braucht.
Flexibilität von btrfs
btrfs ist wie schon geschrieben sehr flexibel in der Möglichkeit, Formate und Profile im laufenden Betrieb zu rekonfigurieren. Besonders interessant ist der Rebalance, der möglicherweise bei ZFS zum Problem werden könnte, weil es dort dies Möglichkeit nicht gibt und man darauf angewiesen ist, dass ZFS das selbst im Laufe der Nutzung ausbalanciert bekommt. Aber wirklich bringen tut einem die Flexibilität aus meiner Sicht aktuell noch nichts. Wenn man bei ZFS die Formate RAIDZ1/2/3 weglässt, dann bekommt man Erweiterungen und Reduktionen von Arrays damit auch wunderbar hin, also genau das gleiche, was auch btrfs im Moment bietet.
Weiterhin hat man gerade bei Proxmox VE mit ZFS noch weitere Möglichkeiten für Flexibilität - auch mit RAIDZ1/2/3. Denn hier kann man z. B. virtuelle Maschinen per LiveMigration auf ein anderes Storage ziehen und kann so also u. U. problemlos eine neue RAIDZ-Konfiguration in Betrieb nehmen.
Ein Vorteil von btrfs ist das Verwenden von unterschiedlichen Datenträgergrößen. Das Verständnis von raid1 bei btrfs ist hier nicht: Spiegelung zweier Datenträger, sondern Speicherung von 2 Kopien eines Blockes (Chunk) auf 2 verschiedenen Datenträgern. Das wirkt sich vor allem bei größeren Datenträgerzahlen positiv aus. Hat man nur 2 Festplatten z. B. 4 TB und 8 TB, dann kann man hier mit "raid1" natürlich auch nur 4 TB insgesamt speichern.
Besonderheit von btrfs bei Ausfall von Datenträgern
Die Besonderheit von btrfs ist hier, dass btrfs, wenn es das eingestellte Format nicht mehr erfüllen kann, dass es dann Datenblöcke im Single-Format schreibt. D. h. wenn eine Platte ausfällt, und es sind nicht mehr genügend Platten vorhanden - beispielsweise bei einem raid1 mit 2 Platten, wovon eine ausfällt, dann kann btrfs die Zusicherung von raid1 nicht mehr erfüllen: 2 Kopien der Daten auf unterschiedlichen Datenträgern. Dann schreibt es jetzt halt Single-Blöcke, ohne Redundanz. Führt man den btrfs replace mit der neuen Platte aus, wird dann wieder im raid1-Format weitergeschrieben. Aber: Die während des Ausfalls geschriebenen Single-Blöcke sind immer noch da! D. h. keine Redundanz dafür.
Das sieht man bei der Ausgabe von ...
Code:
# btrfs filesystem df /mountpoint
...
WARNING: Multiple block group profiles detected, see 'man btrfs(5)'
WARNING: Data: single, raid1Das muss man reparieren, z. B. damit:
Code:
btrfs balance start -mconvert=raid1 -dconvert=raid1 /mountpointWenn man das nicht macht und man tauscht irgendwann mal eine Platte aus, auf der Single-Blöcke sind, dann war's das. Dateisystem verloren - verständlicherweise. Solche multiple block group profiles sollte man unbedingt vermeiden um nicht aus Versehen irgendwann einen Datenverlust zu erleben. Am Besten im Monitoring entsprechende Checks umsetzen.
In der Vergangenheit gab es im Bezug dazu noch einen Bug bzw. eine Entscheidung der Entwickler des Dateisystems, was IMO den Ruf des Dateisystems nachhaltig beschädigt hat, weil sehr viele Personen davon betroffen waren: Wenn ein System beim mounten - wie hier beschrieben - gemischte Formate aufwies, dann haben die btrfs-tools das Dateisystem als unrettbar zerstört angesehen und enstprechend geflaggt. Das Dateisystem wurde somit unwiderruflich read-only gesetzt und konnte somit nur durch backup, mkfs und restore wieder hergestellt werden. Dieser Bug wurde Ende 2017 gefixt. Jetzt kann ein Dateisystem auch mit gemischten Formaten ganz normal eingehängt werden.
Geschwindigkeit
Üblicherweise höre ich von btrfs-Begeisterten, dass btrfs etwas langsamer ist als andere Dateisysteme. Besonders die btrfs-raid10 Variante soll deutlich langsamer als ein tradionelles RAID-10 sein bzw. ein ZFS striped mirror.
Lizenzierung
ZFS ist unter der CDDL lizensiert, während btrfs unter der GPL steht. Alleine deswegen findet ZFS ohne Lizenzänderung vermutlich
niemals Eingang in die großen Linux-Distributionen. Die entsprechende Lücke, ZFS als Root-FS einsetzen zu können, wird hier nur durch den Einsatz von ProxmoxVE geschlossen, die einen entsprechenden Installer zur Verfügung stellen.
Native Integration
btrfs fügt sich in Sachen Konformität als normales Dateisystem ein, so wie auch die anderen Dateisysteme. Eintrag in fstab. Mount-Optionen. Spezifische btrfs-Attribute für Dateien und Verzeichnisse. ZFS ist da ein Fremdkörper, der alles auf seine eigene Art und mit seinen eigenen Tools umsetzt.
Andere Leistungsmerkmale
Was beide, also sowohl ZFS als auch btrfs, können sind Snapshots und Komprimierung. ZFS hat ansonsten noch die Verschlüsselung integriert. Bei btrfs spricht da nichts dagegen, dass man btrfs auf gängigen OSS-Verschlüsselungslösungen (LUKS) aufsetzt. Ebenso unterstützen beide Checksummen. Beide können Unterdateisysteme anlegen.
Persönliches Fazit
Dinge unter btrfs waren in der Vergangenheit mitunter übel, aber sie wurden besser. Aktuell sehe ich noch keinen großen Vorteil dabei, btrfs einzusetzen, es sei denn, man möchte die Formatoptionen für höhere Redundanzlevel nutzen. Ansonsten gibt es für alle Anwendungsfälle bessere Optionen. Trotzdem sehe ich btrfs schon fast gleich auf mit ZFS. Es kann fast für die gleichen Dinge eingesetzt werden, wenn es auch nicht die beste/performanteste Wahl ist.
Ich habe hier auch einige Themen nicht angeschnitten, weil ich diese persönlich nicht nutze (ZVOLs, cp --reflinks, ...).
Insgesamt habe ich bei btrfs ein besseres Bauchgefühls zur Qualität der technischen Umsetzung des Dateisystems. Insofern bin ich bei btrfs optimistischer, was die Zukunft angeht. Ich habe jetzt schon wiederholt erlebt, wie Dinge in btrfs sich gut entwickelt haben, wo ich vorher nur am Kopfschütteln gewesen bin. (btrfs konnte irgendwann dann mal Snapshots - aber keinen Rollback. Aussage ob das irgendwann kommt: keine wahrgenommen. wtf?)
Last edited:
Bei ZFS kannst du doch auch 3 oder 4 Disks in einen Mirror packen mit 3 oder 4 Kopien, wenn da mehr Redundanz gewünscht ist. Das ist doch gängige Praxis, dass man da Striped 3-Disk-Mirrors benutzt, wenn man die Redundanz eines Raidz2/Raid6 will aber die Performance eines normalen Striped Mirror/Raid10.
Das macht ZFS doch aber auch. Ich kann doch 2x 4TB Disk Mirror + 2x 8TB Disk Mirror stripen. Der resultierende Striped Mirror hat dann 12TB und wenn ich was Schreibe dann versucht ZFS die Daten so zwischen den Mirrors aufzuteilen, dass da beide Mirror ungefähr gleich voll sind. Dann gehen halt 2/3 der Writes auf den 8TB Mirror und 1/3 der Writes auf den 4TB Mirror. Nicht so ideal für die Performance, wenn ein Mirror mehr zu tun hat als der andere, weshalb man gleiche große Disks bevorzugt (wie 2x 6TB + 2x 6TB), aber sonst unproblematisch.
Last edited:
Ja. Stimmt!
Btrfs macht das halt nochmal ein bisschen anders. Es kümmert sich halt nicht so um die Plattengrößen. Du kannst da die Grabbelkiste an Platten zusammen werfen: 1 TB, 4 TB, 8 TB, 10 TB, 12 TB und btrfs setzt dann um: 2 Kopien eines Chunks auf zwei verschiedenen Datenträgern. Ob das jetzt unbedingt ein wertvoller UseCase ist? Da habe ich noch nicht drüber nachgedacht. Es ist erst einmal nur anders. Performancetechnisch ist das wahrscheinlich auch alles andere als optimal.
Bei ZFS muss man halt ein neues VDEV (mindestens 2 Platten) dazufügen, wenn man erweitern möchte. Bei btrfs fügt man irgend eine einzelne Platte dazu und sagt: Balance!
Der Unterschied ist, dass man den ganzen Pool jederzeit komplett umstellen kann: Wenn mir einfällt, ich möchte jetzt gerade mal das Redundanzlevel von raid1 (=2-fach) auf raid1c4 (=4-fach) umstellen, dann ist das ein Kommando (was je nach Poolgröße vielleicht dann auch schon mal eine Woche dauert?). Bei ZFS müsste ich mir da jetzt den Pool anschauen und prüfen ob und wie ich das mit der Plattenkonfiguration hinbekomme. Wahrscheinlich ist das dort so nicht möglich.
Nachtrag
Was mich gerade eben noch etwas geschockt hat: btrfs kann man nicht reparieren, wenn es kaputt ist. Es gibt zwar ein btrfsck, aber reparieren kann das wahrscheinlich nix - mehr noch: Es hat zwar eine Option --repair, aber da stehen überall fette Warnungen dabei, dass man die nur dann verwenden soll, wenn einem ein Btrfs-Entwickler das empfohlen hat.
Es gibt aber trotzdem Empfehlungen, was man in solchen Fällen tun sollte:
https://en.opensuse.org/SDB:BTRFS#How_to_repair_a_broken.2Funmountable_btrfs_filesystem
Also in 5 Jahren nochmal schauen ...
Last edited:
Ich sehe das anders. Mir scheint BTRFS ein solides Linux-Projekt zu sein. Da gibt es kontinuierlich Änderungen. (Siehe: Changes auf https://btrfs.readthedocs.io/). Da ist zwar insgesamt recht wenig Medienaufmerksamkeit, aber dennoch findet die Entwicklung statt. Ich sehe da keine Stagnation. Ich merke, wie Dinge im Laufe der Zeit besser werden. (Z. B. Dokumentation).
Schaut man sich da die Contributors-Seite (https://btrfs.readthedocs.io/en/latest/Contributors.html) an, sind da bei der aktuellen Major Version und den einzelnen Releases Codebeiträge von 18 - 28 Entwicklern dabei. An Firmen sind hier SuSE, Facebook, Western Digital und Oracle vertreten - bei denen die vorgenannten Entwickler vermutlich arbeiten.
Ein neues Dateisystem from-scratch zu schreiben ist keine Kleinigkeit. Es ist interessant, das ZFS da deutlich schneller zu Potte kam - es ist ja ungefähr genauso lange da wie btrfs. Bcachefs ist im Vergleich zu BTRFS einige Jahre hinten dran. Ich würde vermuten, dass bcachefs da deutlich weniger manpower hat.
Ist ein OpenSource-Konzept nicht auch das Anliegen, Dinge richtig gut zu machen? Und bei einem Dateisystem wäre es für mich die Stelle, wo ich mich freue, wenn sich die Entwickler mal richtig viel Zeit nehmen.
Last edited: