RAM Write Cache für das Array deaktivieren

[Torben]

Moin, moin,

 

ich hatte bereits einen Thread im englischsprachigen Bereich eröffnet und das grundlegende "Problem" wurde analysiert, aber ich glaube da ist so viel los, dass eine Weiterverfolgung schwierig wird. Und wir haben hier ja wirklich eine gute, aktive deutsche Moderation...das bin ich bei englischsprachigen Software-Herstellern nicht gewohnt. Vielen Dank schon mal dafür! 👍🙂 

 

Nun aber zu meinem Problem: Wenn ich auf das Array schreibe verringert sich die grundsätzliche Schreibleistung durch multiple parallele Schreibprozesse aus dem RAM Write Cache beim Überschreiben von Dateien auf unterschiedlichen Platten drastisch. Reconstruct Write wird deaktiviert, "Normal" läuft halb so schnell, irgendwie macht das Feature für meinen Anwendungsfall alles nur langsamer und nicht schneller. Das Array ist für mich mehr ein Datengrab (das auch mal aktualisiert wird), alle schnell und oft im Zugriff befindlichen Dateien sind auf den Cache-SSDs. Von daher war meine Überlegung den Write Cache für das Array zu deaktivieren, damit nicht unnötig "auf der Parity rumgebumst" wird (2-3 Platten schreiben gleichzeitig) und auch Reconstruct Write zuverlässig funktioniert. Ich habe das Ganze durch den englischen Post per Tips&Tweaks-Plugin und die Dirty Ratios erstmal einigermaßen nutzbar gemacht, aber das betrifft ja das komplette System und 100%ig funktioniert es auch nicht.

 

Leider bekam ich auf folgendes keine Antwort mehr: Gem. meiner Google-Recherche kann man den RAM Write Cache für einzelne Platten wohl  beim Mounten per "-o sync" deaktivieren. Die Manipulation des Array-Mountens geht dann doch ein bisschen über meine "Frickelwohlfühlzone" hinaus.

 

Daher meine Fragen (endlich ):

 

1. Wie deaktiviert man den RAM Write Cache für das Array richtig und gefahrlos?

 

2. Weil es mir gerade einfällt...kann man das (mir neue) Verhalten von unRAID abstellen, dass beim Überschreiben bei "Use Cache = Yes"-Shares die Ursprungsdatei auf dem Array gelöscht und auf dem Cache neu erstellt wird? Ich bin mir ziemlich sicher, dass unRAID früher direkt auf die jeweilige Platte geschrieben hat. Mir ist zwar klar, dass mit dem Löschen und neu anlegen die Geschwidigkeit stark erhöht werden kann, Kopiervorgänge Richtung unRAID sind für mich aber Geschwindigkeits-technisch ziemlich irrelevant (im Gegensatz zu Kopiervorgängen innerhalb unRAID). Das Einzige, das für mich bei diesem Vorgehen passiert ist, dass die Platte trotzdem an geht (nur um einen Löschvorgang durchzuführen) und die Cache-SSDs mit aktualisierten Alt-Daten, anstatt mit wirklichen Neu-Daten, gefüllt werden.

Edited July 22, 2021 by Torben

[mgutt]

21 hours ago, Torben said:

Wenn ich auf das Array schreibe verringert sich die grundsätzliche Schreibleistung durch multiple parallele Schreibprozesse aus dem RAM Write Cache beim Überschreiben von Dateien auf unterschiedlichen Platten drastisch.

Warum schreibst du auf mehrere Platten parallel? Hör auf deinen Share auf mehrere Platten zu verteilen, dann unterbindest du diesen Effekt auch.

 

21 hours ago, Torben said:

Von daher war meine Überlegung den Write Cache für das Array zu deaktivieren, damit nicht unnötig "auf der Parity rumgebumst" wird (2-3 Platten schreiben gleichzeitig) und auch Reconstruct Write zuverlässig funktioniert.

Dann benutzt du Unraid aber auch einfach "falsch". Das Array ist ein "Cold Storage". Auf dem schreibt man nicht ständig herum. Wenn Du auf HDDs ständig schreiben willst, solltest du einen Pool mit HDDs erstellen und dort deinen Share ablegen. Ansonsten verstehe ich ehrlich gesagt dein Problem nicht. Lass das Array doch so lahm sein wie es will. Soll der Mover doch nachts auf das Array so lahm und kompliziert schreiben wie er will. Kann dir doch herzlich egal sein, wenn du im RAM/SSD Cache unterwegs bist.

 

21 hours ago, Torben said:

Gem. meiner Google-Recherche kann man den RAM Write Cache für einzelne Platten wohl  beim Mounten per "-o sync" deaktivieren.

Mag sein, aber das wirst du in Unraid vermutlich nicht beeinflussen können, da Unraid User Shares per FUSE mountet und Disk-Mounts haben ja eine ständige Abhängigkeit zur Parity. Da müsstest du also an den Wurzeln von Unraid rumfummeln und dieser Code ist sowieso Closed Source. Die Performance wird dadurch auch nicht besser, sondern massiv schlechter. Selbst schon getestet in dem ich Dirty Pages auf Null gestellt habe. SMB schreibt dann ja jeden Chunk einzeln. Selbst SSDs brechen dann massiv ein.

 

21 hours ago, Torben said:

kann man das (mir neue) Verhalten von unRAID abstellen, dass beim Überschreiben bei "Use Cache = Yes"-Shares die Ursprungsdatei auf dem Array gelöscht und auf dem Cache neu erstellt wird? Ich bin mir ziemlich sicher, dass unRAID früher direkt auf die jeweilige Platte geschrieben hat.

Das ist auch immer noch so. Erst vor ein paar Tagen festgestellt und mich noch gewundert, warum mein Upload auf den Server so lahm war als ich eine Datei überschrieben habe ^^ Wie hast du dieses Verhalten ausgelöst. Über SMB? Das sollte eigentlich nicht passieren.

 

Ansonsten kann ich dir nur mehr RAM und mehr Write Caching ans Herz und nicht das Gegenteil davon. Auch in diesem Video thematisiert:

 

 

Ich lade so problemlos 30GB an Daten mit 1GB/s direkt auf das Server-Array. Dateien, die regelmäßig verändert werden, hält Linux auf die Art auch im RAM vor. Die werden also gar nicht mehr von der HDD geladen. Was dann danach passiert, also wenn Linux die Dateien aus dem RAM auf die HDDs schreibt, kann mir herzlich egal sein. Das bemerke ich ja nicht.

[Torben]

 

1 hour ago, mgutt said:

Warum schreibst du auf mehrere Platten parallel? Hör auf deinen Share auf mehrere Platten zu verteilen, dann unterbindest du diesen Effekt auch.

Mache ich ja nicht. Ich gleiche einen Ordner mittels rsync mit einem Share ab und durch den RAM-Cache wird das (Über-)Schreiben der zweiten Datei gestartet, bevor die erste komplett auf der Platte gelandet ist. Somit verursacht das Linux-Feature eine massive Verschlechterung der Performance bei Nutzung von - für mich - essentiellen unRAID-Features und das empfinde ich als unlogisch, daher versuche ich es zu ändern. Geht das nicht ist es halt so und ich nehme die bestmögliche Variante. 🙂 Sobald 160 TB HDDs in bezahlbaren Regionen angekommen sind, werde ich gerne meine Shares auf nur einer Platte betreiben (wobei ich wetten könnte, dass parallel auf der gleichen Platte geschrieben wird, was auch wieder für'n Arsch ist).

 

2 hours ago, mgutt said:

Dann benutzt du Unraid aber auch einfach "falsch". Das Array ist ein "Cold Storage". Auf dem schreibt man nicht ständig herum. Wenn Du auf HDDs ständig schreiben willst, solltest du einen Pool mit HDDs erstellen und dort deinen Share ablegen. Ansonsten verstehe ich ehrlich gesagt dein Problem nicht. Lass das Array doch so lahm sein wie es will. Soll der Mover doch nachts auf das Array so lahm und kompliziert schreiben wie er will. Kann dir doch herzlich egal sein, wenn du im RAM/SSD Cache unterwegs bist.

Das ist soweit korrekt, deshalb ist es mir auch ewig nicht aufgefallen, da ich ja normaler Weise auch mit Cache=Yes arbeite. Als ich dann 10TB per USB abgeglichen habe, habe ich gleich auf Cache=No umgestellt, da der Cache sowieso übergelaufen wäre. Als mir unRAID anzeigte, dass ich mit weniger als 40 anstatt 85 bzw. 250 MB/s schreibe, dachte ich mir: "Ich glaube nicht, dass das so sein soll." Ja, das kommt nur selten vor, aber auch hier gilt: Wenn ich es passend machen kann, mache ich es passend. 🙂

 

2 hours ago, mgutt said:

Mag sein, aber das wirst du in Unraid vermutlich nicht beeinflussen können, da Unraid User Shares per FUSE mountet und Disk-Mounts haben ja eine ständige Abhängigkeit zur Parity. Da müsstest du also an den Wurzeln von Unraid rumfummeln und dieser Code ist sowieso Closed Source. Die Performance wird dadurch auch nicht besser, sondern massiv schlechter. Selbst schon getestet in dem ich Dirty Pages auf Null gestellt habe. SMB schreibt dann ja jeden Chunk einzeln. Selbst SSDs brechen dann massiv ein.

Danke für die Erklärung. 🙂 Deshalb war mein Gedanke das Ganze nur für das Array zu deaktivieren und nicht über die systemweiten Dirty Pages. Wenn dadurch SMB -> Array-Aktionen in die Hose gehen, hat man natürlich wieder nichts gewonnen...außer SMB macht außer zu löschen nichts auf dem Array. ^^

 

2 hours ago, mgutt said:

Das ist auch immer noch so. Erst vor ein paar Tagen festgestellt und mich noch gewundert, warum mein Upload auf den Server so lahm war als ich eine Datei überschrieben habe ^^ Wie hast du dieses Verhalten ausgelöst. Über SMB? Das sollte eigentlich nicht passieren.

SMB oder NFS über Wireguard (bin grad nicht sicher, ich baue wegen Wireguard-SMB-Problemen viel hin und her). Durchgeführt über das UserScripts-Plugin mittels rsync. Ich versuche das Ganze nachzustellen und berichte.

 

 

Schade Schokolade, dann werde ich wohl damit leben müssen und an den Dirty Pages rumfummeln, wenn ich es brauche. Oder ich muss doch wieder anfangen mir Todesscripte zu bauen, aber eigentlich nutze ich unRAID und dazugehörige Features, um das nicht mehr machen zu müssen (bzw. nur bei Dingen, die nicht als Feature vorhanden sind).

[mgutt]

1 hour ago, Torben said:

Ich gleiche einen Ordner mittels rsync mit einem Share ab und durch den RAM-Cache wird das (Über-)Schreiben der zweiten Datei gestartet, bevor die erste komplett auf der Platte gelandet ist

Nutzt du bei rsync "--inplace"? Weil die Option sorgt erst dafür, dass die bestehende überschrieben wird (dann würde er in jedem Fall auf die Disk im Array schreiben). Standardmäßig erstellt rsync eine temporäre Datei im Ziel (mit Cache Yes also auf der SSD)  und verschiebt die dann. Eventuell mal "--delete-before" testen, falls er trotz Cache Yes auf die Disk schreibt?!

 

Wie viel RAM hast du verbaut? Verbau so viel wie geht und stell dirty_ratio auf sagen wir mal 70%. 

 

Und nun kommt Trick 17. Du rechnest aus wie schnell rsync braucht um dirty pages zu füllen. Sagen wir mal es wären 20GB und du hast eine 10G Verbindung, also 1GB/s. Ein bisschen Puffer eingerechnet, killen wir rsync nach 19 Sekunden:

timeout 19 rsync src dst

 

Danach ein sleep, der genug Zeit lässt die Dirty Pages zu leeren (also wieder ausrechnen wie lange es braucht 19GB aufs Array zu kopieren) und dann die Schleife von vorne beginnen bis die Rückgabe von rsync erfolgreich war.

 

Oder weniger kompliziert einfach ein Bandbreitenlimit bei rsync einstellen, dass langsam genug ist, dass er niemals parallel in den RAM und auf die Disk schreibt. Da er ja die Dirty Pages nach X Sekunden leert, müsste man ausrechnen wo der Sweetspot liegt. Sagen wir dein freier RAM erlaubt 20GB Dirty Pages und dein Array kann ohne das parallele Schreiben 80MB/s wegschreiben. Würde man rsync nun auf 80MB/s limitieren, würden die Dirty Pages nie überfüllen. Stellt man es aber auf 160MB/s, würden sie parallel ja mit 80MB/s geleert. Wenn ich jetzt keinen Denkfehler habe, müsste man also alleine dadurch die Dirty Pages "verdoppeln".

 

 

1 hour ago, Torben said:

Als ich dann 10TB per USB abgeglichen habe, habe ich gleich auf Cache=No umgestellt, da der Cache sowieso übergelaufen wäre.

Bei der Erstbefüllung kann man das ja auch machen, aber du wirst du sicher nicht im regulären Betrieb ständig 10TB draufschieben oder doch? Falls ja, dann ist der Pool dein Weg und nicht das Array.

 

1 hour ago, Torben said:

mit weniger als 40 anstatt 85 bzw. 250 MB/s

40 bis 80 MB/s ist normal beim Array.

 

2 hours ago, Torben said:

Sobald 160 TB HDDs in bezahlbaren Regionen angekommen sind, werde ich gerne meine Shares auf nur einer Platte betreiben

Bleib bitte mal ernst oder willst du mir jetzt damit sagen, dass dein Array aus 16x 10TB besteht und du so große Shares regelmäßig (also nicht Erstbefüllung) abgleichst, dass einzelne Shares niemals auf nur eine 10TB Platte passen?!

[Torben]

1 hour ago, mgutt said:

Nutzt du bei rsync "--inplace"?

Hm, ich möchte es nicht unbedingt "Fehler 40" ("Der Fehler sitzt 40cm vor dem Monitor") meinerseits nennen, aber nein, nutze ich nicht. Dass erst eine Temp-Datei erstellt wird wusste ich, dass sie im Cache erstellt wird macht Sinn. Dass bei Abschluss vermutlich nicht die Datei im Array ersetzt wird, damit hätte ich allerdings nicht gerechnet und daher auch nicht erwartet, dass es an rsync liegt. Ich werde es mir anschauen und mit den von Dir genannten und falls nicht erfolgreich mit anderen Parametern rumprobieren.

 

1 hour ago, mgutt said:

Wie viel RAM hast du verbaut? Verbau so viel wie geht und stell dirty_ratio auf sagen wir mal 70%.

32GB und ich verstehe Deinen Punkt, jetzt wo ich um den RAM-Cache weiß. Aber eigentlich widerstrebt es mir den RAM zu erhöhen, nur um sauber kopieren zu können bzw. wenn ich große Kopieraktionen anliegen habe bräuchte ich vermutlich mehr RAM als das Board verträgt. 🙂 Aber wenn man es nicht ändern kann ist das halt so und die Verringerung der Dirty Pages macht das Ganze für Großaktionen erträglich. Ich war halt der Meinung, dass der RAM-Cache auf dem Array mehr schadet als nützt und eventuell "einfach" deaktiviert werden kann.

 

1 hour ago, mgutt said:

Bei der Erstbefüllung kann man das ja auch machen, aber du wirst du sicher nicht im regulären Betrieb ständig 10TB draufschieben oder doch? Falls ja, dann ist der Pool dein Weg und nicht das Array.

Wie gesagt, solche großen Kopieraktionen habe ich selten und beim "Tagesgeschäft"-Kopieren werde ich mir Deine Rechenidee zunutze machen und wenn es sich sinnvoll ausgeht nochmal 32 GB nachschieben.

 

1 hour ago, mgutt said:

40 bis 80 MB/s ist normal beim Array.

80 bzw. 85 oder 86 sind bei mir normal, da ich extra auf die Drehzahl geachtet habe, als ich das anfängliche Platten-Sammelsurium ersetzt und mich informiert habe, warum denn die Übertragungsgeschwindigkeiten sind wie sie sind (früher waren es nämlich 40-60). Das passt soweit auch.

 

1 hour ago, mgutt said:

Bleib bitte mal ernst oder willst du mir jetzt damit sagen, dass dein Array aus 16x 10TB besteht und du so große Shares regelmäßig (also nicht Erstbefüllung) abgleichst, dass einzelne Shares niemals auf nur eine 10TB Platte passen?!

Nope, derzeit sind es 96TB, aber da ich jetzt von 10TB auf 16TB schwenke, wird der Endausbau 10x16TB sein...Stand heute. Das größte Share ist 42TB und wird mindestens 3x pro Woche abgeglichen, danach kommt eins mit 12TB und dann "Kleinvieh". Spiel-Mitschnitte (roh und bearbeitet), Filme, Serien, Videos, Backups für Freunde und Familie, da kommt schnell eine Menge zusammen. Ich könnte das sicher noch aufteilen und mehrere Shares mit gleichartigem Inhalt auf einzelnen Platten erstellen, aber dann könnte ich auch einfach mit den Platten und damit verbundenen Einschränkungen arbeiten, wie bei "jedem anderen" OS. Wie gesagt, Parity-Absicherung trotz "Plattengröße egal" und der hinter den Shares stehende "Speicher einfach"-Gedanke in Verbindung mit Cache und Array sind für mich die Haupt-Features, weshalb ich unRAID nutze - der Rest ist Bonus.

 

Aber ich wollte auch keine Grundsatzdiskussion auslösen. Mir ging es eigentlich nur darum, dass meiner Meinung nach Vorgänge bez. des Arrays ablaufen, die kontraproduktiv sind, und ob man diese grundlegend ändern kann. Geht halt in einem Fall nicht so wie ich mir das vorstelle, aber dank Deiner Hilfe habe ich jetzt ein paar Ansätze wie ich das Ganze umschiffen kann. 🙂 

Edited July 24, 2021 by Torben

[mgutt]

5 hours ago, Torben said:

Das größte Share ist 42TB und wird mindestens 3x pro Woche abgeglichen,

Dann verteile den Share so, dass bestimmte Unterordner nur auf einer Disk landen und mach aus dem einen rsync Kommando mehrere, die mit einem entsprechenden zeitlichen Abstand einen Unterordner nach dem andern syncen. Also /mnt/disk1/Filme/A bis M und /mnt/disk2/Filme/O bis Z

 

5 hours ago, Torben said:

Aber eigentlich widerstrebt es mir den RAM zu erhöhen, nur um sauber kopieren zu können

Das Hauptproblem von deinem Server ist, dass dein SSD Cache zu klein ist. Wenn du zb pro Tag 5TB neue Daten auf den Server schaufeln musst, dann sollte dein SSD Cache aus 2x 8TB NVMe oder 3x 4TB NVMe bestehen. Wie bei mehr RAM ist das Problem nicht der Wille, sondern das Budget. Das kann man ja nachvollziehen, nur sich über das Betriebssystem selbst beschweren (weil man "nicht ordentlich kopieren kann), ist dann ja auch nicht richtig. Das unRAID Array ist nun mal lahm und das liegt nicht an der Software, sondern an den HDDs, die mit parallelem Lesen und Schreiben einfach nicht gut klarkommen.

 

Ach ja noch was. Du könntest wenn das finanziell besser passt, bei sehr großen Shares auch einen HDD Pool als Cache davor setzen. Es müssen ja nicht zwangsläufig SSDs sein. Je nachdem wie dein Backup aufgebaut ist, könnte man 1:1 Backups auf diesem Pool belassen und nur alte Backups ins Array schieben. Dann hätte man wieder eine Trennung nach Hot und Cold Storage und vor allem könnte dein Array endlich wieder ohne Reconstruct Write besonders energie-effizient arbeiten.

 

[Torben]

4 hours ago, mgutt said:

Dann verteile den Share so, dass bestimmte Unterordner nur auf einer Disk landen und mach aus dem einen rsync Kommando mehrere, die mit einem entsprechenden zeitlichen Abstand einen Unterordner nach dem andern syncen. Also /mnt/disk1/Filme/A bis M und /mnt/disk2/Filme/O bis Z

Das habe ich früher so gemacht und da läuft man irgendwann in das Problem, dass die Platte A-M voll ist. Dann fängt man an rumzuschieben oder eine weitere Platte mit A-M anzulegen, dann ist 'ne Woche später N-Z voll und man hängt noch eine Platte rein, obwohl auf A-M noch 90% frei sind und so geht das immer weiter. Zusätzlich muss man beim Kopieren darauf achten, ob die Ordner/Dateien vielleicht auf Platte A, C, E bereits vorhanden sind usw. Die Lösung? unRAID und seine automatische Verteilung mittels Shares, die ja eigentlich genau all das (und noch mehr) für einen übernimmt. Ist der unterste Balken gut gefüllt, packt man eine weitere Platte dazu und das Thema ist erledigt. Das ist neben der Einfachheit auch noch effizient...finde ich zumindest. 🙂

 

4 hours ago, mgutt said:

Das Hauptproblem von deinem Server ist, dass dein SSD Cache zu klein ist.

Der Cache ist mit 2TB im Normalfall für 1-2 Wochen ausreichend, nur selten wird es mal knapp und in Ausnahmefällen deaktiviere ich ihn halt für das jeweilige Share, aktiviere Reconstruct Write und schreibe direkt aufs Array. Ansonsten läuft mein Array in read/modify/write. Ja, zugegeben, 4 TB fände ich auch besser, aber im Moment muss das erstmal so reichen. Und damit es möglichst selten knapp wird, nutze ich das Mover Tuning Plugin und lasse öfter prüfen, ob verschoben werden muss...und verschiebe dann nach Alter, um die neuesten Dateien möglichst lange auf den SSDs zu halten. Da ich die 2 TB SSDs noch nicht lange als Cache-Pool einsetze, geht da bestimmt noch ein bisschen was in Sachen Feineinstellungen.

 

5 hours ago, mgutt said:

nur sich über das Betriebssystem selbst beschweren (weil man "nicht ordentlich kopieren kann), ist dann ja auch nicht richtig.

Ich erkläre mich und meine Gedankengänge gerne ausführlich (wie man merkt), da man mangels Wissen manchmal nicht nach dem fragt, das man eigentlich wissen will, sondern nach dem, das man meint wissen zu wollen....äh ja. 😄 Solltest Du das als Beschwerde aufgefasst haben, tut es mir leid, das war nicht die Intention.

 

Eigentlich hatte ich eine Wall of Text der sich wiederholenden Erklärungen geschrieben, aber dabei ist mir etwas bewusst geworden (das was Du schon gesehen hast): Mein Problem ist ja nicht das eigentliche Kopieren, sondern das Überschreiben von Dateien und das kann ich bei Mammut-Kopierereien direkt auf das Array bestimmt mittels der von Dir erwähnten Option --delete-before oder ansonsten irgendeinem anderen Parameter in den Griff bekommen. Dann habe ich, wenn ich es richtig verstehe, nur noch den Fall, dass bei einem Wechsel der Festplatten aufgrund der "High Water"-Regel eine Überschneidung passieren kann. Aber das sollte so selten geschehen, dass es mir wurscht ist. Und wenn der Reconstruct-Kopiervorgang bei 10TB aufgrund der Löschungen und Plattenwechsel eine oder zwei Stunden länger dauert ist das völlig ok. Das ist so viel besser als 3 Tage anstatt 12-13 Stunden zu dauern. ^^ Und ich muss keine zentrale Funktion ändern, die sich bei meinem Glück nachher Gott weiß wie auswirkt.

 

Bez. "auf dem Array löschen und auf dem Cache Pool neu schreiben" werde ich mal schauen, da geht bestimmt auch was mit dem von Dir vorgeschlagenen oder anderen Parametern. Und sollte ich trotz der geringen Source-Übertragungsgeschwindigkeit in das Parallel-Problem laufen, ist das aufgrund der zu überschreibenden Datenmenge nicht das Ding.

 

Wenn man dem RAM-Write-Cache mittels rsync einen "Direkt durchschleusen, bitte"-Parameter übergeben könnte, das wäre vielleicht noch cool. Mal schauen, ob sowas geht.

[mgutt]

1 hour ago, Torben said:

mittels rsync einen "Direkt durchschleusen, bitte"-Parameter

Ich habe mal gesucht, aber einen Direct I/O Parameter scheint es nicht zu geben. 🤷

[mgutt]

2 hours ago, Torben said:

Das habe ich früher so gemacht und da läuft man irgendwann in das Problem, dass die Platte A-M voll ist

Ich mache das immer noch so, allerdings jeden Buchstaben einzeln und ich habe vorher herumprobiert welche Buchstaben auf welcher Platte liegen sollten. Resultat:

https://forums.unraid.net/topic/103012-günstige-7200-umin-hdd-ab-14tb/page/3/?tab=comments#comment-969531

 

 

Auch wenn neue Filme dazu kommen, hält sich das Verhältnis des jeweiligen Füllgrades im Bereich von +/- 5%.

 

Irgendwie mag ich es zu wissen, dass auf Disk 3 die und die Filme liegen. Bzw ich kann auf die Art genau eine Disk mit meinem Remote syncen und es läuft nicht das halbe Array. Und bei einer evtl Wiederherstellung wäre auch direkt klar was auf der Disk war und was ich aus dem Backup holen muss, ohne den kompletten Share abgleichen zu müssen. Und so aufwendig war das jetzt nicht. Aber zugegeben musste ich erst die Größe der Verzeichnisse ermitteln und dann ausprobieren welche Buchstaben auf die selbe Gesamtgröße kommen. Aber das habe ich bisher nur 2x gemacht.

[Torben]

OK...krass. Nein, so viel Arbeit hätte/habe ich mir nicht gemacht. Dazu kommen ja noch andere Shares, die einkalkuliert und erweitert werden müssen...das wäre nichts für mich. 🙂 Das mit dem Remote-Abgleich ist ein gutes Argument. Jetzt wo ich darüber nachdenke ist das mit dem "Lösch die Datei auf dem Array und erstell sie auf dem Cache neu" beim Überschreiben vielleicht doch gar nicht so unpraktisch - irgendwie. Dann werden die zuletzt veränderten Dateien entweder vom Cache Pool oder von - im Normalfall - einer zusätzlichen Platte geladen. Die Platten und der Strom werden es mir nicht danken, wenn sie "unnötig" geweckt werden, aber...das Leben ist hart. Verflucht, gerade die zweite 2TB SSD gekauft, nun heißt es wohl auf 2x 4TB sparen (bzw. auf ein gutes Angebot warten). 🙃

Wo die Daten liegen ist für mich nicht relevant. Ich hatte vor vielen, vielen, vielen Jahren schon unter Windows Home Server angefangen die Platten mit "Drive Bender" zusammenzufassen, als mir das Plattenjonglieren begann auf den Keks zu gehen. Mit normalem Linux dann nicht mehr, bis es mich wieder hart genervt hat, so dass ich mich umgesehen habe und bei unRAID gelandet bin. Unter unRAID habe ich mir direkt abgewöhnt in "Platten" zu denken und nur noch in Shares/Storage. Ich lasse einmal täglich ein Script die Inhalte der Disks in eine Datei auf den Cachepool schreiben. Dank Cache Directories bleibt das Array stumm und die Datei ist in wenigen Sekunden erstellt.

 

Aber das zeigt einfach nur wieder: Jeder wie er mag. 🙂