Mover Einstellungen Share

[NiMora]

Hallo zusammen, ich haber für eine Freigabe die auf dem Screenshot zu sehende Einstellung gewählt.

 

Für mein Verständnis sollte es so laufen, dass wenn ich (viele) Daten auf diese Freigabe kopiere, wird erst der Cache befüllt (250 gb) und wenn die Grenze zu den 36,7 GB erreicht ist, wird automatisch auf das Array geschaufelt.

 

Passiert aber nicht. Der Kopiervorgang stoppt und sagt, dass kein Speicherplatz mehr frei ist.

 

Wo ist mein Denkfehler?

 

Besten Dank

[DataCollector]

41 minutes ago, NiMora said:

Für mein Verständnis sollte es so laufen, dass wenn ich (viele) Daten auf diese Freigabe kopiere, wird erst der Cache befüllt (250 gb) und wenn die Grenze zu den 36,7 GB erreicht ist, wird automatisch auf das Array geschaufelt.

Passiert aber nicht. Der Kopiervorgang stoppt und sagt, dass kein Speicherplatz mehr frei ist.

Ist die zu kopierende Datei vielleicht größer diese ca. 37GB?

 

Diese "Frei"angabe funktioniert nur dann so, wie Du es Dir vorstellst, wenn die Dateien kleiner als diese Minimalgrenze sind.

Deshalb sollte man diese Grenze immer etwas größer (2mal so groß) wie die jemals darauf zu kopierende Datei wählen.

Auch einer der Gründe, warum ich (persönlich) einen 250 oder gar 500GB großen Cache als etwas klein ansehe und zu mindestens 1 oder mehr TB rate.

Aber ich kopiere auch ab und zu mal ein paar hundert großes Image durch die Gegend und will dabei nicht direkt auf ein langsames Array auflaufen.

Edited March 16 by DataCollector
Typos

[NiMora]

Moin und danke für die Antwort.

 

auch wenn das die vorgegebene Größe war, als ich die Freigabe erstellt habe, ist es dennoch ausreichen groß. Keine der zu kopierenden Dateien ist größer. Ja, der Cashe ist noch etwas klein, aber dafür hat es noch nicht gereicht.  erstmal waren die großen HDDs dran.

 

Also die Einstellung an sich ist aber korrekt und meine Vorstellung davon, wie das in der Praxis laufen müsste?

 

Hättest noch ne Idee, was es sonst noch liegen könnte?

[DataCollector]

6 hours ago, NiMora said:

Keine der zu kopierenden Dateien ist größer. Ja, der Cashe ist noch etwas klein, aber dafür hat es noch nicht gereicht.  erstmal waren die großen HDDs dran.

Also die Einstellung an sich ist aber korrekt und meine Vorstellung davon, wie das in der Praxis laufen müsste?

 

Es gibt im Cache selber auch eine solche Größeneinstellung. Wie sieht die denn bei Dir aus?

 

[NiMora]

52,4

 

sollte also auch dicke reichen. Inzwischen bin ich mit der Übertragung aller Daten fertig und habe es im Terminal direkt auf die Disk gespielt, sodass das unbeaufsichtigt nicht immer stoppt. Muss es demnächst mal noch überwachen, ob das im normalen Betrieb auch passiert bzw. nicht passiert. 

 

Weiß auch nicht, was das war.

[NiMora]

Muss das Thema doch noch mal öffnen.

 

habe gerade etwas heruntergeladen (verschiedene rar dateien, allerdings sehr viele) auch hier stoppte der Download wieder, weil der Cache voll war, trotz Erwartung, dass der Mover anspringt, wenn die min free disk erreicht ist.

 

Hat noch jemand einen Tip, wo ich etwas falsch eingerichtet haben könnte?

[DataCollector]

6 minutes ago, NiMora said:

habe gerade etwas heruntergeladen (verschiedene rar dateien, allerdings sehr viele) auch hier stoppte der Download wieder, weil der Cache voll war, trotz Erwartung, dass der Mover anspringt, wenn die min free disk erreicht ist.

Hat noch jemand einen Tip, wo ich etwas falsch eingerichtet haben könnte?

 

Hast Du in dem verwendeten Share so eingerichtet, daß

a) ein Minimaler platz frei bleibt  und

b) bei vollem Cache auf das Array (secondary Storage) durchgeschrieben wird?

[NiMora]

Welche Einstellung in den Shares wäre das?

 

Primary ist cache, secondary ist Array. Mover action ist chache -> Array.

 

Ich war der Meinung, dass hier die Funktion des movers an die minimum free space geknüpft ist.

[DataCollector]

7 hours ago, NiMora said:

Welche Einstellung in den Shares wäre das?

 

Share Minimum Free (sollte etwas größer sein, wie die größte jemals zu schreibende Datei).

Cache Minimum Free (sollte etwas größer sein, wie die größte jemals zu schreibende Datei). 

Und wenn im Share geschrieben wird und der Cache sich als voll meldet, dann wird ins Array durchgeschrieben.

 

7 hours ago, NiMora said:

Ich war der Meinung, dass hier die Funktion des movers an die minimum free space geknüpft ist.

 

Die Funktion des Movers ist an den Timer geknüpft. Man kann mit Mover Tuning da etwas vareieren, aber der Mover arbeitet default nach dem eingestellten Timer/Schedule.

 

Bild 1: Share (gelb = minimum Free Space;  Grün = Wie soll weiter geschrieben werden)

 

Bild 2: Im Cache gibt es auch ein Minimum Free Space.

Edited March 31 by DataCollector

[NiMora]

Danke für die Mühe.

 

bis auf die GB-Zahlen stimmen die Angaben exakt überein.

 

Welchen Sinn macht aber eine zeitgesteuerte Mover-Aktivität? Also ja, wenn der cache groß genug ist und man darin alle Tages-Daten unterbringen kann, macht der nächtliche mover sinn, aber in meinem Fall würde ich mir eben wünschen, dass die Daten ins array laufen, wenn der cache seine Grenze erreicht hat.

 

Ich kann daraus nur schließen, dass der Mover gar nichts mit einem vollaufenden cache zu tun hat. Aber scheinbar habe ich alle Einstellungen korrekt angelegt, dennoch funzt es nicht. Was auch merkwürdig ist, mir aber erst jetzt aufgefallen ist, ist der Umstand, dass der freie Platz im cache größer ist, aber der vollständige download. Somit sind nicht nur die Einzeldateien kleiner, als die angegebenen maximalen GB-Zahlen, als auch in Summe weniger, als der auf dem Cache vorhandene verfügbare Speicher und dennoch läuft er voll.

 

Merkwürdig. Bin ratlos

[DataCollector]

57 minutes ago, NiMora said:

Welchen Sinn macht aber eine zeitgesteuerte Mover-Aktivität?

 

Daß man bei einem ausreichen großen Cache eben die Platten möglichst lange schlafen lassen kann und diese dann eben timergesteuert erst anlaufen, wenn das System in Offzeiten nicht viel zu tun hat.

 

57 minutes ago, NiMora said:

Also ja, wenn der cache groß genug ist und man darin alle Tages-Daten unterbringen kann, macht der nächtliche mover sinn, aber in meinem Fall würde ich mir eben wünschen, dass die Daten ins array laufen, wenn der cache seine Grenze erreicht hat.

 

Dass ist im Regelfall auch so.

Was Du da verstellt hast, dass die Daten nicht ins Array laufen weiß ich nicht. Hast Du evtl. mit dem zusätzlichen Mover Plugin da etwas verstellt?

 

57 minutes ago, NiMora said:

Ich kann daraus nur schließen, dass der Mover gar nichts mit einem vollaufenden cache zu tun hat.

 

Korrekt. Und das ist auch so gewollt und dokumentiert.

 

57 minutes ago, NiMora said:

Was auch merkwürdig ist, mir aber erst jetzt aufgefallen ist, ist der Umstand, dass der freie Platz im cache größer ist, aber der vollständige download. Somit sind nicht nur die Einzeldateien kleiner, als die angegebenen maximalen GB-Zahlen, als auch in Summe weniger, als der auf dem Cache vorhandene verfügbare Speicher und dennoch läuft er voll.

 

Kann es ein, daß Deine Software, die diese Dateien anlegt vielleicht temporärdateien auf dem selben 'laufwerk'/Share nutzt?

Sabnzb beispielsweise macht den download und kopiert anscheinend danach die Teile zusammen. Das bedeutet, daß im falschen Moment für den einen Download fast doppelt so viel Platz benötigt wird, als das Ergebnis hinterher aufweist.

[NiMora]

Erneut danke für die Antwort.

 

Ich habe am Mover noch gar nicht herumgespielt und nix eingestellt. Habe ihn in den Fällen lediglich mal manuell gestartet. Auch habe ich kein mover-plugin installiert. wüste gar nicht, warum. Etwas verstellt zu haben, wäre mir auch nicht bewusst, habe lediglich Standard-Einstellungen durchgeführt.

 

Das Thema Temp-Dateien könnte es sein, erklärt aber leider auch nicht, warum die Dateien nicht alleine verschoben werden, wenn der cache volläuft.

 

Nun, es ist zwar etwas unbequem, aber der Fall tritt eher selten auf. Werde mal auf zwei größere cache-ssd's sparen und dann den Minimum-Speicher hochschrauben und erneut testen.

 

Besten Dank

[DataCollector]

1 hour ago, NiMora said:

Werde mal auf zwei größere cache-ssd's sparen und dann den Minimum-Speicher hochschrauben und erneut testen.

 

Nur so:

Ein Mover, der auf Füllstatus reagiert würde das System noch mehr durcheinander bringen.

 

Erklärung:

Man hat eine Pool/Cache SSD, die die Daten schenll aufnimmt (sagen wir mal bei einer 10GBLan Anbindung  schreibt die SSD optimal konstant mit 1GByte/s).

Wenn dieser Pool Cache nun bis zum Anschlag voll läuft und der Mover anspringt, verschiebt dieser die Dateien des Cache ins Array, welches festplattentypisch mit 80Mbyte/s wegschreibt (wenn man Parity nutzt).

Das bedeutet also, daß nun einerseits die Daten der Pool/Cache SSD ins Array geschrieben werden (welches aber zur Aufnahme nicht schnell genug ist).

Es prasseln aber andererseits weiter Dateien über die 10GBLan rein und diese werden dann (default bei unraid) direkt ins Array geschrieben. Somit kommen sich auf dem Array 2 Schreibvorgänge gleichzeitig in die Quere und werden beide dann auf jeweils ca. die Hälfe ausgebremst (wegen der zusätzliochen Kopfbewegungen, vermutlich sogar noch niedriger).

 

Somit würde eine Füllstandsabhängige Movernutzung in dem Fall sogar noch mehr behindern, als es die defaulteinstellung des Durchschreibens auf das Array macht.

Warum es bei Dir nicht auf das Array schreibt, weiß ich nicht. In der Regel sollte das funktionieren.

 

Mit ausreichend (bis sogar sehr groß dimensioniertem) Cache kann man das auch kompensieren.

 

Du schreibst von  Cache SSDs = Mehrzahl: Falls Du die als Raid1 nutzt, vielleicht mach es Sinn die als Raid0 zu nutzen. So hast Du ohne Kostenaufwand eine höhere Kapazität im Cache und wenn Du den Mover vielleicht auf 1x pro Nacht einstellst gehen im Schadensfalle auch nur die Daten eines Tages verloren.

Nur so als Gedanke.