Wie bereits angedeutet, ich habe keinen Plan wie dies bei BTRFS ist.
Bei ZFS und RAIDZ würde ich die parity penalty nicht ohne weiteres sehen.
Synology verwendet mdraid und darüber hinaus ein modifiziertes BTRFS-Dateisystem. Daher ist die Paritätsstrafe die gleiche wie bei mdraid, zuzüglich der BTRFS-eigenen Verzögerungen aufgrund von Funktionen wie erweiterten Metadaten und COW (naja, und einer Struktur, die nicht für Millionen kleiner Dateien geeignet ist, die auch in Ordnern organisiert sind, nicht so, wie BTRFS es mag: On the impact of two-level directory structure for storing blobs).
1 Like
Es handelt sich um ein RAID 5 System.
Vermute mal mit 4 disks?
Ich spreche jetzt hier nur von ZFS, aber wird bei BTRFS vermutlich gleich sein.
Edit: Nee, ist es nicht. Kannst dir den restlichen Text sparen 
Für meine Beispiele rechne ich mit dem Standard ashift=12 (entspricht 4k).
Ich rechne auch damit, dass die max recordsize auf 128k ist*.
Mit 4 disks rechnest du jetzt vermutlich mit einer nutzbaren Kapazität von 75% und Paritätskosten von 25%. Nur leider wird dies in der realen Welt nur selten zutreffen!
Nehmen wir mal an, du möchtest eine 4k Datei schreiben.
Block data ist Daten, die wir tatsächlich so schreiben wollen.
Parity data, sind Daten du uns nichts bringen, die wir aber schreiben müssen um eine Partität zu haben, damit uns eine beliebige Platte ausfallen kann und wir keinen Datenverlust haben.
Um jetzt also 4k speichern zu können schreiben wir einmal 4k block data und einmal 4k parity data.
4k ist das kleinstmögliche was unsere Platten schreiben können wegen ashift = 12.
Um also 4k zu speichern, müssen wir insgesamt 8k (block + parity) schreiben.
Unsere Effizienz ist 50%.
Entspricht damit mirror oder RAID1.
Im Idealfall, möchtest du 12k, 24k, 36k, 48k, 60k, 72k, 84k, 96k, 108k, 120k haben.
Fällt was auf? Ist immer Faktor 12. Warum?
Bei einem RAID5 über 4 Platten, haben wir 3 Daten disks und eine parity disk (so ganz grob betrachtet). Eine disk hat wegen ashift 12 den kleinstmöglichen 4k block, drei disks haben also einen 12k data als kleinstmöglichen block. Einzig und alleine Schreibvorgänge, die genau ein Faktor 12 sind, können wir sauber und schön mit bestmöglicher Effizienz schreiben! Wir schauen uns dies mal an einen perfekten Beispiel an.
Wir haben also Glück und es kommt ein 60k write daher**.
60k ist ein Mehrfaches von 12. Geht also perfekt!
60k kannst du verteilen auf 60k / 3 block data = 20 stripes.
Wir haben 20 stripes mit je 3 block data. Natürlich braucht jeder dieser 20 stripes auch noch 1 parity data.
Das geht perfekt! Wir schreiben 3 * 20 block data und 1 * 20 parity data.
3 * 20 + 1 * 20 = 80k
Wir schreiben insgesamt 80k um 60k zu speichern.
Unsere Effizienz ist 75%.
Leider ist es in der Realität selten so.
Kommt zum Beispiel ein 64k write daher.
64k kannst du verteilen auf 64k / 3 block data = 21.33 stripes.
Müssen wir aufrunden auf 22 stripes. Padding.
Wir schreiben 3 * 22 block data und 1 * 22 parity data.
3 * 22 + 1 * 22 = 88k
Wir schreiben 88k um 64k zu speichern.
Unsere Effizienz ist 72,73%.
Fällt was auf?
Wollen wir 64k anstelle von 60k zu speichern, wollen wir 4k mehr speichern.
Für 4k brauchen wir ja wie bereits im ersten Beispiel gesehen leider 8k.
Wir hätten also auch einfach die 80k vom zweiten Beispiel nehmen können und die 8k vom ersten Beispiel addieren können. Das hätte dann auch 88k schreiben um 64k speichern ergeben.
Kommt 1k write daher, ist es immer dumm, unabhängig ob mirror oder RAID.
Kleiner als 4k kannst du nicht schreiben. Bei beiden mirror und RAIDZ musst du 4k Daten schreiben und 4k parity data. Du schreibst also 8k um 1k zu speichern.
Unsere Effizienz ist 12,5%.
Wer das Thema spannend findet, aber kein Bock hat auf Kopfrechnen, hier eine Parity costs Tabelle:
Tabelle
Und hier ein guter Blog, der für Mirror argumentiert:
Blog
*einer der Hauptgründe, warum ich nix mit VM disks or iSCSI anfangen kann. Eine fixe blocksize ist sehr ineffizient für RAIDZ.
**nach Kompression! Kannst du halt nie wissen im Vorfeld, ausser du deaktivierst Kompression. Ist aber meistens auch nicht clever. Wir lassen es mal einfachheitshalber weg.
TLDR: RAID in ZFS bringt meistens nicht die gewünschte Storage Efficiency. Manche gehen sogar soweit und sagen, RAID ist ausser in Spezialfällen gegenüber Mirror nutzlos, da RAID folgende Nachteile aufweist:
- ein degraded pool wird extrem viel langsamer
- ein degraded pool braucht extrem viel länger zum resilvern
- mit den heutigen HDD Grössen und langsamen Schreibraten, ist es fast fahrlässig nur RAIDZ1 anstelle von RAIDZ2 zu verwenden. Das Risiko eines zweiten Ausfalls ist nicht unerheblich, während eines stressigen, Tage andauernden Resilverings. Dell rät bei schon seit bald einem Jahrzehnt zu RAID6, wegen der heutigen grossen HDDs. RAID5 ist nicht mehr supported
- Mirror lässt sich viel einfacher erweitern
TL;DR to the TL;DR – unless you are really freaking sure you know what you’re doing… use mirrors.
Um die Verwirrung komplett zu machen, was setzte denn ich ein? Bin ich ein Mirror Fanboy? Nope, nutzte selber beides. Mirror für VMs, RAIDZ2 für grosse Dateien.
Das ist das Schöne an der Lösung von Synology: Das Basis-mdraid hat eine Effizienz von 75 %, die Größe des minimalen BTRFS-Blocks spielt keine so große Rolle mehr (naja, außer dass es bei kleinen Dateien mehr Platz verschwendet und ohne Caching unglaublich langsam ist).
Wow, bin gerade ziemlich baff! War total verwundert, warum Synology sowas instabiles wie BTRFS RAID im Business Umfeld einsetzt. Du nutzen gar nicht die RAID Funktion von BTRFS? Die machen ein RAID mit mdraid und klatschen BTRFS drüber?
Extrem spannender Ansatz. Bin mir gerade am überlegen, welche Nachteile dies nach sich ziehen könnte. Neben Performance fällt mir aber nix ein. Danke @Alexey für deinen Input!
1 Like
Genau! Die Verwendung von BTRFS RAID ist, als würde man auf einem Fass Schießpulver sitzen und rauchen.
Der Hauptnachteil besteht darin, dass sie BTRFS modifizieren mussten, um auf Fehler zu reagieren und diese zu korrigieren, wenn sie gefunden werden.
Siehe auch:
1 Like
Habe jetzt seit ca 7 Tagen SSD Cache installiert. Seit gestern wächst mein Trash Speicher an. Mal sehen ob es daran lag und sich das System jetzt wieder stabilisiert. Zugriffszeit aufs Dashboard ist dadurch auch wesentlich schneller.
Das hängt (edit:) vieleicht zusammen, aber schalte mal den node aus warte 3min., und schaue in den temp ordner.
Wenn ich richtig gerechet hab ist die .partial datei zu alt (2.10.23 +26 tage = 28.11.23 also zu zeitpunkt des screenshot 2 wochen alt.), um noch was zu bringen.
Dann hast du jede menge .partial im temp ordner die nicht mehr benötigt werden.
Prüfe das mal gewissenhaft. .partial sind idr. ein paar minuten alt, und verschwinden dann aus dem Temp ordner. Der leer sein sollte wenn der node aus ist.
1 Like
Hab die Mode mal gestoppt und gewartet.
Da sind noch 229 Dateien drin, diese Belegen ca 151MB Speicher.
Die älteste ist von 2021 die neueste war bis zum Stopp von heute. Jetzt wird mir als neueste eine vom 04.12.23 angezeigt.
Kann man die alten einfach löschen?
Ja, alles was älter als 2 tage (gilt nur für den temp ordner) ist auf jeden fall, am besten den node dafür kurzzeitig wieder ausschalten, um nichts anderes versehentlich zu löschen.
so haben sich schon andere leute den node gekillt.
Ok, um wieviel GB?
Gut möglich das die filewalker und garbage collector jetz wieder funktionieren
1 Like
Hatte vorher ca 16GB im Trash Ordner, jetzt innerhalb 2 Tagen 2,1TB
1 Like
Perfekt, Garbage-collektion funktioniert wieder! Das war ja ungefähr die Differenz.
Frohe Festtage
1 Like