Berky schrieb:
Ich habe eine Frage zu der Kopiergeschwindigkeit zwischen zwei NVMe`s unter Windows. Was genau ist der limitierende Faktor, dass das Kopieren von Dateien untereinander nicht mehr als 2,2-2,3 gb/s vonstatten geht? Kommt in absehbarer Zeit ein Patch, oder ist das das ende der Fahnenstange?
Soweit ich weiĂ, arbeitet der Windows-Explorer sequenziell und nicht parallel (was fĂŒr HDDs auch sinnvoll ist, fĂŒr NVMe-SSDs nicht). Die maximalen Werte einer NVMe-SSD kommen single-threaded leider nicht zur Geltung, was der Hauptgrund fĂŒr die geringen Praxisvorteile auĂerhalb von Benchmarks sein dĂŒrfte. Evtl. könnten hier alternative Dateimanager helfen, die eine parallele Abarbeitung unterstĂŒtzen. Konkrete Empfehlungen habe ich dazu leider nicht, wĂŒrden mich aber gelegentlich auch interessieren.
Hast du schon mal probiert, beim Formatieren der Partition eine gröĂere BlockgröĂe einzustellen? Beim SystemdatentrĂ€ger wĂŒrde das zwar zu mehr Platzverbrauch fĂŒhren, weil jede noch so kleine Datei mindestens einen Block belegt, aber fĂŒrs Datengrab mit durchweg groĂen Dateien könnte das Geschwindigkeitsvorteile bringen. Ich wĂŒrde an deiner Stelle mal den ATTO Benchmark laufen lassen und sehen, ab welcher BlockgröĂe nahezu volle Geschwindigkeit anliegt, und das dann mal fĂŒr die Partition nutzen. WĂ€re aber erstmal nur ein Versuch! Kannst ja eine kleine Partition am Ende zu Versuchszwecken erstellen, ohne gleich alles löschen zu mĂŒssen.
Hast du zum Erstellen von Backups schon mal den Konsolenbefehl robocopy genutzt? Könnte evtl. Vorteile bringen.
Das Klonen bzw. Imaging ist nochmal eine andere Sache. Wie Acronis hier arbeitet, weiĂ ich nicht genau. Ich habe frĂŒher Festplatten und SSDs mit EaseUS Disk Copy geklont. Dieses (vor vielen Jahren kostenlose, jetzt weiĂ ich es nicht genau) Programm arbeitet im Hintergrund sehr wahrscheinlich mit Linux und dem Befehl dd, dabei mit der Standard-BlockgröĂe von 512B. Das ist tödlich fĂŒr die Geschwindigkeit. Wenn Acronis das genauso oder Ă€hnlich macht, rĂŒhrt die niedrige Geschwindigkeit daher. Ich klone DatentrĂ€ger inzwischen nur noch mit Linux, bspw. mit einem gParted Live-Stick. Dort in der Konsole den Befehl dd nutzen und per Parameter eine deutlich gröĂere BlockgröĂe einstellen, bspw. 1MiB, was sich fĂŒr mich als Optimum herausgestellt hat. Klonen lassen sich auf diese Art ganze DatentrĂ€ger (bspw. /dev/sda auf /dev/sdb) oder nur einzelne Partitionen (bspw. /dev/sda1 auf /dev/sdb1). Wenn man sich mal eingearbeitet hat und sehr genau acht gibt auf mögliche Eingabefehler (!!!), ist es viel schneller und universeller als jede kommerzielle Lösung, noch dazu freie Software. Auch ein Klonen in eine Archivdatei (=Imaging) ist damit möglich. Unter SATA reize ich beim Klonen von DatentrĂ€ger zu DatentrĂ€ger das SATA-Limit voll aus. Beim Imaging kommt noch dazu, ob ein komprimiertes Archiv erstellt wird, das erfordert natĂŒrlich Rechenleistung und je nach Kompressionsverfahren, -grad und CPU entsprechend auch Zeit. dd arbeitet dateisystemunabhĂ€ngig, ist also universell, geht fĂŒr Linux- und Windows-DatentrĂ€ger, auch beliebig vollverschlĂŒsselt oder gemischt mit verschiedenen Systemen. Das bedeutet aber auch, dass es auch leere Bereiche mit kopiert, also nicht nur den tatsĂ€chlich im Dateisystem belegten Platz.
Unter Windows lĂ€sst sich fĂŒrs Imaging auch das Konsolen-Tool DISM nutzen, erfordert aber ein zweites System (bspw. Windows-Live-Stick Win10PE SE), da das laufende System sich nicht selbst kopieren kann. DafĂŒr arbeitet es mit der maximalen Kompression schnell (Standardkompression nutzt nur einen CPU-Thread und ist auf modernen Systemen grottig langsam, max. Kompression ist multithreaded und deshalb um ein Vielfaches schneller!) und auch effizient, da es Windows-systemspezifisch optimiert ist und bspw. Auslagerungs- und Ruhezustands-Datei automatisch auslĂ€sst.