[English]Beim Kopieren großer Dateien unter Windows 11 22H2 kann es zu einem gravierenden Geschwindigkeitseinbruch kommen. Was bisher bereits aus Nutzerkreisen bekannt und von einzelnen Microsoft-Mitarbeitern beschrieben wurden war, ist die Tage offiziell durch Microsoft bestätigt worden. Bisher gibt es nur Workarounds, die Microsoft zur Umgehung des Problems vorschlägt. Nachfolgend ein Überblick, wo das Problem auftreten und was der Benutzer dagegen tun kann.
Anzeige
Aktuell kommt das bereits im September 2022 freigegebene und inzwischen breiter verteilte Windows 11 22H2 nicht aus den Negativ-Schlagzeilen. Ein Problem betrifft das Kopieren großer Dateien zwischen Cloud-Instanzen und lokalen Datenträgern. Die Kollegen von Neowin haben bereits Anfang Oktober 2022 auf den Techcommunity-Artikel Slower SMB read performance for large files in 22H2 von Ned Payle hingewiesen.
In diesem Beitrag vom 3. Oktober 2022 bestätigt der Microsoft Mitarbeiter, dass es zu einem Leistungseinbruch beim Kopieren größerer Dateien von einem Remote Computer auf einen Windows 11-Computer oder beim Kopieren von Dateien auf ein lokales Laufwerk kommen kann. Betroffen sind laut Artikel Dateioperationen, die über das SMB-Netzwerkprotokoll transferiert werden.
Der Status dieses Problems soll im Microsoft 365 Admin Center unter der ID WI442499 zu finden sein, sofern dort Windows Release Health verfügbar ist.
Laut Kommentaren von Ned Pyle steckt der Bug an einer Stelle im Windows 11-Kernel der Version 22H2. Ursächlich für den Bug ist das Preview Update KB5017389 vom 30. September 2022, welches zahlreiche Bugs beheben soll (siehe Windows 11: Preview-Update KB5017389 (30.9.2022)). Inzwischen hat Microsoft in der englischsprachigen Fassung des Support-Beitrags das Problem im Know Issues-Abschnitt bestätigt:
Copying large multiple gigabyte (GB) files might take longer than expected to finish on Windows 11, version 22H2. You are more likely to experience this issue copying files to Windows 11, version 22H2 from a network share via Server Message Block (SMB) but local file copy might also be affected.Windows devices used by consumers in their home or small offices are not likely to be affected by this issue.
Der Geschwindigkeitseinbruch beim Kopieren großer Dateien mit mehreren Gigabyte (GB) kann sowohl eine Netzwerkfreigabe über Server Message Block (SMB), aber auch das lokale Kopieren von Dateien, betreffen. Microsoft geht davon aus, dass Consumer im Heimbereich und Nutzer in kleinen Firmen wahrscheinlich von diesem Problem nicht betroffen sind (da werden solch große Dateien eher nicht übertragen).
Workaround von Microsoft
Das Problem lässt sich laut Microsoft durch verwenden von robocopy und xcopy auf der Ebene der Eingabeaufforderung vermeiden. Grund ist, dass diese Befehle keinen Cache-Manager (gepufferte E/A) verwenden. Die Kopieroperationen ließen sich über nachfolgende Befehle
robocopy \\someserver\someshare c:\somefolder somefile.img /Joder
xcopy \\someserver\someshare c:\somefolder /Jausführen, wobei dort die Quell- und Zielpfade einzufügen sind. Microsoft arbeitet an der Behebung dieses Bugs und will diesen mit einem der kommenden Updates für Windows 11 22H2 beheben.
Ergänzung: Ein Fix ist seit dem 28. Nov. 2022 in Arbeit, siehe Windows 11 22H2: Microsoft Fix für Leistungsproblem beim Kopieren von Dateien kommt.
Anzeige
Ähnliche Artikel:
Windows 11 2022 Update (22H2) freigegeben
Windows 11 22H2: Probleme und Upgrade-Stopper
Windows 11: Druckertreiber als Upgrade-Stopper bestätigt (29. Sept. 2022)
Windows 11: Kompatibilitätsprobleme mit Intel Smart Sound Technology
Windows 11 22H2: Sonderupdate KB5019311 zum 27.9.2022, Media Feature Pack, noch kein FOD?
Windows 11: Preview-Update KB5017389 (30.9.2022)
Windows 11 verstärkt Schutz des SMB-Datenverkehrs
Windows 11 22H2: Nächste Rollout-Phase gestartet, breitere Verteilung
Windows 11 22H2: Bereitstellungspakete funktionieren möglicherweise nicht wie erwartet
Windows 11 22H2: Microsoft untersucht RDP-Probleme
Windows 11: Microsoft hilft, die Leistung beim Gaming wiederherzustellen
2015
Robocopy taugt auch für Backupscripte:
robocopy.exe /E /XO /Z /R:3 /W:5 /tee /LOG+:C:\Temp\copy.log
/E inkl. Unterverzeichnisse
/XO ältere Dateien ausschliessen
/Z Bei Abbruch kann der Kopiervorgang vorgesetzt werden
/R Anzahl der möglichen Fehlerversuche
/W Anzahl der Sekunden je Fehlerversuch
/tee Zeigt die zuvor kopierten Dateien in der Eingabeaufforderung an
/LOG+ Logfile fortführen
=========================
Returncodes können ausgewertet werden:
https://ss64.com/nt/robocopy-exit.html
Dabei gilt zu beachten das %ERRORLEVEL% meines Wissens in verschachtelten IF-Abfragen nicht korrekt ausgerwertet werden können (bug).
robocopy.exe SRC DST /E /XO /Z /R:3 /W:5 /tee /LOG+:C:\Temp\copy.log
Besser als /e ist – situationsbedingt – /mir, denn das löscht im Zielverzeichnis Dateien, welches es im Quellverzeichnis nicht mehr gibt. Damit bekommt man ein 1:1 Backup einer ganzen Verzeichnisstruktur, bei der nur neuere Dateien und im Ziel noch nicht existierende Dateien kopiert werden. Das geht im Vergleich zu anderen Methoden viel schneller.
Ich verwende dazu gerne die GUI Easy RoboCopy. Da kann man sich die Parameter zusammenklicken und abspeichern oder wenn man will den Befehl samt Parameter kopieren und in einem Script übernehmen.
…passend zum Thema, nur ich habe eine ähnliche Herausforderung auf Win10 21H2.
Vielleicht weiss ja ein Mitleser einen Rat (sonst lohnt ab hier das Weiterlesen nicht 😉)?
Die Kopiergeschwindigkeit von einer SSD (SATA, Bitlocker, lesen) auf eine NVMe (komprimiert, Bitlocker, schreiben), schwankt zwischen 450 MB/s bis hinunter zu 4 MB/s. Das war bereits so, als die NVMe (2TB) nagelneu war ("Total Host Writes" laut CrystalDiskInfo: 500GB – es sollte also nicht am fehlenden TRIM liegen) und davor mit einer Samsung-500GB-NVMe.
Dito bei Kopie innerhalb der NVMe. So sieht ein Kopiervorgang mit 20 1GB-Dateien aus: .
Zum Vergleich: Kopie der gleichen Daten auf eine RAM-Disk hat konstante 420MB/s )
Lebe ich weiter damit oder was kann ich versuchen, die Geschwindigkeit zu verbessern?
@Bernd B.
Versuche es mal mit FastCopy:
https://portableapps.com/apps/utilities/fastcopy-portable
Bei Dateien kleiner als 200 MB kann der Buffer(MB) bei 256 MB belassen werden, bei Dateien größer 200 MB empfiehlt sich die Anpassung des Buffers mittels Option->Main Settings->I/O Settings->Buffer Size(MB) auf 512 MB.
Viel Erfolg beim Ausprobieren – hier läuft es allemal besser als mit der internen Kopiefunktion!
Was für ein "SATA"?
SATA 6G?
SATAe?
Was für eine PCIe Version? "2.0" "3.0" "4.0"
Wieviele Lanes?
420MBps klingt nach SATA 3G (Kabel?) und/oder nur einer Lane.
Wo läuft das Bitlocker?
Auf in den Platten oder auf den CPUs?
Wie hoch ist die Load?
Die 4MBps sind bei vielen kleinen Dateien unter NTFS m.W. leider "normal".
Aber es sind nur 20 Files und gibt 8,68MBps.
Da ist etwas faul.
Wenn es NTFS sein muß, könnte man eine Virtuelle Platte einrichten und
diese als Ganzes kopieren. Muß man mal rechnen, was sich lohnt.
Früher hat man viele kleine Dateien auch in ein Zip-archiv gesteckt.
Es sind 1GB-Dateien.
Die Quelle (SATA-III am internen Anschluss) muss zwingend mindestens 420MB/s liefern können (siehe Kopie aufs RAMdrive).
Das Ziel ist eine M.2 NVMe SSD (PCI Express Gen3 x4) in einem PCIe 3.0 4x Slot (Maximum Link Speed: 8.0 GT/s).
Bitlocker auf den Drives (ausser RAMdrive). CPUload < 60% (Ryzen 5 4500U, 6 Kerne).
CrystalDiskMark wirft für das Schreiben von 2x 1 GiB Testsize auf die NVMe 370 MB/s (SEQ1M Q8T1) bzw. 500 MB/s (SEQ1M Q1T1) aus.
450MB/s sind für ein mit 4 Lanes angeschlossenes m.2 NVME zu wenig.
SATA III (6000 Gb/s) ist bei ca. 600MB/s am Ende.
Vermutlich bremst da was …
Schau mal wie schnell das Kopieren
nach einem "safe boot" geht. (ja :-))
robcopy wirst Du sicherlich auch schon mit "raw copy"
"direct io" und unterschiedlicher Threadanzahl erfolglos getestet haben (default 8 Threads sind nicht immer optimal).
Schaumal mit RAMMap wo der Speicher bleibt und ob die Kiste nicht anfängt zu swappen, weil MS meint alles cachen zu müssen (was hier ja absoluter Käse ist) und allen physikalischer Speicher ansich reißt, so das u.U. sogar Treiber(!) ausgelagert werden könnten, was man wg. "cache" wirklich nicht will.
Bei SSDs fällt das nicht so auf weil da nicht klappert.
Emm, ich weiß nicht was die 8Mbs auf
https://ibb.co/fq7GSbD
sollen.
Unter sagte er das es noch 45sec für 4,3GB bruscht
(4330 MBps) / 4 = 1.0825 GBps
Das passt, die NVME bringt wohl so 2GBps
ist doch alles gut?
Nein, 4,3GB in 45s sind ~100 MB/s.
Das ist dann sicher der Durchschnitt über die ganze Zeit.
Ja, Stimmt, Komma fheler, und es war spät, sorry.
Das ist doch eine elementare Grundfunktion eines Betriebssystems!
Was ist diese Windows 11 nur für ein Murks aber als das gelobte Land gepriesen.
Wünsche allen Beta-Usern-Testern-Gamern weiter viel Spaß und Nerven aus Drahtseilen und leistet mal weiter gute Arbeit. Glücklicherweise ist bis 2025 ja noch ein wenig Zeit…
>> Das ist doch eine elementare Grundfunktion eines Betriebssystems!
Wird in kürze gefixed.
Bis dahin besteht für große Kopieraktionen ein funktionierender Workarround.
So what?
"Wird in kürze gefixed."
Das sagte Apple auch immer mit seinem kaputten Memory.
Wurde dann auch:
Sie haben ds selbst gemachte alte MacOS komplett in die Tonne getreten und einfach ein BSD-Unix genommen und mit Fenstern sehr gut getarnt…
Das MS ein Problem beim Kopieren hat mit einem zu aggressivem Caching hat ist ein altes Problem.
"Meistens" fällt das nicht auf, wer schiebt schon 200GB Files durch's Gebirge?
Aber heute mit 4k, 8k Video kein Problem.