Kleine Dateien schnell kopieren (Windows)
-
Hallo Leute.
Gibt es eine Möglichkeit kleine Dateien sehr schnell zu kopieren?
Das Problem ist, dass wir etwa 350GB mit etwa 2mio Dateien haben. dh eine durchschnitts Datei ist wirklich klein, die meisten haben unter 10K.Das kopieren der Dateien dauert mit xcopy einfach ewig. Gibt es Tools die das kopieren von so kleinen Dateien schneller hinbekommen? RAM steckt in der Maschine genug um ordentlich cachen zu können...
Irgendwelche Ideen?
Danke schonmal
-
Hmm, vielleicht alles in ein Tarball stecken, und so alles in einem Block kopieren. Aber das Problem der vielen, fragmentierten Zugriffe bleibt natürlich auch beim Schnüren des Tarballs bestehen.
-
Das letztere Problem könnte man durch Verteilung der Lese- und Schreibzugriffe zumindest etwas reduzieren. Erfahrungsgemäß lässt sich damit gerade bei vielen kleinen Dateien - zumindest unter UNIX - einiges rausholen. Ich würde allerdings den MinGW-Tar, nicht etwa den Cygwin-Tar verwenden.
Etwa
tar cf - . | ( cd /c/Zielpfad; tar xf - )
-
Auf der Tar for Windows Seite wird BSD Tar wegen der Performance empfohlen. Vielleicht wäre das also auch was.
-
gibt ein tool namens teracopy, das schnelleres kopieren verspricht. habs bisher nur mit großen dateien ausprobiert, da war es doppelt so schnell wie das normale filecopy von windows.
-
meine erfahrungen sind auch so in etwa. zip, unzip ist oft das schnellste. besonders ueber netzwerk.
manchmal bringt es auch was den rechner vom netz zu trennen. (ich glaube die meiste zeit geht beim rechte und AV drauf).
-
Wie man das mit fertigen Tools hinbekommt weiss ich nicht, ich weiss nur was ich probieren würde wenn ich es selbst implementieren würde: Mehrere Threads die die Dateien in einen Puffer einlesen + mehrere Threads die die Dateien da wieder rausschreiben. Beim schreiben evtl. auch nur ein Thread, müsste man ausprobieren was schneller ist. Hintergedanke ist dass das Storage-System (Treiber, Platten-Controller etc.) die Zugriffe besser optimieren kann wenn mehrere Zugriffe gleichzeitig ausständig sind (NCQ, sortieren der Zugriffe im Treiber etc.).
Ob und wieviel es bringt müsste man natürlich ausprobieren.Und wenn ein Netzwerk im Spiel ist bin ich auch fast sicher dass es schneller ist eine grosse Datei übers Netz zu kopieren und die am anderen Ende dann wieder zu "zerteilen".
-
350GB ?
wo willste die hinkopieren, das ist doch pervers! :p 
ansonsten:
raid - redundant array of independent disks
-
Die 350GB will ich von einer Platte auf eine andere im selben Rechner schaufeln. Sind ja 750GB Platten, also genug Platz. Irgendwann kommen schnellere Platten rein...
Habe jetzt über nacht FastCopy getestet und es ist um 25% schneller als xcopy und robocopy. tar/zip gefällt mir insofern etwas weniger, da dann der Zugriff auf die kopierten Daten umständlich wird. Dank FastCopy ist das Problem jetzt aber erstmal behoben.
Danke jedenfalls
-
Shade Of Mine schrieb:
Habe jetzt über nacht FastCopy getestet und es ist um 25% schneller als xcopy und robocopy. tar/zip gefällt mir insofern etwas weniger, da dann der Zugriff auf die kopierten Daten umständlich wird. Dank FastCopy ist das Problem jetzt aber erstmal behoben.
Danke jedenfalls
Der Tar-Vorschlag oben wird doch nur für on-the-fly Übertragung verwendet, der erste Tar-Befehl gibt das Tar-Paket auf stdout aus und das zweite nimmt ein Tar-Paket auf stdin entgegen und entpackt es direkt wieder.
Und der Zip/Unzip Vorschlag war genau so gemeint, wenn ich das richtig interpretiere.
-
Sys-Admin schrieb:
Der Tar-Vorschlag oben wird doch nur für on-the-fly Übertragung verwendet, der erste Tar-Befehl gibt das Tar-Paket auf stdout aus und das zweite nimmt ein Tar-Paket auf stdin entgegen und entpackt es direkt wieder.
Und der Zip/Unzip Vorschlag war genau so gemeint, wenn ich das richtig interpretiere.und was genau würde dass dann bringen?
das problem ist der overhead den ich per datei habe - und das ist bei ein paar millionen dateien schon recht viel.
die übertragung der rohen daten selber ist kein problem. das ganze läuft auch nicht über das netzwerk, deshalb lohnt komprimierung wohl eher nicht.
-
Shade Of Mine schrieb:
Sys-Admin schrieb:
Der Tar-Vorschlag oben wird doch nur für on-the-fly Übertragung verwendet, der erste Tar-Befehl gibt das Tar-Paket auf stdout aus und das zweite nimmt ein Tar-Paket auf stdin entgegen und entpackt es direkt wieder.
Und der Zip/Unzip Vorschlag war genau so gemeint, wenn ich das richtig interpretiere.und was genau würde dass dann bringen?
das problem ist der overhead den ich per datei habe - und das ist bei ein paar millionen dateien schon recht viel.
die übertragung der rohen daten selber ist kein problem. das ganze läuft auch nicht über das netzwerk, deshalb lohnt komprimierung wohl eher nicht.
Die Hoffnung, dass Tar performant im Umgang mit vielen Dateien ist (was es tatsächlich ist) und es dem Betriebssystem ermöglicht effizient(er) die Daten von der Platte zu lesen.
