mergerfs beste policy etc (mit snapraid)

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • mergerfs beste policy etc (mit snapraid)

      Hi zusammen,

      ich wollte mir mal mergerfs + snapraid näher ansehen. Dazu sind mir einige grundlegende Fragen gekommen, auf die ich hier so nicht direkt die Antworten gefunden hatte:

      - welches ist die "beste" Policy für das Speichern von Dateien (meister/wenigster Speicherplatz, exist. Pfad, etc.) bzw was sind die Vor/Nachteile? Meine ich hätte wo etwas gelesen, dass es auch Auswirkungen auf die Synchronisation hat. Ein anderer Gedanke war, evtl. das Risiko zu streuen, wenn nicht alles auf einer HDD liegt (wobei das ja die Parity auch sicherstellen sollte). Evtl. Geschwindigkeit lesen/schreiben von mehreren HDDs vs. laufen ggf. auch mehere HDDs statt nur eine.

      - ihr scheibt ja, dass man entgegen der Anleitung nicht direkt das root einbinden soll, sondern einen Ordner anlegen. a) was genau ist der Grund und b) kann Jemand die Schritte genauer beschreiben? (zB sollen/müssen die obersten Ordner dann je HDD gleich lauten oder dürfen sie genau das nicht)?

      - wie macht ihr es mit der Synchronisation? Autom, von Hand, chronjob o.ä.?
    • mergerfs nicht direkt im root der Festplatte, sondern in einen Unterordner deshalb:
      • snapraid schreibt im root directory jeder Platte eine Datei (die solltest du nicht sehen im Pool)
      • mit mergerfs merkst du eh nicht, dass alles in einem Subdirectory liegt, sondern siehst nur das Pool
      • du kannst auf einer Platte mehrere mergerfs Pools anlegen
      die Ordner würde ich alle gleich nennen, am besten wie den Pool dann.

      ich synchoniziere SnapRAID händisch, nachdem ich neue Mediendateien auf mein Pool gespielt habe.
      immer beachten: mergerfs => pool, snapraid => Datensicherheit, und dann gibt es noch das Backup...
      SW: OMV 4.1.22 (Arrakis), Snapraid mit mergerfs, Minidlna
      MSI B150M ECO, Intel Pentium G4400, 16GB Kingston DDR4, SSD 250GB, 4TB Daten, 3*8TB+6TB SnapRaid (8TB Parity,3+3+2TB Parity2), FSP Aurum S 400W, Fractal Node 804
    • wtuppa schrieb:

      mergerfs nicht direkt im root der Festplatte, sondern in einen Unterordner deshalb:
      • snapraid schreibt im root directory jeder Platte eine Datei (die solltest du nicht sehen im Pool)
      • mit mergerfs merkst du eh nicht, dass alles in einem Subdirectory liegt, sondern siehst nur das Pool
      • du kannst auf einer Platte mehrere mergerfs Pools anlegen
      die Ordner würde ich alle gleich nennen, am besten wie den Pool dann.

      ich synchoniziere SnapRAID händisch, nachdem ich neue Mediendateien auf mein Pool gespielt habe.
      immer beachten: mergerfs => pool, snapraid => Datensicherheit, und dann gibt es noch das Backup...
      und wie (das mit den Ordnern)? Mergerfs zeigt mir bei "add file system" nur Festplatten an, keine Ordner.
      Was wäre ggf. der Anwendungsfall für mehrere Pools?

      Wie verteilst du denn die Dateien auf die HDDs? Eine nach der anderen füllen, alle gleichmässig, ...?
    • du hast recht, über die GUI kann man nur ganze Platten dazufügen, mit command line kann man auch direkt subdirs mounten.
      trotzdem würde ich auf jeder Platte das Pool directory anlegen und alle Daten unter diesem anlegen. ist einfach sauberer.

      ich verwende "Vorhandener Pfad, meister freier Speicherplatz.", wobei ich 50G (auch wegen SnapRAID parity) frei lasse.
      vorhandener Pfad deshalb, weil ich doch auch eine gewisse Sortierung auf die Platten habe.
      SW: OMV 4.1.22 (Arrakis), Snapraid mit mergerfs, Minidlna
      MSI B150M ECO, Intel Pentium G4400, 16GB Kingston DDR4, SSD 250GB, 4TB Daten, 3*8TB+6TB SnapRaid (8TB Parity,3+3+2TB Parity2), FSP Aurum S 400W, Fractal Node 804
    • Re,

      wtuppa schrieb:

      du hast recht, über die GUI kann man nur ganze Platten dazufügen, mit command line kann man auch direkt subdirs mounten.
      trotzdem würde ich auf jeder Platte das Pool directory anlegen und alle Daten unter diesem anlegen. ist einfach sauberer.
      Logischerweise - da mergerfs (UnionFS) ein Speichsubsystem abbildet, sprich unter dem Filelayer drunter liegt ... und zwar korrekterweise zw. Filelayer und Filesystem-Layer ... daher ist die Logik: einen Pool bildet man aus Membern, und darauf legt man dann das (oder die) entsprechende Pool-Verzeichniss(e) an.

      Ich habe meinen MEDiATH0R mit SnapRAID/mergerfs nur über die GUI konfiguriert - inkl. eines Unterverzeichnisses ... denn das Unterverzeichnis gibt man nicht mergerfs (UnionFS) oder SnapRAID an, sondern man legt es unter "freigegebene Ordner" auf dem Pool an ... und so verfährt man auch mit evtl. weiteren "Pools" (man darf das nicht mit dem Speichersubsystem verwechseln!).

      Also Pool unter "UnionFS" aus allen Datenplatten anlegen (inkl. Anpassung der Freihaltegrenze, bei mir funktionieren 50G auf 8TB-Platten) und dann einen "Freigabe" Ordner auf dem Pool-Dateisystem anlegen - und den via SMB "sharen" ... und wenn man einen weiteren Pool braucht, einfach einen neuen Freigabe-Ordner anlegen.

      Man muss mit SnapRAID lediglich vermeiden, das die content-Dateien von mergerfs "verwaltet" werden - d.h. sie dürfen zwar auf dem Pool liegen, aber nicht von mergerfs dorthin geschrieben (verteilt) werden, und das "lesen" am Besten auch vermeiden (daher der Unterordner mit dem SMB-Share, und nicht den Hauptordner sharen). SnapRAID schreibt die content-Dateien ja auch nicht auf den mergerfs-Pool, sondern direkt auf die Dateisysteme der jeweiligen Datenplatten. SnapRAID weiß ja nix vom mergerfs ...

      Sc0rp
    • hm ... dann hab ich es wohl zufällig richtig gemacht. D.h. Alle Platten, aber dann Freigabe "Daten" angelegt (Ordner wurde entsprechend angelegt/vorgeschlagen).

      Ach ja - gibt es einen Richtwert für die Parity je HDD - hab da im Moment glaube ich noch die Default 8 GB - ist wohl zu wenig (4TB Platten). (jetzt wo ich 4 TB lese kommen die mir so klein vor ...).

      @Sc0rp: welche Policy verwendest du denn? Evtl ist es ja für die Platten schonender, wenn man die lieber nacheinander füllt (weil dann die Sachen bei einem Zugriff beisammen liegen und nicht 2+ HDDs anlaufen müssen?)
    • Re,

      die Policy kommt auf deine Vorlieben an - mergerfs bietet ja quasi alle Möglichkeiten an, lese dir Alle durch und wähle dann deinen Favoriten. Wichtige Schlüsselwörter sind "ep" für "existing path" (vorhandener/bestehender Pfad) und "mfs" = "most free space" ...

      Derzeit habe ich "epmfs" = "Vorhandener Pfad, meister freier Speicherplatz" (müsste auch der Standard sein), weil mir wichtig ist, das meine Mediendateien nicht komplett verteilt werden. Daher hatte ich am Anfang auch "epall" drinne ... und habe es später geändert.

      Wenn man als führende Policy "mfs" verwendet, werden die Daten gleichmäßig auf alle Pool-Member verteilt, was der Paritätserstellung unter SnapRAID zu Gute kommt, aber eben auch die einzelnen Dateinen wild auf den Members verteilt.

      itbastler schrieb:

      Ach ja - gibt es einen Richtwert für die Parity je HDD - hab da im Moment glaube ich noch die Default 8 GB - ist wohl zu wenig (4TB Platten). (jetzt wo ich 4 TB lese kommen die mir so klein vor ...).
      Verstehe ich nicht - was sollen die "8GB" machen ... wo stellt man die ein? Parity ist ja bei SnapRAID ... da finde ich nix dazu.

      Sc0rp
    • Sc0rp schrieb:

      itbastler schrieb:

      Ach ja - gibt es einen Richtwert für die Parity je HDD - hab da im Moment glaube ich noch die Default 8 GB - ist wohl zu wenig (4TB Platten). (jetzt wo ich 4 TB lese kommen die mir so klein vor ...).
      Verstehe ich nicht - was sollen die "8GB" machen ... wo stellt man die ein? Parity ist ja bei SnapRAID ... da finde ich nix dazu.
      Sc0rp
      er meint wohl, dass mergerfs minfree=8GB auf jeder Platte frei läßt. Kann etwas knapp werden mit dem Verschnitt für die Parityplatte. Ich hoffe er hat diese speziell dafür formatiert, da dies doch einiges bringt.
      SW: OMV 4.1.22 (Arrakis), Snapraid mit mergerfs, Minidlna
      MSI B150M ECO, Intel Pentium G4400, 16GB Kingston DDR4, SSD 250GB, 4TB Daten, 3*8TB+6TB SnapRaid (8TB Parity,3+3+2TB Parity2), FSP Aurum S 400W, Fractal Node 804
    • Re,

      wtuppa schrieb:

      Ich hoffe er hat diese speziell dafür formatiert, da dies doch einiges bringt.
      Das erfordert aber Spezialwissen und Consolefertigkeiten ... und man muss es nicht machen, denn das ist ja auch nur wieder etwas für Leute, die wirlich das allerletzte Byte aus dem Verbund quetschen wollen - wovon ich einfach strikt abrate.

      Daher einfach in den mergerfs-Settings die Freihaltegrenze hochdrehen - am Besten so, das man noch das eine oder andere Verzeichnis "rangieren" kann ...

      Sc0rp
    • Sc0rp schrieb:

      Man muss mit SnapRAID lediglich vermeiden, das die content-Dateien von mergerfs "verwaltet" werden - d.h. sie dürfen zwar auf dem Pool liegen, aber nicht von mergerfs dorthin geschrieben (verteilt) werden, und das "lesen" am Besten auch vermeiden (daher der Unterordner mit dem SMB-Share, und nicht den Hauptordner sharen). SnapRAID schreibt die content-Dateien ja auch nicht auf den mergerfs-Pool, sondern direkt auf die Dateisysteme der jeweiligen Datenplatten. SnapRAID weiß ja nix vom mergerfs ...
      Wie macht man das?

      Kann man irgendwo konfigurieren, dass mergerfs Dateien mit dem Namen "snapraid.*" ignorieren soll?
      Oder wie hast du das gemacht?
      Vielleicht habe ich dich aber auch falsch verstanden. :huh:
    • Re,

      CWempe schrieb:

      Wie macht man das?
      Einfachste Lösung ist, einfach die "Freigabe" auf einen Unterordner auf dem mergerfs-Pool legen.

      CWempe schrieb:

      Kann man irgendwo konfigurieren, dass mergerfs Dateien mit dem Namen "snapraid.*" ignorieren soll?
      Kann man sicher ... i'wie (ich wüsste jetzt nicht auf Anhieb wie, aber siehe oben :D)

      CWempe schrieb:

      Oder wie hast du das gemacht?
      Systemverständnis:
      OMV: schicke grafische Benutzeroberfläche für ein Debian-Linux, verwaltet "Freigaben" und das Basissystem
      SnapRAID: Sicherungsschicht, erstellt Redudanzen mittels dedizierter Paritätsdatenträgern
      UnionFS (mergerfs): macht aus vielen kleinen Partitionen EINE virtuelle Große

      - ich habe einfach zuerst mal alle Festplatten unter OMV formatiert ("Dateisystem anlegen") (Standard EXT4) und Idiotensicher benamst (meine Datenfestplatten heißen D1...D6, Paritätsfestplatten heißen P1...P2)
      - dann habe ich mit SnapRAID die Sicherungsschicht angelegt (keine "Inhalte" auf Paritätsfestplatten legen!)
      - dann habe ich den Verbund aus allen Datenfestplatten unter mergerfs angelegt (50GiB Freihaltekontigent bei 8TB-Platten, ggf. Policy ändern)
      - dann habe ich einen "Freigegebenen Ordner" unter OMV auf dem "Pool" angelegt - der Standard erstellt hier automatisch ein gleichnamiges Unterverzeichnis auf dem Datenträger (hier im "Pool")
      - diesen Unterordner dann als "Samba Share" freigeben

      Sc0rp
    • Ok.
      Das habe ich eigentlich identisch auch so gemacht.
      Die Dateien in den Freigaben sind auch nicht das Problem.

      Wenn ich das richtig verstanden habe, ist die Problematik, dass ich jetzt zum Beispiel diese Daten habe

      Quellcode

      1. /srv/dev-disk-by-label-disk1/snapraid.content
      2. /srv/dev-disk-by-label-disk2/snapraid.content
      3. /srv/dev-disk-by-label-disk3/snapraid.content
      4. [..]
      Das macht normaler Weise keine Probleme.
      Aber wenn man mit den mergerfs-tools dedupliziert oder rebalancet, könnten dabei die "snapraid.content"-Datein gelöscht/verschoben werden.
      Man scheint bei den Tools aber dann Dateien ausschließen zu können.


      So habe ich das zumindest verstanden.
      Ich dachte nur, ich hätte was übersehen oder es gäbe eine bessere Lösung. :saint: