Von FreeBSD zu OpenBSD – softdep-Entfernung: Wirklich ein Problem?

Hmmm naja einen FreeBSD Kernel Entwickler zu fragen was er von einem Linux-Dateisystem hält ist schon ein bisschen so wie einen Boing Ingenieur zu fragen was er von Airbus-Flugzeugen hält - das wird nicht die ganz neutralste Antwort sein ;)

Es gibt bei jedem Dateisystem Unzulänglichkeiten. Zeitlebens wird man bei ZFS wohl auf Online-Defragmentierung verzichten müssen, genauso wie man btrfs wohl immer lieber auf RAID5 und RAID6 verzichten sollte.

Und wenn man das trotzdem als wichtig empfindet, sollte man auch All-In gehen und sowas wie ZFS nehmen anstatt jetzt da irgendwie zu grübeln ob OpenBSD-FFS und NetBSD-FFS besser ist.

Korrekt. Man nimmt einfach ein Betriebssystem, bei dem ZFS und/oder btrfs funktioniert. Dann kriegt man anhand der Prüfsummen wenigstens mit, dass etwas kaputt ist.

Bei UFS/FFS wird der defekte Ist-Zustand im Zweifelsfalle einfach heimlich, still und leise ab dem Augenblick mitgesichert. Nachdem man aber sowieso Backups hat, kann man ab dem Zeitpunkt jederzeit den defekten Zustand wiederherstellen. :ugly:
 
Kleiner Tip um etwas sicherer bei Stromausfall zu sein und ja, das ist dann langsamer: write cache deaktivieren. Wenns im ungünstigsten Fall passiert und nur eine Platte/SSD existiert, hilft auch das natürlich nicht. Eben kein allheilendes Mittel. :)
SAS/SCSI mit sg_utils bzw. sg3_utils
sdparm -s WCE=0 -S /dev/daX Kleines s für set, großes S für save. Geht in Einzelfällen auch mit SATA (manchmal auch nur ohne -S), das überlebt da aber keinen reboot, weil die Firmware des Laufwerks das meist sowieso blockt.
Im Umkehrschluß frißt/speichert das aber so gut wie jedes SAS-Laufwerk.

Mit smartmontools:
smartctl -s wcache,off /dev/sdX Auch hier die gleiche Problematik, dass die Firmware das Speichern blockt und es somit keinen reboot überlebt. Abhilfe dann via Startscript.
 
Bei UFS/FFS wird der defekte Ist-Zustand im Zweifelsfalle einfach heimlich, still und leise ab dem Augenblick mitgesichert.
Selbstredend muss man bei einem solchen Zwischenfall (z.B. Stromausfall) dann halt ggf. mit dem Backup abgleichen.
Aber ja. Das grundsätzliche Problem existiert und wurde hier im Thread ja auch schon adressiert.

Wobei ich das jetzt auch nicht so schlimm finde. Erstens setzen sich SSDs immer mehr durch und da hat Fragmentierung einen nicht ganz so großen Impact. Und zweitens gibts sammelt sich meiner Erfahrung nach i.d.R. sowieso nicht so viel Fragmentierung an, solange man darauf achtet das die Pools nicht zu voll werden.

Also wenn ich bei meinen Nicht-SSD-Pools mal kurz mit zfs list drauf gucke, wird da eine Fragmentierungsrate von 3% angezeigt. Und der ist schon 5 Jahre alt (oder sogar älter) und hat ein Füllstand von ca. .
Ich würde sagen: Kann man mit leben. :-)
 
Wobei ich das jetzt auch nicht so schlimm finde. Erstens setzen sich SSDs immer mehr durch und da hat Fragmentierung einen nicht ganz so großen Impact. Und zweitens gibts sammelt sich meiner Erfahrung nach i.d.R. sowieso nicht so viel Fragmentierung an, solange man darauf achtet das die Pools nicht zu voll werden.

Also wenn ich bei meinen Nicht-SSD-Pools mal kurz mit zfs list drauf gucke, wird da eine Fragmentierungsrate von 3% angezeigt. Und der ist schon 5 Jahre alt (oder sogar älter) und hat ein Füllstand von ca. .
Ich würde sagen: Kann man mit leben. :-)

Naja, auf großen Storagepools hat man schon noch rotierende Datenträger. Aber was gesagt sei: Defrag unter BTRFS ist auch mit Vorsicht zu genießen. Die Autodefragmentation Mountoption, die beim Schreiben (bzw. überschreiben) automatisch defragmentiert ist relativ save, aber der manuelle Defrag kann, bzw. wird Daten dededuplizieren (nein, kein "de" zu viel).
Was ich ja an ZFS im Vergleich zu BTRFS am meisten vermisse, ist das out-of-band Deduplicate. Das spart mir regelmäßig Hunderte GB an Speicherplatz.
 
Also wenn ich bei meinen Nicht-SSD-Pools mal kurz mit zfs list drauf gucke, wird da eine Fragmentierungsrate von 3% angezeigt.
18% hier, 7200er Derwische, 2020-02 angelegt und immer bei ~90% Füllstand. Wenn man genügend vdevs hat, tut das wirklich nicht weh. Bei ner Einzelplatte aber schon.
 
Code:
NAME   SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
data  10.9T  7.80T  3.11T     185M         -     8%    71%  1.00x    ONLINE  -

5 Jahre alter Pool, immer zwischen 50% und 80% Füllstand. Lässt sich aushalten.
 
Naja, auf großen Storagepools hat man schon noch rotierende Datenträger.
Das stimmt zwar. Aber auf lange Sicht wird das halt weniger. Und das wird sicher ein Aspekt sein bei der Überlegung, ob man den Aufwand einer Implementierung überhaupt treiben sollte.

Was ich ja an ZFS im Vergleich zu BTRFS am meisten vermisse, ist das out-of-band Deduplicate.
out-of-band Deduplicate klingt interessant, wobei mir immer noch nicht ganz klar ist, warum das mehr Speicherplatz sparen soll als das "in-Band"-Deduplicate.

Das spart mir regelmäßig Hunderte GB an Speicherplatz
Das ist eine Menge.
Aber kommt sicherlich auch immer darauf an, was man macht.
 
out-of-band Deduplicate klingt interessant, wobei mir immer noch nicht ganz klar ist, warum das mehr Speicherplatz sparen soll als das "in-Band"-Deduplicate.

Tut es nicht, aber anstatt bei zB einem 8TB Pool permanent 10-15 GB an RAM belegt zu haben wie bei ZFS, habe ich einmal oder zweimal im Jahr ein Wartungsfenster am Wochenende wo die Deduplication läuft und ansonsten hat es keinen Einfluss auf das System.
 
Ihr seid natürlich Profis und das merkt man auch in den letzten Beiträgen.
Für Profis spielen manchmal ja kleine Unterschiede in der Performance eine große Rolle.
Wenn ich mich aber frage, nur mal so als konstruiertes Beispiel, warum denn mein 10 Jahre alter 500€ Server nicht an die Leistung von Netflix und Co herankommt, spielt die Performance des Dateisystems sicher nicht "die" große Rolle.

Die Beiträge sind trotzdem für mich sehr interessant zu lesen und auch die Einschätzungen von Profis bekommt man ja ansonsten nicht so frei Haus geliefert. Lasst uns aber mal einfach auf die Bedürfnisse eines Heimanwenders beschränken und dann vielleicht noch voraussetzen, dass er ein neues Projekt auch mit neuer HW und ausreichend RAM beginnen möchte: glaubt ihr ernsthaft dass man da einen Performance-Unterschied spüren kann, der von der Wahl des Dateisystems herkommt?

ZFS habe ich auch auf meinem alten Dateiserver, weil es einfach cool mit der Frage der Redundanz umgeht. Ich brauche mir quasi keine großen Gedanken zu machen (wie früher), welches RAID und wohin die Platten zu verteilen sind, sondern ich nehme einfach ZFS, entscheide, wieviel Redundanz ich brauche oder will und den Rest macht mir das Dateisystem und ich bin nicht von irgendwelcher HW abhängig (RAID-Controller und co).
Ob da nun BTRFS etwas schneller wäre? Spielt bei mir keine Rolle.

Ich benutze ZFS aber nicht, weil ich glaube, damit keine Daten verlieren zu können!
Bei mir gibt es häufig Stromausfall, verglichen mit DE. Normalerweise hängt deshalb an allen PCs eine USV, aber am File-Server sind die Batterien schlecht und ich hatte noch keinen Bock, das zu ändern. Der Fileserver bootet von USB-Stick mit UFS(2), ein Klon des Sticks liegt bereit, die Daten liegen auf einem inzwischen veralteten ZFS-Pool. Aber alle wichtigen Daten (und Musik oder Filme gehören nicht dazu) liegen auch noch zusätzlich auf anderen Medien.
Und das hat sich in der Vergangenheit gut bewährt, denn einige Filme habe ich durchaus schon verloren, weil mal etwas schief gegangen ist.
Profis können mit solchen Verlausten nicht leben! Ich kann das schon und es macht mir auch keine Probleme, wenn ich mal ein paar Sekunden auf den Server warten muss (was ich real aber nicht wirklich muss).

Nach den Beiträgen hier, vor Allem der Erklärung von @Yamagi zur Lage der BSD-Dateisysteme, halte ich die Eingangsfrage eigentlich für beantwortet. Für ausreichend beantwortet.
Ich leite daraus folgende Empfehlung ab: den Server bauen und testen, mehrmals Stecker ziehen und sehen, ob er danach wieder kommt und dann wieder bauen, mit neuen Einstellungen zum Dateisystem, wieder testen und sehen und schließlich Erfahrung sammeln und nachher auch berichten.
Jedenfalls habe ich das vor meiner Entscheidung für ZFS so gemacht. Echter Stress-Test unter meinen eigenen Bedingungen und Anforderungen.
 
Man kann Datensicherheit auch nachrüsten. Snapraid läuft auf so ziemlich jedem System und baut einem auch bei unterschiedlichen Plattengrößen Datemsicherheit ein. Ist kein Backup, aber eine einfache und sichere Variante. Ich habe damit nur positive Erfahrungen gemacht. Besonders nett fand ich auch, dass man den Scrub immer nur auf einen Teil der Daten machen kann, also einmal pro Woche 5% oder so etwas.
 
Lasst uns aber mal einfach auf die Bedürfnisse eines Heimanwenders beschränken und dann vielleicht noch voraussetzen, dass er ein neues Projekt auch mit neuer HW und ausreichend RAM beginnen möchte: glaubt ihr ernsthaft dass man da einen Performance-Unterschied spüren kann, der von der Wahl des Dateisystems herkommt?

Kann er nicht. Die Unterschiede zwischen den Dateisystemen sind (von speziellen Szenarien und synthetischen Benchmarks mal abgesehen) weit unterhalb der Wahrnehmungsgrenze.

Ob da nun BTRFS etwas schneller wäre? Spielt bei mir keine Rolle.

Tatsächlich ist der Performance-Unterschied zwischen ZFS und btrfs in der Praxis völlig vernachlässigbar.

Unter FreeBSD stellt sich die Frage eh nicht, welches Dateisystem man nimmt.

Unter Linux ist in der Praxis nur die Frage, ob für den eigenen Anwendungsfall die Vorteile von ZFS (u.a. RAID-Z) die Nachteile (u.a. out-of-tree des Kernels) überwiegen.

Man kann Datensicherheit auch nachrüsten. Snapraid läuft auf so ziemlich jedem System und baut einem auch bei unterschiedlichen Plattengrößen Datemsicherheit ein. Ist kein Backup, aber eine einfache und sichere Variante.

Das ist in der Tat für völlig statische Daten eine recht gute wenngleich manuelle Lösung. Durch die asynchrone Natur gibt es aber leider bei dynamischen Daten hässliche Fehlerszenarien, die man mit ZFS oder btrfs nicht hat.
 
Ich hatte mal ein Setup, bei dem ich ZFS ohne RAID benutzte und snapraid dann die Ausfallsicherheit übernahm. Wenn mann dann einen Snapshot vor dem Rebuild macht, dann hat man einen garantierten Datenstand. Der Grund für dieses Setup war, dass ich die Ausfallsicherheit über unterschiedlich große Platten herstellen wollte.
Zum Sichern eines Jails eignet sich Snapraid in der Tat nicht. Schon alleine, weil man die Berechtigungen der Daten verliert. Aber für die Musik- und Videosammlung ist das großartig. Auch, weil nur die Platten anfahren, die man wirklich braucht.

Jetzt habe ich auf die Ausfallsicherheit verzichtet und speicher alles auf einer riesigen Platte. Dafür gibt es dann regelmäßig ein Backup. :)
 
Der Grund für dieses Setup war, dass ich die Ausfallsicherheit über unterschiedlich große Platten herstellen wollte.
:)

Das wäre zB ein Punkt für BTRFS, da kannst du auch zB Raid1 auf 2x 1TB + 1x 2TB Platten fahren. Wenns rechnerisch möglich ist, geht es da - und lässt sich live konvertieren und erweitern, wenn du Platten hinzufügst. Finde ich eine der Stärken im Privatbereich.
 
Das ist schon nicht schlecht. Bei Snapraid finde ich halt praktisch, dass nur die größte Platte als Parity verschwindet (oder die größten 2,3,etc.). Und dir Platten sind im System nicht als Raid sichtbar. Das hat Vor- und Nachteile. Man muss seine Daten aufteilen, aber dafür fährt auch nur eine hoch, wenn man auf eine Datei zugreift. Für das Kombinieren von mehreren Platten zu einem Filesystem gibt es dann Metafilesysteme. Die habe ich aber nicht gebraucht.
 
Das wäre zB ein Punkt für BTRFS, da kannst du auch zB Raid1 auf 2x 1TB + 1x 2TB Platten fahren. Wenns rechnerisch möglich ist, geht es da - und lässt sich live konvertieren und erweitern, wenn du Platten hinzufügst. Finde ich eine der Stärken im Privatbereich.
Wird jetzt alles ein bisschen OT hier, aber das geht doch auch mit ZFS? Einfach auf der 2TB Platte zwei 1TB Partitionen machen und die jeweils mirrorn mit einer 1TB-Platte...?
 
Wird jetzt alles ein bisschen OT hier, aber das geht doch auch mit ZFS? Einfach auf der 2TB Platte zwei 1TB Partitionen machen und die jeweils mirrorn mit einer 1TB-Platte...?

Das geht prinzipiell. Fügst du aber später beispielsweise noch zusätzlich eine 4-TB-Platte hinzu, wird die Erweiterung mit btrfs trivial und mit ZFS spannend. Vor allem, wenn du nicht den kompletten Pool neu aufsetzen möchtest (z.B. weil dein Backup offsite ist).

Kommt später noch eine 8-TB-Platte hinzu, brauchst du schon mehrere Mirrors in deinem Pool. :ugly:
 
Wird jetzt alles ein bisschen OT hier, aber das geht doch auch mit ZFS? Einfach auf der 2TB Platte zwei 1TB Partitionen machen und die jeweils mirrorn mit einer 1TB-Platte...?
das kannst du auch einfacher haben, siehe zfsprops(7)
copies=1|2|3
Controls the number of copies of data stored for this dataset. These copies are in addition to any redundancy provided by the pool, for
example, mirroring or RAID-Z. The copies are stored on different disks, if possible. The space used by multiple copies is charged to the associated file and dataset, changing the used property and counting against quotas and reservations.
 
Das die Daten nach Möglichkeit auf unterschiedliche Platten verteilt werden hatte ich ganz überlesen. Dann ist das ja zumindest schon einmal ein gutes "Mirroring" Feature.
 
Das die Daten nach Möglichkeit auf unterschiedliche Platten verteilt werden hatte ich ganz überlesen. Dann ist das ja zumindest schon einmal ein gutes "Mirroring" Feature.

Mit ZFS und copies=2 ist - im Gegensatz zu btrfs - kein Rebalancing möglich. Will man eine zusätzliche Platte nutzen, müssen sämtliche Daten manuell neu geschrieben werden.

Nutzt man features wie Snapshots, läuft es wohl auf ein zfs send | zfs recv auf ein externes Medium hinaus - also genau das, was man nicht haben möchte.
 
Nutzt man features wie Snapshots, läuft es wohl auf ein zfs send | zfs recv auf ein externes Medium hinaus - also genau das, was man nicht haben möchte.
das ist wirklich etwas, das ich nachteilig an ZFS empfinde. Wenn du einen GROSSEN Pool hast, kann es womöglich kein externes Medium geben, wohin du sichern kannst oder du brauchst eventuell mehrere, falls du entsprechende Datasets hast.
Alternativ geht natürlich auch ein Ziel im Netz, also eventuell dann gleich ein neuer Rechner mit mehr Speicher etc.
Da ist dann, wenn ich das richtig verstanden habe, zfs send | zfs recv womöglich gar nicht so gut, wenn ich dem neuen Pool (bzw Dataset) auch neue Eigenschaften geben möchte. Zumindest habe ich selbst in solch einem Fall dann mit rsync gearbeitet, um die alten Daten in den neuen Pool zu bringen.

Mein Bauchgefühl spricht dennoch eher für ZFS als für BTRFS. Das kann daran liegen, dass ich mich in BTRFS etwas verloren und hilflos fühle. ZFS wird einem an mancher Stelle gut erklärt und mit Beispielen nicht gegeizt. Es kann ja fast immer auch die Dokumentation von oracle, also Solaris genommen werden.
 
Mit ZFS und copies=2 ist - im Gegensatz zu btrfs - kein Rebalancing möglich. Will man eine zusätzliche Platte nutzen, müssen sämtliche Daten manuell neu geschrieben werden.

Nutzt man features wie Snapshots, läuft es wohl auf ein zfs send | zfs recv auf ein externes Medium hinaus - also genau das, was man nicht haben möchte.

Dazu kommt, dass dir ZFS diese Eigenschaft nicht garantiert. Du merkst also garnicht, wenn deine Copies 2x auf dem selben Medium liegen.
 
Zurück
Oben