Bestand an Nutzdaten: Austauschen von Dateien rutscht am SSD-Cache vorbei?

[DataCollector]

Hallo.

 

Quelle externer Win10 PC mit TotalCommander.
Ziel Unraid Array mit vorgeschaltetem SSD Cache als SMB Share.

Bei dem Sammelsurium der Dateien in der Quelle (einige hunderte Dateien in einigen unterschiedlichen Unterverzeichnissen mit eingen hunderten GB Kapazität) sind einige dabei, die namensgleich aber inhaltsunterschiedlich auf dem Array schon vorhanden sind (und somit überschrieben werden sollen).

Klar fragt der Totalcommander einmal ob das gewünscht ist und ich beantworte die Nachfrage mit sinngemäß 'Ja, alle'.

Dabei ist mir aufgefallen, daß gerade bei den Dateien die Übertragung vom Win10 PC zum Unraid Share stockt (= nach kurzer Zeit sehr viel langsamer läuft).
Als ich da genauer mit dem MC nachsah, stellte ich fest, daß diese doppelten Dateien nicht im Share SSD-Cache auftauchen.
Alle anderen sind auf der SSD gelandet (wo sie der Mover dann später auf das Array verschieben würde).

Dafür waren die Festplatten, auf denen diese Namensdoppel vorhanden sind hoch gefahren (Spin up).

 

Ich verstehe, wenn unraid die Namensdoppel auf den Arrayfestplatten direkt löscht, damit es nicht irgendwo 2 Dateien mit dem selben Namen und identischer Ordnerstruktur gibt.

Aber dennoch sollte die Übertragung nicht stocken, da ein simpler Löschbefehl doch im Ram gepuffert werden kann (bis die betreffende Festplatte dreht), währen die neue Datei im Cache landen würde.
Doch es scheint, als wenn zusätzlich die neuen Dateien dann direkt am SSD-Cache vorbei auf die Festplatte geschrieben werden.
Dadurch bremt die Parität massiv den SMB Transfer vom Win10 PC zum unraid Share ab und das merke ich bei der Übertraung der Daten.

 

Läßt sich das irgendwo umstellen?
Ich würde bei so einer Aktion bevorzugen, wenn alles neue im SSD Cache landet und dann von dort erst später auf die Festplatten kopiert wird, so wie es das Konzept eigentlich vorsehen sollte.

[hawihoney]

1 hour ago, DataCollector said:

so wie es das Konzept eigentlich vorsehen sollte.

 

Es funktioniert exakt wie vorgesehen. Achte auf das kleine Wort "new". Aus der Hilfe zum Cache bei den Shares:

 

Quote

Specify whether new files and directories written on the share can be written onto the Cache disk/pool if present. 

 

Edited October 22, 2022 by hawihoney

[hawihoney]

1 hour ago, DataCollector said:

Läßt sich das irgendwo umstellen?

 

Was passiert wenn Du direkt auf den Cache schreibst? Hab es selbst noch nicht ausprobiert. Wäre mal einen Versuch wert.

 

[alturismo]

1 hour ago, DataCollector said:

Läßt sich das irgendwo umstellen?
Ich würde bei so einer Aktion bevorzugen, wenn alles neue im SSD Cache landet und dann von dort erst später auf die Festplatten kopiert wird, so wie es das Konzept eigentlich vorsehen sollte.

 

wie @hawihoney schreibt soll es auch so sein, neue Dateien landen da wie beschrieben, vorhandene Daten werden dort überschrieben wo diese auch sind ... wenn dann müsstest du vorher die vorhandenen löschen ... dann kämen die "neuen Dateien" wieder über den cache rein ...

 

und Nein, nicht cache direkt jetzt beschreiben und Dubletten verursachen ...

[hawihoney]

10 minutes ago, alturismo said:

nicht cache direkt jetzt beschreiben und Dubletten verursachen

 

Ist das so? Wie gesagt, ich habe es es noch nie ausprobiert. Ich dachte der Mover wäre "strunzdoof" und würde einfach alles rüber kopieren und wenn vorhanden überschreiben. Erstellt der tatsächlich neue Dateien sofern sie schon existieren? So hätte ich das nie gebaut ...

 

Was ist denn wenn ich eine Datei unterhalb /mnt/user erstelle und später auf /mnt/disk an der selben Stelle erzeuge. Gibt das ebenfalls eine Dublette durch den Mover?

 

Ui, muss ich mir merken.

 

 

Edited October 22, 2022 by hawihoney

[MAM59]

Ich hatte das merkwürdige Verhalten von ein paar Wochen auch schon zur Sprache gebracht, aber es hat auch niemanden interessiert.

 

Richtig wäre, die alte Datei zu löschen, dann sind die ankommenden Daten "neu" und landen im Cache.

Allerdings muss dazu trotzdem immer eine kurze Pause eingelegt werden und die Platten hochfahren um das Verzeichnis upzudaten. Erst dann darf der Transfer weitergehen.

 

[DataCollector]

44 minutes ago, hawihoney said:

Was passiert wenn Du direkt auf den Cache schreibst? Hab es selbst noch nicht ausprobiert. Wäre mal einen Versuch wert.

Das würde einiges an Bequemlichkeit kosten und aus dem Cache müßte ich dann immer noch die Daten ins Array bekommen.

Kommt der Mover damit klar, wenn er im Array gleichnamige Dateien überschreiben müßte oder schreibt er die einfach irgendwo hin und dann habe ich im Array 2 gleichnamige Dateien in gleich aussehenden Unterverzeichnisstrukturen auf unterschiedlichen Festplatten? Denn dann wäre es ja eher Glück, welche davon ich dann ja irgendwann später beim Öffnen erwische.

[DataCollector]

30 minutes ago, hawihoney said:

Ist das so? Wie gesagt, ich habe es es noch nie ausprobiert. Ich dachte der Mover wäre "strunzdoof" und würde einfach alles rüber kopieren und wenn vorhanden überschreiben. Erstellt der tatsächlich neue Dateien sofern sie schon existieren? So hätte ich das nie gebaut ...

Das ist zu befürchten. Beispiel: Ich habe eien Datei "Hallo.txt" auf Festplatte 1 im Array und die Festplatte 1 ist im Laufe der Jahre ziemlich voll geworden (bis zum eingestellten Limit).

Dann befürchte ich, der Mover schreibt eine gleichnamige Datei eben irgendwo anders hin (je nach Verteilungsregel), weil Festplatte 1 ja schon zu voll ist.

Und dann habe ich die gleichnamige Datei in einer gleichnamigen Verzeichnisstruktur aber ganz wo anders.

 

30 minutes ago, hawihoney said:

Ui, muss ich mir merken.

Die Problematik mit den Doubletten ist mir schon früher aufgefallen, als ich mit MC Verzeichnisse mit Dateien im Array "verschoben" habe. Wenn man den Verschiebevorgang abbricht fragt der MC ob man den kopierten Teil löschen oder behalten will. Selbst wenn ich Löschen auswähle löscht er nur die gerade angefasste Datei, aber die anderen vorher im selben Durchgang schon kopierten Dateien bleiben im Ziel bestehen.

Leider hat der MC die schon kopierten Dateien in der Quelle aber noch nicht gelöscht. Das macht er erst ganz am Ende des jeweiligen verschievbevorganges, den man ja abgebrochen hat. Und schon hatte ich identische Verzeichnisse auf 2 Festplatten im selben Array, welche zum Teil identische Dteien enthielten.

Und dem Mover scheint man auch nicht mehr 'Intelligenz' mitgegeben zu haben, als es beim MC der Fall ist.

Naja, wenn man es weiß, kann man damit umgehen.

[DataCollector]

36 minutes ago, MAM59 said:

Richtig wäre, die alte Datei zu löschen, dann sind die ankommenden Daten "neu" und landen im Cache.

Allerdings muss dazu trotzdem immer eine kurze Pause eingelegt werden und die Platten hochfahren um das Verzeichnis upzudaten.

An der Stelle hatte ich auf die Lagerung diese prozessteiles im RAM gehofft, sio dass die Festplatte in aller Ruihe hoch fahren kann, während weitere einlaufende Dateien eben nach dem RamCahe zum SSD Cache weiter gereicht werden.

Jedesmal 20-30 Sekunden zu warten, bis irgendwo etws gelöscht wurde ist auch recht bremsend.

 

[alturismo]

56 minutes ago, hawihoney said:

Ist das so? Wie gesagt, ich habe es es noch nie ausprobiert. Ich dachte der Mover wäre "strunzdoof" und würde einfach alles rüber kopieren und wenn vorhanden überschreiben. Erstellt der tatsächlich neue Dateien sofern sie schon existieren? So hätte ich das nie gebaut ...

das hat nichts mit "doof" zu tun ... wenn du direkt in den cache schreibst dann ist diskX ja außen vor ... und ja, dann hast du Dubletten und Nein, der mover überschreibt nicht stumpf was im array liegt ... das Gejammere will ich gar nicht sehen wenn jemand aus Versehen /mnt/cache schreibt anstelle /mnt/user und dann die array Daten einfach überschrieben werden ... das wäre ja auch am System vorbei, machen wir alle gerne hier, nur die Konsequenzen sollten dann klar sein wenn ich cache und diskX direkt anspreche anstelle /mnt/user ... machst du doch auch mit deinen Plex Shares im Lesezugriff ...

 

was passiert denn jetzt wenn ich /mnt/user eine Datei aufrufe wo als Dublette vorliegt ?

was passiert wenn ich rm /mnt/user/Share/datei.xyz lösche wenn Sie als  Dublette vorliegt ?

 

also zusammenngefasst, das ist das normale Verhalten und sollte auch so sein, wer überschreibt denn bitte x Daten mit dem gleichen Namen ... und dafür dann ein System aushebeln (fuse Dateisystem) ... macht doch jetzt wirklich nicht soviel Sinn

 

wenn das Szenario ansteht, dann lasse ich halt kurz ein script laufen welches die Dubletten vorher sucht, löscht, und schiebe dann rüber ... wenn ich dann wirklich alles nochmals über den cache gehen will um dann per mover wieder auf das array verschieben will ... ist doch jetzt nicht wirklich sinnig die Diskussion, meiner Meinung nach.

[MAM59]

1 hour ago, DataCollector said:

An der Stelle hatte ich auf die Lagerung diese prozessteiles im RAM gehofft,

Nööö! Gott bewahre uns vor dieser Idee!!!

Alle Daten, die quittiert wurden, betrachtet der Klient als "erledigt". Das würde bei Unterbrechungen gnadenloses Chaos verursachen.

1 hour ago, DataCollector said:

Jedesmal 20-30 Sekunden zu warten, bis irgendwo etws gelöscht wurde ist auch recht bremsend.

Wieso jedes Mal? Die Platte fährt doch nur einmal hoch, oder hast Du Dein Timeout auf 10s gelegt???

51 minutes ago, alturismo said:

, wer überschreibt denn bitte x Daten mit dem gleichen Namen

Also das kann ja schon mal vorkommen. Aber er beschwert sich ja nicht über x Dateien, sondern, dass er (natürlich) bei 1000 Dateien nicht vorher wissen kann, ob ein paar davon schon mal vorhanden sind. Und bei denen hakt es dann eben. Ist aber eben nur lästig, kein wirklicher Fehler.

Ich hab hier auch manchmal den Effekt, dass ich ein paar Filme verschieben will, und einige davon sind schon vorhanden. Da kommt der Transfer dann etwas ins Stottern.

Richtig nervig wird es allerdings, wenn die Dateien größer sind. Z.B. son 200Gb Backup Datei. Da kriegt man schon lange Zähne, wenn sich UNRAID mit quälenden 160-200Mb/s der Daten erbarmt, statt mit 1,02Gb/s in den Cache zu schreiben...

Ist halt nur ne Frage des Geschwindigkeitsunterschiedes zwischen Disk, Cache und LAN. Je schneller LAN und Cache, desto mehr nervt es.

 

[alturismo]

5 minutes ago, MAM59 said:

Ich hab hier auch manchmal den Effekt, dass ich ein paar Filme verschieben will, und einige davon sind schon vorhanden. Da kommt der Transfer dann etwas ins Stottern.

yep ... das passiert hier auch ab und an, wobei ich bis dahin die Daten meist noch im cache habe, ich schieb ja nicht täglich alles ins array

 

und sehe ich auch so, einmal fährt halt alles an, dann halt überschreiben und fertig, das wird ja sicherlich kein "Tagesgeschäft" sein ... und ja, auch ich schiebe lieber Vollgas in den cache anstelle ins array, aber wenn ich halt einfach array Daten mal überschreibe dann ist es dann so mit /mnt/user ...

[DataCollector]

2 hours ago, MAM59 said:

Nööö! Gott bewahre uns vor dieser Idee!!!

Alle Daten, die quittiert wurden, betrachtet der Klient als "erledigt". Das würde bei Unterbrechungen gnadenloses Chaos verursachen.

Das ein Stromausfall oder so bei unraid sowieso eine schlechte Sache ist, ist doch klar.

Wenn wirklich das Löschen wegen einem solchen problem wirklich mal nicht stattfindet, fällt es auf, wenn man nach doppelten Dateien sucht. Das wäre zeitaufwändig aber auch machbar.

 

2 hours ago, MAM59 said:

Wieso jedes Mal? Die Platte fährt doch nur einmal hoch, oder hast Du Dein Timeout auf 10s gelegt???

Bei 24 Datenfestplatten sind das dann 24x 20-30 Sekunden und bei entsprechend großen Datenmengen, wie im beschriebenen Fall kann ein Spindown Timer schon mal die eine oder andere Festplatte wieder runter fahren, wenn zwischenzeitlich eben andere angesprochen werden oder eben doch einiges im SSD Cache landet.

Ich erwähnte ja hunderte von GB an Dateien.

[mgutt]

3 hours ago, MAM59 said:

Das ein Stromausfall oder so bei unraid sowieso eine schlechte Sache ist, ist doch klar.

Das hat nichts mit Unraid zu tun, sondern ist ein Standardverhalten von Linux und lässt sich wie folgt abstellen:

https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?do=findComment&comment=959302

 

5 hours ago, hawihoney said:

Ist das so? Wie gesagt, ich habe es es noch nie ausprobiert. Ich dachte der Mover wäre "strunzdoof" und würde einfach alles rüber kopieren und wenn vorhanden überschreiben.

4 hours ago, DataCollector said:

Das ist zu befürchten. Beispiel: Ich habe eien Datei "Hallo.txt" auf Festplatte 1 im Array und die Festplatte 1 ist im Laufe der Jahre ziemlich voll geworden (bis zum eingestellten Limit).

Dann befürchte ich, der Mover schreibt eine gleichnamige Datei eben irgendwo anders hin (je nach Verteilungsregel), weil Festplatte 1 ja schon zu voll ist.

Und dann habe ich die gleichnamige Datei in einer gleichnamigen Verzeichnisstruktur aber ganz wo anders.

Nein das passiert nicht. Der Mover überspringt Dateien, wenn sie bereits auf dem Array vorhanden sind. Dadurch kann man zB auch tricksen und einzelne Dateien auf dem Cache halten, wenn man im Array eine gleichnamige Datei (ohne Inhalt) erstellt, auch wenn das Caching auf "yes" steht.

 

Könnt ihr einfach testen, in dem ihr zB das macht:

touch /mnt/cache/appdata/test

touch /mnt/cache/disk1/test

 

Dann Mover Logs aktivieren und den Mover starten. In den Logs kommt dann "skip ... file already exists". Ich meine dann meckert auch Fix Common Problems.

 

4 hours ago, alturismo said:

was passiert denn jetzt wenn ich /mnt/user eine Datei aufrufe wo als Dublette vorliegt ?

was passiert wenn ich rm /mnt/user/Share/datei.xyz lösche wenn Sie als  Dublette vorliegt ?

Es wird die vom Cache geladen. Und beim Löschen wird erst die vom Cache gelöscht. Dann ist die Datei trotzdem wieder da und kann nochmal gelöscht werden. Dann wird sie erst vom Array gelöscht. Habe ich alles schon ausprobiert.

 

5 hours ago, MAM59 said:

Richtig wäre, die alte Datei zu löschen, dann sind die ankommenden Daten "neu" und landen im Cache.

Das lässt sich nicht umsetzen, weil ein Dateisystem, was das virtuelle Dateisystem von Unraid ja auch ist, keiner Logik von Dateien, sondern von Inodes und Datenblöcken folgt. Das Dateisystem weiß also nicht, dass der Prozess gerade die komplette Datei überschreiben möchte. Tatsächlich könnte es sogar so sein, dass ein Prozess nur Teile einer Datei ändern möchte wie es zB rsync macht, wenn sich nur ein Teil der Datei geändert hat. Würde nun die Zieldatei auf dem Array vorab gelöscht werden, wäre am Ende nur eine kaputte Datei übrig.

 

Man kann das nur lösen, in dem man:

a) Hot und Cold Daten strikt auf Cache und Array verteilt, muss man dann trotzdem mal Dateien aktualisieren, die auf dem Array liegen, dann Pech, ist das eben langsam

b) das Mover Tuning Plugin verwendet und "heißere" Dateien auf dem Cache behält

c) auf /mnt/cache schreibt und dann selbst zB per Skript, Dubletten aus dem Array löscht, damit der Mover den Cache auf das Array verschieben kann

d) wenn man glaube ich "rsync --archive --remove-source-files --whole-file --delete-after /quelle/ /ziel" verwendet. Habe ich noch nicht ausprobiert, aber das sollte so gehen: Dadurch wird die kopierte Datei erst als .tmp-Datei erstellt (die landet dann auf dem Cache), dann löscht rsync die bereits vorhandene Datei (aus dem Array) und dann benennt rsync die .tmp in den richtigen Dateinamen um (und da die Datei im Array weg ist, liegt sie nun auf dem Cache, wie gewünscht).

 

 

 

 

[DataCollector]

6 hours ago, alturismo said:

wer überschreibt denn bitte x Daten mit dem gleichen Namen ...

Beispielsweise ich.

Aktuell nehme ich bei meinem Quellsystem die Bearbeitung der Daten vor (Auch die Erzeugung der Checksummen). Und ab und zu gleiche ich eben unraid Zielsystem) mit dem Quellsystem ab.

Heute im Laufe des Tages  waren dann geschätzt rund 3tsd Dateien abzugleichen und davon waren geschätzt 400 namensgleich zu den Zielen auf dem Unraid Array.

 

6 hours ago, alturismo said:

wenn das Szenario ansteht, dann lasse ich halt kurz ein script laufen welches die Dubletten vorher sucht, löscht, und schiebe dann rüber ...

Wenn Du dieses Script mitteilen könntest, kann man es vielleicht anpassen.

 

Ich nutze eben den TotalCommander (Befehle/Verzeichnisse Synchronisieren) und lasse ihn von einem Win10 PC aus einfach

(Win Quelle) D:\Hauptverzeichnis\<manuell markierte Unterverzeichnisse und deren Inhalt>   mit (unraid Ziel) S:\Hauptverzeichnis\*.* vergleichen.

Dabei habe ich noch vor destruktiver Ausfuehrung die Möglichkeit nachzubessern, bevor irgendein Schaden entsteht.

 

Das Ergebnis ist eine Liste in der ich sehe, was auf welcher Seite anders ist und bei der ich dann entscheiden kann, wie weiter verfahren werden soll.

Im Ziel werden mir dann beispielsweise die Dateien dargestellt, die in Quelle nicht vorhanden sind, welche ich dann zum Löschen anwähle und löschen lasse.

Übrig bleiben eben die Datein, die im Ziel nicht vorhanden sind und die, die namensgleich vorhanden sind (oft eben auch alle Dateien in einem Unterverzeichnis mit Checksummen um die Datenintegrität der Dateien auch über Computergrenzen und auch in einem PC prüfen zu können.  Beipielsweise sowas: ALLE.SFV).

Wie gesagt machen die neuen Dateien, die nicht namensgleich im Ziel vorhanden sind keine Probleme.

Aber die Dateien, die eben namensgleich und inhaltsunterschiedlich (oder auch nur Datumsstempel unterschiedlich) vorhanden sind, erzeugen die beschriebene Bremsefunktion und das passiert bei großer Datenmenge (=Anzahl und Dateigröße) doch schon bemerkbar oft.

 

Ich habe vorhin auf dem Cache nachgesehen und dort waren von der heutigen Aktion Dateien in Summe von 1,8TB drauf. Geschätzt habe ich heute rund 2,3TB an Daten/Dateien auf das Unraid System kopiert und dann sind ca. 500GB direkt ins Array gegangen, weil die eben am SSD-Cache vorbei geschrieben wurden. Das sind dann eben die namensgleichen Dateien gewesen.

 

6 hours ago, alturismo said:

wenn ich dann wirklich alles nochmals über den cache gehen will um dann per mover wieder auf das array verschieben will ... ist doch jetzt nicht wirklich sinnig die Diskussion, meiner Meinung nach.

Tja, ich hatte gedacht, dass unraid in seiner NAS Funktionalität eben etwas ausgeklügelter funktioniert und gehofft, daß ich nur noch nicht die richtige Option eingeschaltet habe.

Um einen solchen geschwindigkeitsvorteil zu haben, habe ich meinem QNAP NAS extra 2 NVMe SSD verpasst und dort schreibt es sich problemlos mit hoher Datenrate weg.

Nur leider ist das mit seinen 4 Festplattenschächten zu klein für meinen Datenbestand und wenn ich ein NAS mit 30+ Datenträgern kaufe, geh ich pleite.

Und meine Windowsmaschinen, die das bisher mit Hardwareraid sehr gut gemacht haben, schlucken mir leider zu viel Strom. Deswegen will ich ja schon seit mitte letzten Jahres auf unraid setzen.

 

Edited October 22, 2022 by DataCollector

[DataCollector]

32 minutes ago, mgutt said:

Das hat nichts mit Unraid zu tun, sondern ist ein Standardverhalten von Linux und lässt sich wie folgt abstellen:

Darauf wollte ich hinaus. Deshalb ist ja meinr Eaton USV da.

Und deshalb sehe ich ja auch in der Aussage:

"Alle Daten, die quittiert wurden, betrachtet der Klient als "erledigt". Das würde bei Unterbrechungen gnadenloses Chaos verursachen."

als nicht zutreffend/relevant an.

Achja: Kopien sind dank meiner aktuellen Win10 Quelle sowieso vorhanden.

 

32 minutes ago, mgutt said:

Nein das passiert nicht. Der Mover überspringt Dateien, wenn sie bereits auf dem Array vorhanden sind. Dadurch kann man zB auch tricksen und einzelne Dateien auf dem Cache halten, wenn man im Array eine gleichnamige Datei (ohne Inhalt) erstellt, auch wenn das Caching auf "yes" steht.

Mover überspringt: Danke, diese Info hatte ich bisher nicht.

 

Dann wäre das SSD caching sogar noch besser für meine Zwecke geeignet (wenn unraid es beim Überschreiben machen würde).

Wünschenswertes (einstellbares) Verhalten:

Man schreibt von außen (halbwegs flott) auf das unraid share und alles geht in den SSD Cache. Dann läuft irgendwann nachts der Mover an und wenn er auf eine doppelte Datei stößt (die er ja nach aktuellem Verhalten auf die korrekte Festplatte an die selbe Stelle schreiben sollte, die die namensgleiche Originaldatei hat), bemerkt er das und überspringt diese.

Wenn man das weiß, kann man dann am nächsten Tag einfach auf das Cache schauen und sieht genau, was da übrig geblieben ist und kann manuell nachstuern (schnell mit dem MC auf die richtigen Festplatten überschreiben).

 

32 minutes ago, mgutt said:

Könnt ihr einfach testen, in dem ihr zB das macht:

touch /mnt/cache/appdata/test

touch /mnt/cache/disk1/test

Dann Mover Logs aktivieren und den Mover starten. In den Logs kommt dann "skip ... file already exists". Ich meine dann meckert auch Fix Common Problems.

Also FCP meckerte bei mir mit doppelten Dateien noch nie (ich beschrieb ja, daß der MC beim Verschieben ganzer Verzeichnisse mit Inhalt in Wirklichkeit Kopien anlegt erst nach erfolgreich gemeldetem Kopiervorgang das Quellverzeichnis mit Inhalt löscht, wodurch beim Abbrechen zwischendurch eben an beiden Stellen identische Dateien bestehen bleiben).

Was den Befehl "touch" angeht, der war mir bisher unbekannt und ich muss mich erst einlesen, was der macht.

 

32 minutes ago, mgutt said:

Das lässt sich nicht umsetzen, weil ein Dateisystem, was das virtuelle Dateisystem von Unraid ja auch ist, keiner Logik von Dateien, sondern von Inodes und Datenblöcken folgt. Das Dateisystem weiß also nicht, dass der Prozess gerade die komplette Datei überschreiben möchte. Tatsächlich könnte es sogar so sein, dass ein Prozess nur Teile einer Datei ändern möchte wie es zB rsync macht, wenn sich nur ein Teil der Datei geändert hat. Würde nun die Zieldatei auf dem Array vorab gelöscht werden, wäre am Ende nur eine kaputte Datei übrig.

Das verstehe ich nicht. Muss mich da wohl auch noch einlesen.

 

32 minutes ago, mgutt said:

Man kann das nur lösen, in dem man:

a) Hot und Cold Daten strikt auf Cache und Array verteilt, muss man dann trotzdem mal Dateien aktualisieren, die auf dem Array liegen, dann Pech, ist das eben langsam

Bezogen darauf, daß Du vermutlich meinst, daß Array mit Festplatten und Cache mit SSD betrieben wird:

Das ist eben bei entsprechend großen Datenmengen eine viel zu teure Angelegenheit.

Und das mit dem "langsam" ließe sich ja durch komplettes Aufgabenpuffern abfangen.

 

32 minutes ago, mgutt said:

b) das Mover Tuning Plugin verwendet und "heißere" Dateien auf dem Cache behält

Es ist nicht im voraus zu wissen, welche Dateien ausgetauscht werden und somit müßten sehr viele TB im Cache liegen.

Ich glaube wir sind uns einig, dass ein paar hundert TB im SSD Cache eine wünschenswerte aber aktuell sehr (und für mich zu) teure Sache sind. Vielleicht haben die TB Preise von SSD diese von Festplatten in 10-20 Jahren unterschritten. Dann wird das auch für Privatpersonen, die damit kein Geld machen interessant.

 

32 minutes ago, mgutt said:

c) auf /mnt/cache schreibt und dann selbst zB per Skript, Dubletten aus dem Array löscht, damit der Mover den Cache auf das Array verschieben kann

Das ist eine nette Idee.

Da ich sogar die zu wählende Zielfestplatte im Array bestimmen will (ich habe gerne alle meien Dateien sinngemäß zusammen um eben nicht verschiede festplatten anlaufen zu sehen) kopiere ich sowieso vieles vom SSD Cache auf das Array um. Das mach eich mit dem MC, da der krusader mir leider zu oft mit nervenden Nachfragen bei vorhandenen Verzeichnissen und Dateien) stehen bleibt (und ich im krusader noch nicht gefunden habe diese Nachfragen für alle folgenden Batchvorgänge gleich mit zu beatowrten).

Ivh hätte also keine Bedenken, das entsprechend zu lösen, aber habe dahingehend keien Scriptfähigkeiten um das selbst aktuell umzusetzen.

Edited October 22, 2022 by DataCollector
Typos

[DataCollector]

3 hours ago, alturismo said:

und sehe ich auch so, einmal fährt halt alles an, dann halt überschreiben und fertig,

Wenn ich nicht täglich hinterher bin (und das war ich diese Woche nicht), dann werden aus hunderten GB eben ein paar TB am Wochnende. Und ja, das dauert recht lang und ist leider nicht "mal eben fertig".

3 hours ago, alturismo said:

das wird ja sicherlich kein "Tagesgeschäft" sein

In der Regel täglich rund 300-500GB an Dateivolumen, diesen Freitag (weil ich Mo-Do ziemlich geschludert habe) in Summe über 2TB.

Vor ein paar Tagen habe ich meine 24. 18TB Festplatte eingebunden. Die ursprünglich enthaltenen 16TB Festplatten sind zwischenzeitlich aus dem Array schon wieder rausgeflogen (ersetzt gegen 18TB).

Ich warte wirklich sehnsüchtig auf eine MultArrayfunktion. Momanten behelfe ich mir damit, daß ich zusätzliche Cachepools nutze (4x2TB SSD Raid0+ 3x16TB HDD Raid0)

Edited October 22, 2022 by DataCollector

[mgutt]

44 minutes ago, mgutt said:

d) wenn man glaube ich "rsync --archive --remove-source-files --whole-file --delete-after /quelle/ /ziel" verwendet. Habe ich noch nicht ausprobiert, aber das sollte so gehen: Dadurch wird die kopierte Datei erst als .tmp-Datei erstellt (die landet dann auf dem Cache), dann löscht rsync die bereits vorhandene Datei (aus dem Array) und dann benennt rsync die .tmp in den richtigen Dateinamen um (und da die Datei im Array weg ist, liegt sie nun auf dem Cache, wie gewünscht).

 

Das funktioniert tatsächlich:

 

# folgende Testdateien werden erstellt
echo "old" > /mnt/disk6/Marc/dest/test.txt
echo "old" > /mnt/disk6/Marc/dest/test2.txt
sleep 2
echo "newer" > /tmp/source/test.txt
echo "newer" > /tmp/source/test2.txt

# ich lösche den Linux Cache
sync; echo 3 > /proc/sys/vm/drop_caches 

# über die GUI werden alle HDDs gestoppt, Wartezeit 30 Sekunden, damit sie wirklich stehen

# rsync ausführen
rsync --archive --remove-source-files --whole-file --delete-after --itemize-changes /tmp/source/ /mnt/user/Marc/dest
.d..t...... ./
>f..t...... test.txt
>f..t...... test2.txt

# der Kopiervorgang ist SOFORT fertig, die HDDs fahren erst danach hoch (!)

# keine Datei mehr im Array, aber die neuen auf dem Cache
cat /mnt/disk6/Marc/dest/test.txt
cat: /mnt/disk6/Marc/dest/test.txt: No such file or directory
cat /mnt/disk6/Marc/dest/test2.txt
cat: /mnt/disk6/Marc/dest/test2.txt: No such file or directory
cat /mnt/cache/Marc/dest/test.txt
newer
cat /mnt/cache/Marc/dest/test2.txt
newer