Flexibles Dateisystem für NAS und VM-Host: Btrfs?

[Shutterfly]

Hallo,

ich betreibe auf meinem Heim-Server derzeit eine wohl eher exotische ext4, SnapRaid, MergerFS Kombination und habe von @tolga9009 irgendwie einen Btrfs-Floh ins Ohr gesetzt bekommen, welchen ich gerne mal diskutieren wollen würde. Hierzu möchte ich kurz mein aktuelles Setup und meine Gründe für diese Entscheidungen darlegen, danach möchte ich auf Btrfs zu sprechen kommen. Sehr gerne sind Meinungen, Erfahrungen, Anregungen oder einfach Hinweise zu Denkfehlern willkommen

Aktuelles Setup betreibe ich derzeit gut vier Jahre:

• Arch Linux für VMs (KVM) und Docker
• OS auf SSD
• 4x2 TB WD Red
  • Drei von vier Platten per MergerFS als Mount-Point (NFS für VMs, SMB für Clients, Ablage von VM-Images etc.)
  • Vierte Platte für Parität und wöchentliches Scrubbing per SnapRaid
  • Hat also ganz entfernt etwas von RAID 3, nur ohne Striping

Gründe für dieses Setup waren bzw. sind:

• Ich möchte flexibel sein bei den Speicherplatz-Upgrades. Ich kann derzeit beliebig große Festplatten ins System hängen, solang die Platte mit Parität die Größte ist. Es geht kein Platz verloren
• Neu eingefügte Platten lassen sich dank MergerFS problemlos zu einem Mount-Point zusammenfügen, so dass z.B. SMB-Nutzer nichts beachten oder beachten müssen. MergerFS kümmert sich ums Balancing
• Durch LUKS sind alle Festplatten verschlüsselt. Primär wegen Diebstahl
• Scrubing jede Woche schützt mehr vor Bit Rot als normales RAID
• Jede Nacht wird ein Sync "zur Paritätsplatte" durchgeführt. Gelöschte Daten können bis zu diesem Zeitpunkt wiederhergestellt werden
• Da die Daten effektiv immer nur auf einer Platte liegen, habe ich nur normalen SATA-Speed. Durch max. 1Gbit-Anbindung im LAN limitiert jedoch der LAN-Anschluss
• Da die Daten effektiv immer nur auf einer Platte liegen, verliere ich beim Ausfall von zwei Platten nur die jeweilige Daten. Jede Platte hat ein normales ext4-Dateisystem und könnte normal an einem PC gemountet werden

Ist das Setup perfekt? Definitiv nicht. Passt es zu meinem Anwendungsfall? Ja.

Wieso komme ich nun als auf Btrfs? Bei einem anderen Beitrag bzgl. Container und VMs hat @tolga9009 mich auf Btrfs aufmerksam gemacht. Im Zuge von Recherchen zu LXC/LXD bin ich auf gute Kompatibilität bzw. Effektive Nutzung von Features von Btrfs durch LXD erneut auf das Thema gestoßen. Insbesondere interessieren mich Snapshots. Ein umfangreicheren Schutz vor Bit Rots nehme ich gerne mit.

Inzwischen habe ich mich in die Sache mehr eingelesen, da ich grundsätzlich interessiert bin, jedoch auch nicht vollends überzeugt. Nun werden vermutlich einige Leute direkt mit ZFS kommen, welches ebenfalls gut mit LXD harmonisieren soll. Aus folgenden Gründen sehe ich mich derzeit nicht bei ZFS:

• Ich möchte aus finanziellen Gründen derzeit keine weiteren oder größere Platten ins System nehmen. Von den effektiven 6TB (gerundet) nutze ich 4TB. Würde ich ZFS nehmen wollen, bliebe nur ein RAIDZ1
• ZFS ist, soweit ich das nun in vielen Recherchen wahrnehmen konnte, zu unflexibel bzw. starr. Möchte ich meinen Speicherplatz vergrößern, z.B. durch Tausch einiger Platten gegen größere, hinzufügen einer weiteren oder Umstellung von 4x2 TB auf 2x8 TB, dann ist es bei ZFS gefühlt umständlicher, da ZFS einfach aus der Business-Welt kommt. Dort juckt es i.d.R. nicht ob man nun 4 oder 8 Platten neu kaufen müssen, es muss laufen. Für mich als Privat-Person macht es einen Unterschied

Bei Btrfs werfe ich derzeit ein Auge auf ein RAID5, weil ich auch so andernfalls meine Anforderung nicht erfüllen kann. Jede Platte würde erst mit LUKS verschlüsselt, on top käme dann Btrfs. Über die Stable-Geschichte bei Btrfs und RAID5/6 bin ich mir bewusst, sehe es aber nicht als Problem an:

• Ich habe nicht den Anspruch einer Produktiv-Business-Umgebung wie sie zur Stable-Bewertung herangezogen wird
• Verwendet Arch Linux stets den aktuellsten Kernel, somit auch das aktuellste Btrfs
• Habe ich in den letzten 12 Monaten eigentlich nur positive Rückmeldungen zu RAID5 im Heimgebrauch finden können

Wieso als Btrfs gegenüber ZFS, wenn ich technisch vom Speicherplatz bei beiden gleich herauskommen würde: Btrfs erlaubt die volle Ausnutzung von unterschiedlich großen Platten im RAID5, solang die Paritätsplatte ebenfalls die maximale Größe hat. Automatisches Balancing ohne manuelles Löschen und neu Schreiben gibts gratis dazu. Tägliche Sicherheitskopien könnte ich mit Snapshots realisieren.

Was ich natürlich verlieren würde, wäre die Möglichkeit noch Daten zu haben, wenn mehr als eine Platte stirbt, da ein externes Backup derzeit nur einmal in der Woche gemacht wird. Diese Pille muss ich dann an der Stelle wohl schlucken.

Technisch würde ich dieses Setup einmal per VM mit mehreren Platten simulieren und testen, ob wirklich alles so läuft, wie ich es mir vorstelle. Das wäre der technische Teil. Was mir fehlt, und weswegen ich nun den Beitrag überhaupt mache, ist Erfahrung. Die würde ich auf die schnelle nicht ausreichend bekommen und daher interessieren mich eure Meinungen. Bei Unklarheiten auch gerne genauer Nachfragen. Der Text ist schon so lang und ich möchte nicht jedes Detail ewig klein ausrollen.

 

[tolga9009]

Bzgl. BTRFS RAID5 fasst folgender Beitrag von einem der BTRFS Developer alles ganz gut zusammen: https://www.spinics.net/lists/linux-btrfs/msg101483.html. Ich empfehle den gesamten Beitrag zu lesen, da dort sehr wertvolle und aktuelle Informationen & Empfehlungen zu dem Thema zu finden sind.

Zwei weitere Punkte bzgl. BTRFS, die meiner Meinung nach wichtig sind:

- BTRFS RAID funktioniert etwas anders als traditionelles RAID. Das muss man sich erst einmal bewusst machen. So kann z.B. ein BTRFS RAID mit weniger als Minimum Disks nur noch als Degraded gemountet werden. Beispiel: RAID1 mit 2 Disks (Minimum). Eine Platte fliegt raus -> Dateisystem wird Read-Only und muss als Degraded gemountet werden. Das ist für Produktiv-Systeme eine Katastrophe. Bei einem RAID1 aus 3 Platten ist das jedoch kein Problem: fliegt eine Platte raus, kann ganz normal weitergearbeitet werden. Minimum Disks für RAID5 sind 3, für RAID6 und RAID10 sind es 4.

- So kommen wir dann auch zum zweiten Punkt: der Tausch von Festplatten. Z.B. RAID1 mit 2 Festplatten, 1 Festplatte weist kaputte Sektoren auf, die ich nun tauschen möchte. Entferne ich diese Festplatte, damit ich eine neue einsetzen kann, haben wir den Fall aus dem vorherigen Punkt: das FS wird Read-Only und muss als Degraded gemountet werden, da wir ja unterhalb von Minimum Devices sind. Daher muss der Tausch wie folgt stattfinden: ich setze die neue Festplatte ein (insgesamt nun 3 Festplatten), führe btrfs replace aus und erst nach Fertigstellung des Vorgangs entferne ich die alte Festplatte.

Was "replace" macht: es kopiert 1:1 die kaputte Festplatte. Wenn eine Datei nicht lesbar ist oder kaputte Checksummen liefert, wird es von den intakten Festplatten kopiert. Vorteil von dem ganzen ist, dass wir auch während des Austausches jederzeit die volle Ausfallsicherheit haben. Selbst wenn die kaputte Festplatte während des Vorgangs aussteigt, können die Daten immernoch von den anderen Festplatten gezogen werden. Nachteil: du brauchst einen zusätzlichen SATA-Port.

Du könntest aber auch ganz auf BTRFS RAID verzichten und nach wie vor SnapRAID dafür verwenden.

 

[ludwinator]

Ich empfehle jedem, der über den Einsatz von BTRFS nachdenkt, den von Tolga verlinkten Thread zu lesen. Wer am Ende mehr Fragen als Antworten hat, muss tiefer einsteigen oder die Finger davon lassen.
Erinnert mich an ZFS vor 8-10 Jahren.
Cu

 

[gea]

Erinnert mich an ZFS vor 8-10 Jahren.
Cu

Ich habe mir ca 2008, also vor 12 Jahren meinen ersten kommerziellen ZFS Server zugelegt (NexentaStor) und fand das schon damals um eine Größenordnung stabiler als meine Windows ntfs Server. Die ZFS Enwicklung begann ja schon sehr viel früher und seit 2006 ist ZFS Bestandteil von Solaris, einem kommerziellen Unix.

Btrfs steckt im Vergleich dazu noch in den "Windeln". Ob es mal wirklich Reife erhält ist angesichts des Erfolgs von ZFS auf allen Plattformen noch nicht sicher.

 

[Stueckchen]

Ich hatte eine Zeit lang vor allem in ner ARM-NAS BTRFS laufen (vor so 3 Jahren), war damit eigentlich ganz zufrieden. Performance war auch OK. Bin zwar zu ZFS gewechselt aber Hauptsächlich aufgrund der mangelnden webGUI von BTRFS.
Wenn man sich etwas an die Vorgaben hält, also keine Metadaten auf Raid5/6 sehe ich keine großen Problem. Verzichtet man ganz auf das Raid, habe ich noch nicht von großen BUGs gelesen. Bei Syno läuft das ja auch sehr stabil.

 

[Cantor]

Ich teste gerade ein BTRFS RAID1 mit 4x 2TB.
Wenn man sich den verlinkten Bericht von tolga durchliest, scheint ja RAID5 data mit RAID1 metadata durchaus nutzbar zu sein.

Ich finde es jedenfalls ein spannendes Dateisystem. Hatte zuvor jahrelang ein Software RAID5 erfolgreich im Einsatz, aber die zusätzliche Sicherheit vor Bit Rot macht es gerade für private Daten recht interessant.

 

[Digi-Quick]

Wie kann ein CoW FS eigentlich ein Write Hole Problem haben??
Ich dachte CoW eleminiert das Write Hole....

 

[gea]

Das geht ganz einfach.

Man muss nur ein Hardwareraid oder "Fremd" Softwareraid einsetzen. Dabei sieht z.B. ZFS nur eine einzelne Platte an den ein Write übermittelt wird. Das Raid schreibt dann eigenständig die Raidstripes sequentiell oder beschreibt die Platten eines Mirrors nacheinander. Ein Absturz beim Schreiben und man hat ein korruptes Raid oder inkonstistenten Mirror. ZFS oder btrfs/ReFS kann dagegen garnichts machen.

Nur wenn z.B. ZFS jede Einzelplatte des Raid im Zugriff hat, kann es einen Schreibvorgang im Raid kontrollieren und den komplett ausführen oder er wird im Falle eines Absturzes komplett verworfen.

 

[tolga9009]

Btrfs steckt im Vergleich dazu noch in den "Windeln". Ob es mal wirklich Reife erhält ist angesichts des Erfolgs von ZFS auf allen Plattformen noch nicht sicher.

BTRFS ist das Standard Dateisystem bei SLES ist u.a. bei Facebook und Synology millionenfach im Einsatz. Ich denke so schlecht kann es nicht sein. Es gibt einige Features von BTRFS, die aktuell als instabil eingestuft sind und vielleicht vor einem "BTRFS2" auch niemals funktionieren werden. Dafür hat es aber auch stabile Features, die andere Lösungen nicht bieten (können), wie etwa das Mixed-Size RAID oder flexibles Grow / Shrink - was eben für manche Heimanwender sehr attraktiv ist. Insbesondere, wenn man mit einem kleineren Budget arbeiten muss. Es gibt einfach Fälle, wo BTRFS die einzige, logische Antwort ist.

Wenn man heutzutage noch über Katastrophenfälle liest, sind es in 9 von 10 Fällen Steinzeit Kernel-Versionen oder grob-fahrlässige User-Error. Im Gegensatz zu ZFS steht nicht in jedem Wiki / Blog, dass man Enterprise-Hardware mit ECC Memory einsetzen muss; die Leute nutzen BTRFS z.T. auf einem Raspberry Pi. Das ist ähnlich wie mit den Leuten, die ein 2500€ MacBook Pro mit einem 300€ Medion-Laptop vergleichen und Windows deshalb "schlecht, langsam und instabil" ist.

Ich denke jeder muss die Pro / Contra für seinen Anwendungsfall individuell abwägen und dann selbst entscheiden.

 

[Cantor]

Im Gegensatz zu ZFS steht nicht in jedem Wiki / Blog, dass man Enterprise-Hardware mit ECC Memory einsetzen muss; die Leute nutzen BTRFS z.T. auf einem Raspberry Pi.

Ich hoffe, ich habe diese Aussage nun nicht aus dem Zusammenhang gerissen.

Siehst du es kritisch, BTRFS auf einem Raspberry Pi im RAID1 zu verwenden? Klar, er hat kein ECC, aber das fehlt mir auch bei einem 2500 Euro MacBookPro.
Und die Performance ist auch nicht die Beste, aber für GBit Lan durchaus ausreichend.

 

[Digi-Quick]

@gea
Meine Frage bezog sich auf BTRFS, welches ja bekannlich auch ein CoW FS sein soll

 

[gea]

Egal ob btrfs, ReFS oder ZFS.

Nur wenn diese volle Kontrolle über jede CoW Operation und über jede Platte im Raid haben, können atomare und abhängige Schreibvorgänge wie Daten + Metadaten oder alle Raidoperationen komplett oder garnicht ausgeführt werden. Damit vermeidet man das Write Hole Problem teilweise ausgeführter abhängiger Schreibaktionen.

 

[tolga9009]

Siehst du es kritisch, BTRFS auf einem Raspberry Pi im RAID1 zu verwenden?

Worauf ich hinaus wollte: im Durchschnitt sind auf Server Hardware mit weniger hardwarespezifischen Problemen zu rechnen, als auf einem Raspberry Pi. Aufgabe von BTRFS ist es, Fehler zu erkennen und zu korrigieren. Besser ist es aber, wenn diese Fehler garnicht erst auftauchen.

Ich nehme an, die Festplatten werden per USB angeschlossen? Du kannst ja mal die ZFS-Leute fragen, was die davon halten würden. Es gilt genau dasselbe auch für BTRFS, auch wenn dies in den Wikis und Mailing Listen so nicht kommuniziert wird. Die ZFS Community hält sich auf diese Art und Weise viele Probleme vom Hals, BTRFS sollte das meiner Meinung nach auch so lösen: BTRFS auf Raspberry Pi kannste machen, solltest dich bei Problemen aber nicht zu sehr wundern.

@Digi-Quick die RAID5/6-Implementierung von BTRFS hat ein Write-Hole Problem, die anderen RAID Modi nicht. ZFS hat das Parity-RAID Write-Hole Problem umgangen, indem dynamische Stripes eingesetzt werden. Bei BTRFS wird vermutlich wie bei mdadm ein Journal das Problem lösen. Es gab 2016/17 einen Patch, der es aber nicht Upstream geschafft hat.

 

[ludwinator]

Wenn ich mir die Liste hier https://www.spinics.net/lists/linux-btrfs/msg101483.html ansehe denke ich, das write hole Problem ist eher nachrangig.

Cu

 

[gea]

Write Hole ist ein Problem beim Schreiben bei dem ein einzelner Schreibvorgang der bei nur teilweiser Ausführung ein Problem verursacht (Absturz: Datenblock ist geändert, Metadaten nicht, eine Platte im Mirror hat den neuen Datenstand, die andere noch nicht, bei einem Raidstripe über 3 Platten wurde etwas auf zweien geschrieben auf der dritten noch nicht. Eine Gleichzeitigkeit beim Schreiben gibt es halt nicht, alles muss nacheinander passieren, entweder auf andere Bereiche der Platte oder nacheinander im Raid).

Das Problem führt normalerweise nicht zum Tod eines Dateisystems. Darin geht es ja hauptsächlich in dem Beitrag sondern meist nur zu einem Fehler in den Metadaten des Dateisystems oder der Raidstruktur. Ein fschk oder chkdsk ist dazu da, das zu bereinigen (mit einem eventuellen Datenverlust für betroffene Dateien). Journale oder stomare Schreibvorgänge sind Möglichkeiten das Abzusichern helfen aber oft nur bei den Userdaten insgesamt, nicht bei strukturellen Problemen auf Ebene eines Datenblocks.

Meist meint man aber strukuturelle Raid Probleme beim Raid Hole Problem und das ist unabhängig vom Raid Level. Ein btrfs/ReFS/ZFS Softwareraid kann mit Copy on Write und Prüfsummen auf den Einzelplatten des Raid dafür sorgen dass strukturelle Probleme nicht auftreten oder erkannt/repariert werden können. Wird das Raid von einem Hardwarraid oder einem Softwareraid bereitgestellt, dass Copy on Write und Prüfsummen auf den Einzelplatten beim Schreiben eines Datenblocks nicht bereitstellt, hat man erst das Problem. Ein Raid-5 auf ZFS ist genauso vom Raid Hole Problem betroffen wie btrfs. Oft entdeckt man strukturelle Raid Probleme erst bei einem Raid-Rebuild nach Plattenausfall.

Natürlich können viele Probleme durch Prüfsummen beim Lesen erkannt werden. Ein btrfs/ZFS auf hardwareraid/mdadm raid kann Fehler beim Lesen erkennen aber im Raid nicht reparieren da es keinen Zugriff auf die Einzelplatten hat (bis auf einfache Metadatenfehler, die gibts doppelt. Synology hebt diese Raparaturoption ja beim Einsatz von btrfs auf mdadm immer besonders hervor - in Ermangelung der Reparatur/Prüfoption auf Ebene der einzelnen Platten im Raid).

"Write hole" phenomenon in RAID5, RAID6, RAID1, and other arrays.

 

[Shutterfly]

Bzgl. BTRFS RAID5 fasst folgender Beitrag von einem der BTRFS Developer alles ganz gut zusammen: https://www.spinics.net/lists/linux-btrfs/msg101483.html. Ich empfehle den gesamten Beitrag zu lesen, da dort sehr wertvolle und aktuelle Informationen & Empfehlungen zu dem Thema zu finden sind.

Danke für den Link. Einiges davon habe ich schon an anderer Stelle angedeutet lesen dürfen. Nun schwarz auf weiß ganz hilfreich.

Was "replace" macht: es kopiert 1:1 die kaputte Festplatte. Wenn eine Datei nicht lesbar ist oder kaputte Checksummen liefert, wird es von den intakten Festplatten kopiert. Vorteil von dem ganzen ist, dass wir auch während des Austausches jederzeit die volle Ausfallsicherheit haben. Selbst wenn die kaputte Festplatte während des Vorgangs aussteigt, können die Daten immernoch von den anderen Festplatten gezogen werden. Nachteil: du brauchst einen zusätzlichen SATA-Port.

Da mein Mainboard acht Ports hat, wovon ich nur vier nutze, wäre das nicht das Problem. Was ich bei diesem Vorgehen besser bzw. interessanter fand: Es wird noch möglichst viel die alte Platte belastet und die übrig gebliebenen werden nur in Notfällen genutzt. Gerade ein Rebuild ist ja immer ein kritischer Punkt, wenn dort eine weitere Platte aussteigt bzw. die Chance aufgrund der Belastung hoch ist.

Du könntest aber auch ganz auf BTRFS RAID verzichten und nach wie vor SnapRAID dafür verwenden.

Wenn ich nun deinem Gedankenspiel folge, dann habe Btrfs auf jeder Platte, jedoch kein RAID o.ä. Könnte dort Snapshots z.B. nutzen, für Bit rots wäre dann SnapRAID notwendig. Im System würde dies dann aber kein gemeinsamer Mount-Point sondern vier getrennte. Oder meinst du per "mkfs.btrfs -d single /dev/sda /dev/sdb /dev/sbc" als Multi-Device-Filesystem?

Btrfs steckt im Vergleich dazu noch in den "Windeln". Ob es mal wirklich Reife erhält ist angesichts des Erfolgs von ZFS auf allen Plattformen noch nicht sicher.

Wenn es nicht so unflexibel im Heimgebrauch wäre. Das hatte Sun damals einfach nicht im Blick Mit OpenZFS 0.8.4 soll zumindest die Geschwindigkeit der nativen Verschlüsslung besser geworden sein, was bislang für mich immer ein Kritikpunkt an OpenZFS war. Es bleibt für mich jedoch diese fehlende Flexibilität bzgl. der Erweiterung/Vergrößerung des Speicherplatzes.

Könnte ich Geld kacken würde ich tatsächlich ein Stripe Mirror mit gröoßeren Platten machen, jedoch müsste ich dafür derzeit 4x4 TB Platten holen. Oder direkt RAID Z2 mit 6x4TB.

 

[Shutterfly]

Du könntest aber auch ganz auf BTRFS RAID verzichten und nach wie vor SnapRAID dafür verwenden.

Wenn ich nun deinem Gedankenspiel folge, dann habe Btrfs auf jeder Platte, jedoch kein RAID o.ä. Könnte dort Snapshots z.B. nutzen, für Bit rots wäre dann SnapRAID notwendig. Im System würde dies dann aber kein gemeinsamer Mount-Point sondern vier getrennte. Oder meinst du per "mkfs.btrfs -d single /dev/sda /dev/sdb /dev/sbc" als Multi-Device-Filesystem?

Ich habe mich hier noch einmal eingelesen und würde dich mal bzgl. folgender Konfiguration fragen:

Wenn ich alle vier Festplatten zu einem RAID1 für Data und Meta-Data konfiguriere, dann müsste ich doch eigentlich das erreichen, was ich möchte oder? Da ein RAID1 bei Btrfs dazu führt, dass ein Block auf genau zwei getrennten Geräten existiert, egal wie viele Festplatten genutzt werden, habe ich meine "SnapRAID-MergerFS"-Kombination.

Da dann auch die Meta-Daten in RAID1 vorliegen und so im Zweifelsfall on-the-fly Bit rots korrigiert und nicht nur gefunden werden können, sollte ich auch erhöhte Sicherheit erhalten.

Sollten mehr als eine Festplatte ausfallen, dann sind die dort enthaltenen Daten verloren, jedoch alle anderen Daten bleiben verfügbar, da keine Strides genutzt werden. Performance ist natürlich identisch (ggf. etwas schlechter) zu reinen ext4 Festplatten.

Somit müsste ich einen für mich praktikablen Zwischenweg zwischen der jetzigen Lösung ohne CoW und Snapshots und dem starren Gerüst ala ZFS gefunden haben.

Nachtrag: Kommando zurück, leider hab ich mich von dem "Block wird nur auf zwei Devices geschrieben" blenden lassen. Bei 4x2TB komme ich bei 4TB Platz raus. Was ja leider zu wenig ist. Würde somit um RAID5 also nicht drum herum kommen, wenn ich meinem Ansatz von oben folgen wollen würde.

 

[tolga9009]

Meine Vorstellung von SnapRAID ist, dass es vollkommen egal ist, welches Dateisystem sich drunter befindet. Ob nun ext4, XFS oder BTRFS - sogar gemischt. Konkret war meine Vorstellung, dass du jede Festplatte einzeln als BTRFS anlegst (mkfs.btrfs /dev/sda1, mkfs.btrfs /dev/sdb1,...) und dann wie bisher mit SnapRAID / MergerFS drüberfährst. Kenne mich mit SnapRAID leider nicht aus, sodass ich keine eigenen Erfahrungen teilen kann.

Nachdem ich aber ein wenig darüber recherchiert habe, denke ich, dass es doch keine so gute Idee ist: es scheint Probleme bzgl. BTRFS Snapshots zu geben. Die nehmen unter BTRFS keinen Speicherplatz in Anspruch; davon weiß SnapRAID aber nichts und kopiert dir die Daten in so einer Art und Weise rum, dass sie nun doch Speicherplatz in Anspruch nehmen. Dafür scheint es Lösungen zu geben, sieht aber nach viel Bastelei aus (und Schrott).

Bei 4x2TB komme ich bei 4TB Platz raus. Was ja leider zu wenig ist. Würde somit um RAID5 also nicht drum herum kommen, wenn ich meinem Ansatz von oben folgen wollen würde.

Ich denke du kennst dein System ja auch mittlerweile ziemlich gut - ob es zu Silent Bit Rot schonmal gekommen ist, ob du ständig Kernel Panics hast, Stromausfälle, Festplatten zufällig rausfliegen etc. Wenn die Hardware unproblematisch ist und du Backups hast, denke ich kannst du BTRFS RAID5 eine Chance geben (Metadaten RAID1, Daten RAID5, space_cache=v2). Vielleicht noch einige Worte dazu (hatte ich mal selber getestet vor ca. 1 Jahr):
- Performance mit 4 Festplatten war nahezu auf RAID0-Niveau - sowohl beim Lesen, als auch beim Schreiben.
- RAID5 Scrubs waren bei meinen Tests merklich langsamer als RAID1 - würde sagen ca. 50%. Je nach Gesamtgröße, kann das ein Problem darstellen. Workaround: Festplatten einzeln, nacheinander scrubben. Vielleicht wurde es auch schon gefixt; weiß ich leider nicht.
- Wenn du nach Stromausfällen / Kernel Panics scrubbst (ist eh nicht verkehrt), minimierst du die Folgen bzgl. des RAID5 Write-Holes

Außerdem: du kannst jederzeit hin- und herkonvertieren. Wenn du also deine Filmsammlung auslagerst und mehr Speicherplatz zur Verfügung hast, kannst du im laufenden Betrieb vom RAID5 wieder zurück auf RAID1. Es ist also keine Entscheidung von Leben und Tod.

Schau dir auch im BTRFS Calculator (https://carfax.org.uk/btrfs-usage/) an, wie du von zukünftigen Festplatten-Upgrades profitieren würdest. Z.B. wenn eine 2TB aussteigt und du diesen durch 8TB ersetzt (weil du die zu einem sehr guten Kurs gekriegt hast), könntest du nach RAID1 konvertieren und hättest nach wie vor 6TB nutzbaren Speicher. Wenn du eine weitere 2TB durch 8TB ersetzt oder schlicht dazukaufst, profitierst du wieder ordentlich vom RAID5, sodass hier wieder eine Konvertierung sinnvoll ist.

 

[Shutterfly]

Meine Vorstellung von SnapRAID ist, dass es vollkommen egal ist, welches Dateisystem sich drunter befindet. Ob nun ext4, XFS oder BTRFS - sogar gemischt. Konkret war meine Vorstellung, dass du jede Festplatte einzeln als BTRFS anlegst (mkfs.btrfs /dev/sda1, mkfs.btrfs /dev/sdb1,...) und dann wie bisher mit SnapRAID / MergerFS drüberfährst. Kenne mich mit SnapRAID leider nicht aus, sodass ich keine eigenen Erfahrungen teilen kann.

Ah okay, so hast du das gemeint. Wie du aber schon selbst gesagt hast, funktioniert das nicht in allen Fällen unproblematisch. Wenn ich Btrfs als reines FS ohne Snapshots verwenden würde, wäre das kein Problem, hätte jedoch auch nix gegenüber ext4 gewonnen, was wirklich von Erwähnung wäre.

Und wenn man darüber hinausgehen muss, benötigt man so etwas wie snapraid-btrfs und das treibt in meinen Augen die Komplexität nur unnötig in die Höhe. Eigentlich wollte ich die Situation ja auch etwas homogener gestalten und die vielen Software-Komponenten reduzieren

Ich denke du kennst dein System ja auch mittlerweile ziemlich gut - ob es zu Silent Bit Rot schonmal gekommen ist, ob du ständig Kernel Panics hast, Stromausfälle, Festplatten zufällig rausfliegen etc. Wenn die Hardware unproblematisch ist und du Backups hast, denke ich kannst du BTRFS RAID5 eine Chance geben

Also ich habe die Hardware nun inzwischen gut vier Jahre und würde sie als rock-solid bezeichnen. Trotz Arch Linux hatte ich noch nie eine Kernel Panic und Power loss gabs nur einmal wegen einer defekten Steckerleiste, wo die komplette Sicherung ausgelöst ist.

Von daher mache ich mir bzgl. Write hole echt keine Gedanken. Hatte aber eh mal überlegt, ob ich nicht irgendwann mal eine kleine USV besorge, wenn sie irgendwo im Sale ist. Das ist auf der Prio-Liste aber so weit unten, dass ich dann eher größere HDDs hole.

Den Calucator kenne ich bereits, danke. Damit hatte ich meinen Denkfehler bzgl. RAID1 auch entlarvt, da ein unerwartetes Ergebnis raus kam.

Aber gut, dann weiß ich, dass RAID5 nun meine einzig sinnvolle Option ist. Werde ich mal in einer VM als Experiment aufsetzen und etwas rum spielen

 

[NVMe1.4]

Leichenschändung:

Mir würde es genügen, wenn mir ein Dateisystem klar und zeitnah sagt, dass es einen Bitfehler in der Datei X oder in den Metadaten gibt. Wer keine Backupstrategie hat...

Das würde mir zum Beispiel ersparen, dass ich über ein schlechtes Betriebssystem fluche, weil ich die wirkliche Ursache beim Datenräger nicht erkennen kann.