Daten kopieren, wie läuft das ab?

Hallo Leute,
bin gerade dabei meine Daten von einer externen Festplatte auf ne zweite Externe zu kopieren. Und bei >500 GB dauert das natürlich
Jetz hab ich mich gefragt, ob ich den PC in der Zwischenzeit noch vernünftig nutzen kann, oder ob er mit dem Kopiervorgang total ausgelastet ist.
Wie funktioniert denn der Kopiervorgang? Die CPU ist am Kopieren schon beteiligt oder? RAM dürfte nicht gebraucht werden!? Meine interne Festplatte ist ja eigentlich auch unbeteiligt oder? Wie schauts mit Datenbussen aus? Sprich könnte ich ohne Probleme zocken? (Ja ich weiß ich könnts einfach ausprobieren )
Wollt aber mal den technischen Vorgang verstehen.
Klärt mich auf.
Gruß

Es werden eigentlich nur die CPU & die externe(n) Festplatte(n) belastet...

Kannst nebenbei natürlich immer noch produktiv & ohne Nachteile arbeiten.


MfG
[HC]

Ist mal schwer abhängig von deienr Hardware...
Sollte sonst aber kein Problem sein.

Und es benötigt dazu natürlich RAM und CPU...

Beim Kopieren zwischen zwei internen HDDs wird im Grunde nur immer mal wieder eine DMA aufgesetzt, welche dann ohne weitere CPU-Interaktion die Daten kopiert. Beim Kopieren auf eine externe USB-HDD muss deutlich häufiger von der CPU eingegriffen werden. Allerdings sollte man mit einem aktuellen Rechner schon nebenbei problemlos arbeiten können.

Nachdem noch keiner das direct-copy von device zu device erfunden hat, geht jeder I/O über den Speicher: Lesen in den RAM - Schreiben aus dem RAM. Die dabei benutzte Größe hängt vom Kopierprogramm ab und ist marginal

muss mich da mal mit einklinken!

wenn ich dinge von einer internen datenplatte (WD Caviar Blue 640) auf einen usb stick kopiere oder antivir meine platten (WD Caviar Blue 320 und 640, sowie WD Caviar Green 1.5TB) durchsucht, wird mein system regelmäßig "unbenutzbar" alles hängt und stock.

ich benutze vista64 und weder die cpu noch der ram sind auch nur ansatzweise ausgelastet!

hab schon überlegt win7 zu installieren, vielleicht geh das besser damit um..

Das Problem liegt am hohen I/O-Aufkommen einer Applikation, wodurch eine andere mit wenigen Zugriffen auf die gleiche HDD totgebremst wird. NCQ kann diese Situation noch verschärfen.
Da hilft nur runterschrauben der Aktivität von Virenscanner oder Copy-Tool, damit man nebenher noch vernünftig arbeiten kann.

Also wenn die interne Datenplatte = OS/App-Platte, dann ist's, wie Ernst bereits sagte normal. Ein Kopiervorgang lastet eine HDD praktisch aus (bei vielen kleineren Dateien noch extremer) und sie wird unbenutzbar.

Weiter ist bereits Moros im aktuellen SSD-Test aufgefallen, dass Windows 7 scheinbar einen Bug in der Priorisierung der Zugriffe hat. Kopiert man eine einzige grosse Datei, so muss man selbst mit einer SSD zum Teil bis fast zum Ende der Kopieraktion warten, bis sie auf andere Zugriffe reagiert. Ich bin mir 100%ig sicher, dass dies im RC oder früheren Versionen noch nicht der Fall war.

Ich kann jedoch ohne Probleme Dinge von der 1. auf die 2. Daten (Non-OS-)Platte schieben, ohne dass das System irgendwie hängt. Sobald eine OS-HDD in's Spiel kommt ist aus die Maus.

Gewisse Interaktionen kann man nicht ausschalten - Wenn die Firmware der Device fehlerhaft/schlecht designed ist, blockiert die bei NCQ den Zugriff auf einen weit entfernten Bereich abseits des Mainstreams.
Gleiches ist im BIOS/der Controllerfirmware möglich, da kann das OS priorisieren, was es will. Mehr als den Request vorne in die in die Controller/Devicequeue zu stellen ist nicht drin- außer es verhindert das Nachfüttern von I/O-Requests anderer Tasks auf diese Device, damit die Queue-Tiefe mal 1 wird und der eigene Request endlich auch behandelt wird.

Es liegt definitiv am OS.
Bei Moros' Test ist dieses Phänomen bei jeder einzelnen SSD und auch bei beiden Festplatten aufgetreten. Ich konnte dies bestätigen. Mit Windows 7 RTM passierte dies noch nicht (wie mein Praxistest in der Signatur eindeutig beweist).

Kann auch eine Kombination aus Treiber & OS sein. Wenn ich eine 1GB-Iso auf der Intel SSD kopiere erscheint z.B. bei Photoshop bei mir momentan nichtmal der Flashscreen. Erst ganz am Ende tut sich was. Das ist ziemlich abnormal.

Das sollte man ganz einfach mit einem Trace/Monitor auf der Physical Device-Ebene eingrenzen können - Wann geht der Befehl an den Controller, wann erfolgt der Interrupt nach Datentransfer. Liegen nur ein paar ms dazwischen, hing es in der OS-I/O-Queue, sind es Sekunden, wars der Treiber, der Controller oder die Device.
Ähnliches kann man mit Treiber-Tools nochmals hinter dem Treiber veranstalten

Wenn ich's mit XPERF betrachte so sind die Werte für die "IO Time" und "IO Init Time" sowie für die komplette "Service Time" der Illustrator.exe um den Faktor 20-150 höher im Vergleich zwischen Einzelstart und Start + Copy. Kenn mich aber zu wenig aus um die einzelnen Werte korrekt interpretieren zu können.

Wenn ich dasselbe mit dem kopieren vieler kleiner Dateien im Hintergrund mache, sind die Werte sehr ähnlich.

Kopieren von 4GB + direktes Starten von Illustrator: Illustrator-Flashscreen erscheint etwa in der Hälfte des Kopiervorgangs, wenn der Vorgang beendet ist, startet er.
Kopieren von xGB kleinen Dateien + direktes Starten von Illustrator: Illustrator ist nach 4 Sekunden offen...

so danke erst mal für die ganzen Antworten. (auch wenn am Ende etwas abgeschweift wurde )
so ganz zufrieden bin ich allerdings noch nicht. Könnte mir noch mal jemand genauer (ganz genau , ruhig mit Fachbegriffen) erklären wie das bei meinem Beispiel abläuft und wo die Daten genau "entlang laufen"?
Viele Dank schon mal

Dann lies dir die Posts nochmal genauer durch...

http://de.wikipedia.org/wiki/Serielle_Datenübertragung

Da haste genügend Querverweise und kannst dich in die Materie einlesen...

Als Einstiegspunkt dazu die Serielle Schnittstelle zu verlinken, ist vielleicht nicht ganz optimal.

Auf der Software-Seite sieht es so aus, dass die Copy-Anwendung (z.B. der Windows Explorer) den Copy-Befehl in Einzelteilen zerlegt an das Filesystem(z.B. NTFS) weitergibt:

(nicht in allen Einzelheiten)
- lesen des Directorys der Source-Platte - Feststellen der Dateigröße
- schreiben des neuen Directory-Eintrags auf die Target-Platte, Anforderung des dazu und für die Target-Datei notwendigen Platzes)
- wechselweise lesen/schreiben (in Clustergröße) der Datei

das resultiert an der Hardware/Software Schnittstelle zwischen Betriebssytem und BIOS, je nach Größe der Datei, in vielen tausenden Wiederholungen von
- Leseoperation(Sektoradresse, Anzahl Sektoren eines Clusters) von der Source-Platte
- und Schreiboperation(Sektoradresse, Anzahl Sektoren eines Clusters) zur Target-Platte
mit Angabe des dabei zu verwendeten RAM-Bereiches

Diese werden über das BIOS vom entsprechenden Controller übernommen, queued(max 32 je Device), und bei der nächsten Übertragungsmöglichkeit an die Device weitergegeben.

Die Device übernimmt diese Befehle, queued sie wieder(bei NCQ), und führt sie in einer Reihenfolge ihres Gutdünkens ganz oder teilweise aus.
Der Datentransport erfolgt (mglw über den Cache) über von der HDD gesteuerten DMA zwischen RAM und Plattenoberfläche in Paketen
Ist einer der Befehle vollständig ausgeführt oder wegen Fehlers abgebrochen, meldet die HDD das dem Controller

Der Controller meldet die erfolgreiche(oder aus Fehlergründen abgebrochene) Ausführung jedes I/O Befehls zurück an das Betriebssystem, welches wiederum das Programm davon informiert.

auszugsweise einige ins Detail gehende weiterführende Links:
PCI-Express und Grafik des Bussystemes
NCQ im Überblick und dessen Funktionsbeschreibung(Link im Überblick dorthin ist falsch)
DMA Funktionsweise

Bei Bedarf kann ich Dir noch jede bitgenaue Detail-Beschreibung von der Programmschnittstelle über die von der CPU ausgeführten Maschinenbefehle bis in die BIOS-Codierung des Controllers und die Signaldetails an den Leitungen nachreichen - bis Dir der Kopf raucht

Eggcake schrieb:

Also wenn die interne Datenplatte = OS/App-Platte, dann ist's, wie Ernst bereits sagte normal. Ein Kopiervorgang lastet eine HDD praktisch aus (bei vielen kleineren Dateien noch extremer) und sie wird unbenutzbar.

Weiter ist bereits Moros im aktuellen SSD-Test aufgefallen, dass Windows 7 scheinbar einen Bug in der Priorisierung der Zugriffe hat. Kopiert man eine einzige grosse Datei, so muss man selbst mit einer SSD zum Teil bis fast zum Ende der Kopieraktion warten, bis sie auf andere Zugriffe reagiert. Ich bin mir 100%ig sicher, dass dies im RC oder früheren Versionen noch nicht der Fall war.

Ich kann jedoch ohne Probleme Dinge von der 1. auf die 2. Daten (Non-OS-)Platte schieben, ohne dass das System irgendwie hängt. Sobald eine OS-HDD in's Spiel kommt ist aus die Maus.

Zum Vergrößern anklicken....

Das mit Windows 7 und dem Kopieren großer Dateien ist mir auch aufgefallen. Dann lahmt die SSD doch ziemlich, wobei sie natürlich immer noch eine bessere Figur abgibt, als eine normale HDD.

irgendwo hab ich gelesen, die SSDs unterstützen auch NCQ - ist das richtig?

Nachtrag: um es etwas zu präzisieren:
NCQ bedeutet ja, bis zu 32 Requests in der Device selbst ablegen zu können. Das mag ja auch bei SSDs Sinn machen.
Die Frage ist nur: Wird da auch an der Reihenfolge der Abarbeitung gedreht, zB bei Cache-Hits?

Ist ja auch die serielle Datenübertragung... ;-)

über diesen Link auf die heutzutage verwendeten Übertragungstechniken zu kommen, erscheint mir etwas mühsam
Da wäre dieser schon etwas näher dran

Ernst@at schrieb:

Die Frage ist nur: Wird da auch an der Reihenfolge der Abarbeitung gedreht, zB bei Cache-Hits?

Zum Vergrößern anklicken....

Genau das ist ja der Sinn von NCQ - einfach nur die Requests in die Queue zu schreiben und anschließend abzuarbeiten bringt rein gar nichts.