ZFS vs Btrfs

[Saykel]

Hallo zusammen,

ich betreibe nun seit knapp einem halben Jahr meinen Homeserver mit Proxmox und ZFS. Funktioniert auch perfekt, der Speicherplatz wird nur langsam etwas knapp...
Mir war bei der Planung bewusst, dass ein erweitern des ZFS-Pools nicht so einfach möglich ist. Da ich meine Daten gerne gespiegelt habe möchte und aktuell zwei Platten einsetze, würde ich 2 weitere benötigen um ein weiteres vdev zum Pool hinzuzufügen. Zum Zeitpunkt der Planung wäre dies kein Problem gewesen. Nun hat sich aber die Familiensituation ein wenig geändert, so dass das Geld nicht mehr so locker sitzt und ich mir einfach keine zwei Platten leisten kann

Beruflich komme ich häufiger mit GPFS/Spectrum Scale in Kontakt. Das hat das wunderbare Feature, dass Platten egal welcher Größe in den Pool geschmissen werden können. Ich gebe nur an, dass ich die Daten gespiegelt haben möchte und GPFS stellt sicher, dass die Daten auf mindestens zwei Platten liegen. Dieses Feature fehlt mir bei ZFS. Daher habe ich mich auf die Suche nach etwas ähnlichem gemacht und bin bei btrfs gelandet.

Verstehe ich die Beschreibungen richtig, so kann btrfs genau dieses Verhalten abbilden. Also ich könnte eine neue Platte in den Homeserver einbauen, dort ein btrfs Volume anlegen, die Daten rüber kopieren, anschließend den ZFS Pool auflösen, die Platten mit in den btrfs "Pool" hängen und die Spiegelung aktivieren (nennt sich wohl Raid-1 auch wenn es kein klassisches Raid-1 ist) aktivieren.

Nun aber zu der eigentlichen Frage: Hat jemand btrfs im Einsatz und kann dazu einen Erfahrungsbericht abgeben? Im Internet finde ich alle möglichen Aussagen von "Auf gar keinen Fall für Produktion einsetzen, nur zum spielen" bis hin zu Aussagen von Suse, die meinen das FS wäre bereit für den produktiven Einsatz.
Verwendet wird es als Datengrab und Speicher für den Mediaserver. Die Inhalte ändern sich also eigentlich kaum, es werden nur immer mehr

Ich bin für jede Erfahrung dankbar. Auch Rückmeldung von Personen die vor einer ähnlichen Frage standen mit der Entscheidung und deren Begründung wären äußerst willkommen.

Vielen Dank im Voraus!
Saykel

 

[rayze]

Wenn du auf eine Echtzeitspiegelung verzichten kannst schmeiße ich mal Snapraid+Aufs in die Runde. So betreibe ich das ganze seit über 2 Jahren. Jede Festplatte ist für sich erstmal autark, daher: Jede Festplatte kann mit einem Beliebigen Dateisystem formatiert sein. Um das ganze nun in einem Share zur Verfügung zu haben nutze ich AUFS. Bei diesem kann man einstellen wie Daten verteil werden sollen.

Folgende Modi gibt es

create=tdp | top−down−parent
Selects the highest writable branch where the parent dir exists. If the parent dir does not exist on a writable branch, then the internal copyup will happen. The policy for this copyup is always ’bottom-up.’ This is the default policy.
create=rr | round−robin
Selects a writable branch in round robin. When you have two writable branches and creates 10 new files, 5 files will be created for each branch. mkdir(2) systemcall is an exception. When you create 10 new directories, all are created on the same branch.
create=mfs[:second] | most−free−space[:second]
Selects a writable branch which has most free space. In order to keep the performance, you can specify the duration (’second’) which makes aufs hold the index of last selected writable branch until the specified seconds expires. The seconds is upto 3600 seconds. The first time you create something in aufs after the specified seconds expired, aufs checks the amount of free space of all writable branches by internal statfs call and the held branch index will be updated. The default value is 30 seconds.
create=mfsrr:low[:second]
Selects a writable branch in most-free-space mode first, and then round-robin mode. If the selected branch has less free space than the specified value ’low’ in bytes, then aufs re-tries in round-robin mode. Try an arithmetic expansion of shell which is defined by POSIX. For example, $((10 * 1024 * 1024)) for 10M. You can also specify the duration (’second’) which is equivalent to the ’mfs’ mode.
create=pmfs[:second]
Selects a writable branch where the parent dir exists, such as tdp mode. When the parent dir exists on multiple writable branches, aufs selects the one which has most free space, such as mfs mode.

Um den Ausfall einer Platte abzufedern und Daten Wiederherzustellen ist Snapraid da. Dies lass ich 1x Täglich laufen. Beim Ausfall einer Platte ist das System zwar erstmal Down (zumindest die Daten der einen Platte), lassen sich mit Snapraid aber Rebuilden. Der Vorteil bei diesem Setup ist das du einfach beliebige Platten beliebiger größere hinzufügen kannst. Wichtig: Die Parity-Festplatte muss mindestens genauso groß sein wie die größte Platte im Verbund.

 

[ludwinator]

Bevor du aus Kostengründen das Dateisystem wechselst poste mal lieber was du hast und was du willst.
Welche Features von ZFS benutzt du aktiv, also Kompression, Dedup, Snapshots, send/receive, SMB, NFS, iSCSI etc.
Dann kann dir jemand auch ne praktikable Empfehlung machen, evtl. auch eine die nix kostet.

cu

 

[the_pi_man]

Die Platten einzeln gegen größere tauschen und die kleineren verkaufen? Wäre das eine Möglichkeit für dich?
Das (zu schnelle) Wachsen auf dem Mediaserver kenne ich nur zu gut. Siehe in meine Systeminfo unter NAS.

 

[Saykel]

Hallo zusammen,

erst mal danke für die Antworten.
Von ZFS nutze ich aktuell die Kompression, Snapshots, SMB und NFS.

Zur aktuellen Situation: Ich betreibe auf dem Server Proxmox. In dieses Debian sind alle Platten eingebunden. Für Proxmox und die VMs/Container läuft eine SSD. Zusätzlich laufen 2 2TB WD Red in einem ZFS Pool als Datengrab. Dieser Pool stellt unter anderem die Quelle für meinen Plex-Server dar (per bind mount in den entsprechenden Container eingebunden). Der Pool wird außerdem via NFS an meinen Linux Client und via SMB an die restlichen Windows Maschinen verteilt. NFS und SMB muss nun nicht über das FS laufen. Das würde das Debian ja auch so hinbekommen.
Ich habe mir noch ein Skript geschrieben, dass regelmäßig Snapshots von den interessanten Bereichen des Pools macht.

Aktuell habe ich also einen Pool mit 2 TB Kapazität. Da die Sammlung stätig wächst und ich nicht in der letzten Sekunde reagieren möchte, bin ich nun auf der Suche nach einem Weg den verfügbaren Plattenplatz zu erweitern. Nun jedes Mal wenn es eng wird gleich zwei neue Platten hinzufügen ist ein wenig schwierig geworden
Daher suche ich nach einem Konstrukt, bei dem ich bei Bedarf eine weitere Platte hinzufüge (egal welcher Größe, da P/L sich im Laufe der Zeit ja deutlich ändert) und die Daten auf allen Platten so verteilt werden, dass alles zwei mal vorhanden ist.

Vor der "Arbeit" des Konfigurieren und kopieren der Daten habe ich keine Angst. Das betrachte ich mit als Hobby und beschäftige mich auch gerne mal mit etwas neuem. Und lese ich mir die verschiedenen Artikel durch, die sich so im Netz finden, so gibt es ja durchaus einige Parallelen zwischen ZFS und Btrfs.

Bei der Variante Aufs+Snapraid sind mir ehrlich gesagt zu viele Komponenten im Spiel. Das sind viele Punkte an denen etwas schief gehen kann und viele Komponenten die mit unterschiedlichen Kommandos gesteuert werden müssen. Wenn der Server läuft, bin ich ja nicht täglich am Basteln. Daher fange ich jedes Mal wieder von vorne an, wenn ich eine Änderung machen will und da empfinde ich es deutlich angenehmer, wenn ich mich lediglich mit einem Code auseinander setzen muss (z.B. ZFS oder Btrfs).

Die Platten verkaufen wäre theoretisch eine Alternative. Ohne jetzt nachgeschaut zu haben, befürchte ich jedoch, dass ich für 2 TB Platten, die bereits einige Jahre auf dem Buckel haben, nicht mehr viel bekomme und dadurch am Ende drauf zahle.

 

[fax668]

Nun aber zu der eigentlichen Frage: Hat jemand btrfs im Einsatz und kann dazu einen Erfahrungsbericht abgeben? Im Internet finde ich alle möglichen Aussagen von "Auf gar keinen Fall für Produktion einsetzen, nur zum spielen" bis hin zu Aussagen von Suse, die meinen das FS wäre bereit für den produktiven Einsatz.

Ich sag mal so: Seit ReiserFS Anfang des Jahrtausends hat bei mir nichts so viele Daten vernichtet wie btrfs vor zwei Jahren - mehrmals. Und ich habe keinerlei exotische Features genutzt. Mir kommt das nicht mehr auf die Platte bevor das nicht noch ein paar Jahre gereift ist.

 

[Tornhoof]

Produktiv hatte ichs nicht im Einsatz, einer unserer Testserver (Kernel 4.2, ESXi VM) hatte es mal drauf um es zu evaluieren, der lief primär als Samba Backup Fileserver mit bischen nächtliches Backup zum Lasterzeugen, in 6 Monaten hatte einmal btrfs-scrub einen Fehler in einer Nutzdatei angezeigt, danach nimmer. Experiment eingestellt und btrfs sein gelassen. Aber keine größere Analyse gestartet was da schief gelaufen ist.

 

[ludwinator]

Ich würde einfach eine weitere Red 2TB dazustecken und auf ein RaidZ1 migrieren. Siehe https://blogs.oracle.com/zhangfan/entry/how_to_turn_a_mirror
Schon mehrmals gemacht, funzt bestens.
Platz verdoppelt und Redundanz weiter vorhanden, Investition einer Tankfüllung.

cu

 

[Digi-Quick]

Dauert halt länger als eine einfache Raidlevelmigration / die Daten sind länger ohne Redundanz.
Die Redundaz wird aufgelöst, wenn eine HDD aus dem Mirrorset entfernt wird und ist erst nach dem resilvern des Raidz1 wiederhergestellt.

Wie war doch gleich die Standardempfehlung vor solchen Operationen? *Grübel*
"Nie ohne Backup" *scnr*

 

[yarofbi]

Mir kommt das nicht mehr auf die Platte bevor das nicht noch ein paar Jahre gereift ist.

 

[smutbert]

Ich verwende btrfs schon recht lange. Am Anfang gab es noch Probleme, zB mit Festplattenimages von virtuellen Maschinen, da habe ich es aber auch nur aus Interesse ausprobiert.

Seit geraumer Zeit verwende ich es aber im Normalbetrieb und es läuft problemlos. Ich verwende es auf meinem Laptop auf einer SSD, auf meinem normalen PC auf zwei SSDs und auf einem alten Computer, den ich mit vier hdds im btrfs-eigenen raid1 als NAS zum Speichern der Backups verwende missbrauche.
Das letztere System läuft nur, wenn ich das Backup aktualisiere, dafür lege ich jedes Mal vom vorigen Backup einen read-only Snapshot an, dh dort hat sich schon eine beachtliche Zahl an Subvolumes angesammelt (von vornherein je eines für meine alltäglichen Daten, eines für Konfigurationsdateien, eines für das System selbst,… und dann jeweils eine Menge Snapshots von jedem dieser subvolumes).

 

[Saykel]

Ich würde einfach eine weitere Red 2TB dazustecken und auf ein RaidZ1 migrieren. Siehe https://blogs.oracle.com/zhangfan/entry/how_to_turn_a_mirror
Schon mehrmals gemacht, funzt bestens.
Platz verdoppelt und Redundanz weiter vorhanden, Investition einer Tankfüllung.

cu

Die Variante ist natürlich interessant. Ein Backup der Daten ist natürlich empfehlenswert. Das sollte ja aber sowieso vorhanden sein
So muss ich dann das Filesystem nicht ändern und btrfs hätte noch ein bisschen Zeit für die Weiterentwicklung.
Das lasse ich mir auf jeden Fall durch den Kopf gehen. Danke für den Hinweis!