Mover läuft ohne Daten zu bewegen

[MVLP]

Hallo zusammen,

 

ich habe mir ein paar Shares auf ein neune Cache Pool erstellt.

Downloads, Backups usw.

 

Nun habe ich gestern ein Backup mit Acronis von meinem PC gemacht und auf das Backup-Share schreiben lassen.

Wurde soweit auch gemacht und Daten waren auf der NVME vorhanden.

 

Nun wollte ich die Daten vom Cache auf das Array schreiben lassen.

Share ist wie folgt eingestellt:

 

Nur leider hat das nicht so wirklich geklappt. Habe Mover gestern um 22 Uhr angeworfen und bis heute 18 Uhr war er immer noch nicht feritg.

Waren / Sind so ca. 600GB an Backup Datei.

Musst leider über "mover stop" abbrechen, da mein Unraid etwas "unrund" gelaufen ist.

 

Hab ich hier etwas falsch gemacht oder woran könnte das liegen?

Die Backup Datei war augenscheinlich nicht mehr im Zugriff, da mein PC ausgeschalten war und nur ein Unterordern von einem Docker benutzt wird.

 

Über jegliche Hilfe bin ich Dankbar!

 

Grüße

Stefan

 

 

[DataCollector]

1 hour ago, MVLP said:

Nun habe ich gestern ein Backup mit Acronis von meinem PC gemacht und auf das Backup-Share schreiben lassen.

Eine große Datei oder gesplittet in viele kleine?

 

1 hour ago, MVLP said:

Wurde soweit auch gemacht und Daten waren auf der NVME vorhanden.

Eine/sehr wenige große, oder viele eher kleine Dateien?

 

1 hour ago, MVLP said:

Share ist wie folgt eingestellt:

 

Zuerst Einmal: stelle den "Minimum free space" besser nicht auf 0 (ein vollgeschriebener Cache/Share bereitet nicht selten Probleme). Nimm etwas mehr, als die größte dort aufzuspeichernde Datei je haben wird.

 

1 hour ago, MVLP said:

Nur leider hat das nicht so wirklich geklappt. Habe Mover gestern um 22 Uhr angeworfen und bis heute 18 Uhr war er immer noch nicht feritg.

Waren / Sind so ca. 600GB an Backup Datei.

600 GB Daten in mehr als 20Stunden = 833.333.333 Byte/s.
Wenn ich mich nicht verrechnet habe, hat Dein System also mit unter 8MByte/s geschrieben, das ist sehr wenig.
Welche Schreibrate hat der Main Tab denn bei dem Array angezeigt?

 

1 hour ago, MVLP said:

Musst leider über "mover stop" abbrechen, da mein Unraid etwas "unrund" gelaufen ist.

Wenn es beispielsweise ein großes 600GB Backup in einer Datei war und der Mover das versucht hat das auf das (aus irgendwelchen Gründen extrem langsame Array) wegzuschreiben und Du ihn dann kurz vor Ende oder so abgebrochen hast, ist es logisch, daß er dei Riesendatei nicht von dem Pool/Cache gelöscht hat, weil sie ja noch nicht komplett auf ddem Array angekommen ist.

Sollte das Array noch langsamer sein, wäre das Problem auch bei etwas kleineren Dateien der Fall.

Beispiel: das Array läuft nur mit einer winzigen Schreibrate von 1MByte/s, dann würden in 20Stunden nur rund 72GB weggeschrieben. Dann würde in der Zeit also sogar eine 72,00001 GB große Datei im Pool/Cache stehen bleiben.

(wenn ich mich nicht verrechnet habe).

 

1 hour ago, MVLP said:

Hab ich hier etwas falsch gemacht oder woran könnte das liegen?

Die Backup Datei war augenscheinlich nicht mehr im Zugriff, da mein PC ausgeschalten war und nur ein Unterordern von einem Docker benutzt wird.

Über jegliche Hilfe bin ich Dankbar!

 

Ich befürchte um hier mehr sagen/raten zu können fehlen noch weitere Informationen.

 

Sidn die betreffenden Dateien groß (wie groß? jeweils >1GB, 10GB,.... ) oder doch eher klein?

Die sieht Dein Aufbau aus? Wieviele Datenträger im Array? Mit oder ohne Parität? Welche Schreibraten hast Du üblicherweise im Array?

und so weiter...

 

 

[MVLP]

42 minutes ago, DataCollector said:

Eine große Datei oder gesplittet in viele kleine?

Ist eine große *.tibx Datei

 

43 minutes ago, DataCollector said:

Eine/sehr wenige große, oder viele eher kleine Dateien?

Auf der NVME sind kleine bis sehr große Datein, wenige KB bis hunderte GB

 

44 minutes ago, DataCollector said:

Zuerst Einmal: stelle den "Minimum free space" besser nicht auf 0 (ein vollgeschriebener Cache/Share bereitet nicht selten Probleme). Nimm etwas mehr, als die größte dort aufzuspeichernde Datei je haben wird.

Werde ich umstellen.

 

45 minutes ago, DataCollector said:

600 GB Daten in mehr als 20Stunden = 833.333.333 Byte/s.
Wenn ich mich nicht verrechnet habe, hat Dein System also mit unter 8MByte/s geschrieben, das ist sehr wenig.
Welche Schreibrate hat der Main Tab denn bei dem Array angezeigt?

Wenn ich das richtig im Kopf habe, sind es zwischen 8MB/s bis zu 50MB/s

 

46 minutes ago, DataCollector said:

Wenn es beispielsweise ein großes 600GB Backup in einer Datei war und der Mover das versucht hat das auf das (aus irgendwelchen Gründen extrem langsame Array) wegzuschreiben und Du ihn dann kurz vor Ende oder so abgebrochen hast, ist es logisch, daß er dei Riesendatei nicht von dem Pool/Cache gelöscht hat, weil sie ja noch nicht komplett auf ddem Array angekommen ist.

Sollte das Array noch langsamer sein, wäre das Problem auch bei etwas kleineren Dateien der Fall.

Beispiel: das Array läuft nur mit einer winzigen Schreibrate von 1MByte/s, dann würden in 20Stunden nur rund 72GB weggeschrieben. Dann würde in der Zeit also sogar eine 72,00001 GB große Datei im Pool/Cache stehen bleiben.

(wenn ich mich nicht verrechnet habe).

Ja was mich etwas wundert, ist dass eine andere Datei ohne "Probleme" vom Cache aufs Array geschrieben wurde war auch ca. 600GB groß.

 

46 minutes ago, DataCollector said:

Ich befürchte um hier mehr sagen/raten zu können fehlen noch weitere Informationen.

 

Sidn die betreffenden Dateien groß (wie groß? jeweils >1GB, 10GB,.... ) oder doch eher klein?

Die sieht Dein Aufbau aus? Wieviele Datenträger im Array? Mit oder ohne Parität? Welche Schreibraten hast Du üblicherweise im Array?

und so weiter...

 

 

Das wäre meine aktuelle Konfiguration:

Die Parity und Disk1 sind auf einem SATA controller PCIe 2.0 x1 

[1b4b:9215] 24:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9215 PCIe 2.0 x1 4-port SATA 6 Gb/s Controller (rev 11)
[11:0:0:0]   disk    ATA      WDC WD20SPZX-22U 1A01  /dev/sdc   2.00TB
[12:0:0:0]   disk    ATA      WDC WD20SPZX-22U 1A01  /dev/sdd   2.00TB

Disk 3 hängt direkt am MB SATA Port.

[1022:43c8] 09:00.1 SATA controller: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset SATA Controller (rev 01)
[9:0:0:0]    disk    ATA      WDC WD20EFRX-68E 0A82  /dev/sdb   2.00TB

 

Dateien sind zwischen 100kb, mehrere MB und 20 - 600GB

Kleiner Dateien brauchen natürlich "länger" bei einer großen Maße als eine große Datei.

 

 

[DataCollector]

On 4/30/2023 at 12:58 AM, MVLP said:

Ist eine große *.tibx Datei

Wie groß ungefär?

Ich lasse mit Absicht Acronis die Zieldateien immer auf 1,9GB splitten. Somit habe ich zwar dann einige Dutzend/hunderte Imagedateien, aber die lassen sich problemlos in Häppchen sogar mit einem FAT32 USB Stick transferieren.

(Ich darf gerne Leuten mit älterer Hardware helfen, wobei sich die eigentlich schon lange obsolte FAT32 2GB Grenze auch heute noch zeigt).

 

On 4/30/2023 at 12:58 AM, MVLP said:

Wenn ich das richtig im Kopf habe, sind es zwischen 8MB/s bis zu 50MB/s

50MByte/s ist okay, 8MByte/s ist sehr langsam für ein Array.

 

On 4/30/2023 at 12:58 AM, MVLP said:

Ja was mich etwas wundert, ist dass eine andere Datei ohne "Probleme" vom Cache aufs Array geschrieben wurde war auch ca. 600GB groß.

In einem vorherigen Durchlauf oder in diesem beanstandeten MoverDurchlauf?

 

On 4/30/2023 at 12:58 AM, MVLP said:

Das wäre meine aktuelle Konfiguration:

Soweit ich richtig sehe:
2x2TB Daten und 1x 2TB Parity Festplatten im Array.

 

Die Western Digital WD Blue Mobile 2TB, 7mm, 128MB, SATA 6Gb/s 5400Rp (WD20SPZX)
sind 2,5inch SMR Festplatten.

 

2,5inch ist (in diesem Fall) schon langsamer als 3,5inch
5400Rpm ist langsamer als 7200RPM
und durch SMR sackt nach kurzer Schreibdauer die Datenrate zusätzlich massiv ein.

 

Im Array als Datenfestplatte ist das vielleicht noch zu ertragen,
als Parityfestplatte sind diese Festplattentypen (meiner unmaßgeblichen Meinung nach) vollkommen falsch (=bremsend) platziert.

 

Von den 3 Festplatten im Array sollte die Western Digital WD Red Plus 2TB, SATA 6Gb/s, 3,5inch, CMR (WD20EFRX) die Parität machen.
Das redzuiert die negativen Auswirkungen der SMR Technik etwas.

 

On 4/30/2023 at 12:58 AM, MVLP said:

Die Parity und Disk1 sind auf einem SATA controller PCIe 2.0 x1 

[1b4b:9215] 24:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9215 PCIe 2.0 x1 4-port SATA 6 Gb/s Controller (rev 11)
[11:0:0:0]   disk    ATA      WDC WD20SPZX-22U 1A01  /dev/sdc   2.00TB
[12:0:0:0]   disk    ATA      WDC WD20SPZX-22U 1A01  /dev/sdd   2.00TB

Marvelkontroller und unraid...    Ich sage mal ganz vorsichtig: nicht mein Favorit.

Und an PCIe 2.0 x1 mehr als 2 Festplatten zu betreiben ist auch irgendwie nicht unbedingt (für performante aktuelle Festplatten) nicht die Beste Idee.

Deine dort angeschlossenen Festplatten hingegen sind schon eher die gemächlicheren Typen, wodurch sich an dem Kontroller in dieser Situation zumindest kein Flaschenhals zeigen dürfte (abgesehen davon daß Marvel und unraid.... naja, ich sagte ja schon, nicht mein Favorit).

 

On 4/30/2023 at 12:58 AM, MVLP said:

Disk 3 hängt direkt am MB SATA Port.

[1022:43c8] 09:00.1 SATA controller: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset SATA Controller (rev 01)
[9:0:0:0]    disk    ATA      WDC WD20EFRX-68E 0A82  /dev/sdb   2.00TB

Gute Entscheidung, weil diese WD etwas flotter als die anderen beiden Arrayfestplatten ist, sollte sie auch den performantesten Kontrollerport bekommen.

Wenn ich es richtig lese scheint Dein Mainboard für einen AMD Ryzen oder so gedacht zu sein.

Diese Boards haben meist mehr als nur 1 OnBoard SATA Steckplatz. Wenn es möglich ist, würde ich den Marvel entfernen und die Festplatten intern anschließen.

Das spart Strom und vielleicht auftretende Probleme durch den Marvel unter unraid.

 

On 4/30/2023 at 12:58 AM, MVLP said:

Dateien sind zwischen 100kb, mehrere MB und 20 - 600GB

Also ich befürchte SMR, 5400Rpm und sehr ungünstige Parityeinstellung (falsche Festplatte) haben die Transferrate über die erwähnte Zeit (20-18 Uhr) so weit einbrechen lassen, daß der Mover sich an der größten Datei noch die Zähne ausgebissen hat und noch mitten im Prozess des Kopierens war.

Du erwähntest, daß der Mover wegen Problemen von Dir manuel gestoppt wurde.

Gerade bei ausgelasteten SMR Festplatten kann der Mover so erscheinen, als wenn er eingefrohren ist, weil er eben auf die SMR Festplatte wartet, die sich mit sich selbst beschäftigt.

Könnte es das gewesen sein, weshalb Du ihn abgebrochen hast?

 

On 4/30/2023 at 12:58 AM, MVLP said:

Kleiner Dateien brauchen natürlich "länger" bei einer großen Maße als eine große Datei.

Bezogen auf kleine Dateien im KB oder wenige MB Bereich hast Du vollkommen recht.

a) 600GB in 10 kb Stücken verschieben: die Kiste wird wohl Tage brauchen.

b) 600GB in beispielsweise 1-5 GB Stücken: wird weniger brauchen als a).

c) 600GB an einem 600 GB großen Stück: wird ähnlich wenig brauchen wie b).

 

Aber alle 3 Szenarien rennen vor die 5400RPM SMR Wand der langsamen 2,5inch Paritätsfestplatte.

 

Wenn der Mover aber bei c) hängt/abgebrochen wird, hat er natürlich auf dem Pool/Cache noch nichts gelöscht, weil die Datei ja noch nicht fertig überrragen ist.

Wenn der Mover bei a) oder b) an einer Datei dran ist und Du brichst ab, wird er aber die kopieren Dateien auf den Pool/Cache schon gelöscht haben, wodurch sich ein Erfolg durch weit mehr freien Platz auf dem Pool/Cache sehen läßt.

 

Edited May 2, 2023 by DataCollector
Typos