Angeregt vom Thread... Beitrag "Festplatte kopieren dauert endlos lange" ...habe ich heute eine kleine Meßreihe mit verschiedenen Kopierverfahren unter verschiedenen Betriebssystemen erstellt. Die Ergebnisse sind teilweise erstaunlich. Es gibt einen klaren Gewinner und einen ebenso klaren Verlierer, die beide dem selben Haus entstammen. Als Hardwarebasis diente mein Testrechner, bestückt mit Intel-CPU E8400, 4GB RAM und drei WD Velociraptor Festplatten (S-ATA im IDE-Mode). Eine der Platten beherbergte das jeweilige System, die anderen beiden wurden als Quell- bzw. Zielplatte dediziert und enthielten keinerlei andere Daten. Als Testdaten verwendete ich einen Ordner mit 93 realen Benutzerprofilen, der aus einer Datensicherung stammt. Der Ordner ist 2,54GB groß und enthält 62137 Dateien in 21121 Unterordnern. Es handelt sich ausschließlich um kleine Dateien im Bereich von einigen kByte bis wenigen MByte. Um Einflüsse des Platten-Caches auszuschließen, wurde der Rechner zwischen den Kopiervorgängen immer neu gestartet. Die Messung erfolgte händisch mit der Stoppuhr. Nachfolgend die Zahlen, angegeben sind das Betriebssystem, das Quell-/Zieldateisystem, das Kopierverfahren und die benötigte Zeit (Minuten:Sekunden): Windows XP, NTFS/NTFS, Explorer, 04:54 Windows XP, NTFS/NTFS, xcopy, 04:54 Windows XP, NTFS/NTFS, robocopy, 03:39 Windows 7 32-Bit, NTFS/NTFS, Explorer, 05:50 Windows 7 32-Bit, NTFS/NTFS, xcopy, 05:05 Windows 7 32-Bit, NTFS/NTFS, robocopy, 06:57 Ubuntu 12.04/Unity, ext4/ext4, GUI, 08:45 Ubuntu 12.04/Unity, ext4/ext4, Shell (cp -r), 01:16 debian-7.1.0-i386/Gnome, ext4/ext4, GUI, 08:26 debian-7.1.0-i386/Gnome, NTFS/ext4, GUI, 12:40 debian-7.1.0-i386/Gnome, ext4/ext4, Shell (cp -r), 01:18 debian-7.1.0-i386/Gnome, ext4/NTFS, Shell (cp -r), 02:39 debian-7.1.0-i386/Gnome, NTFS/NTFS, Shell (cp -r), 05:08 Einige Messungen wiederholte ich, weil sie nicht plausibel erschienen, die Zeiten waren jedoch reproduzierbar. Fazit: Wirklich beeindruckend schnell läuft das Kopieren unter Linux auf der Kommandozeile ab, wenn die Platten mit ext4 formatiert sind. Umso verwunderlicher erscheint die extreme Schnarchnasigkeit auf GUI-Ebene, welche das Klischee bedient, unter Linux könne man nur mit der Shell vernünftig arbeiten. MS hat beim Kopiertempo deutliche Rückschritte gemacht, der Explorer benötigt trotz deaktivierter Indizierung unter W7 ca. 20% mehr Zeit als unter XP. Ein absolutes Rätsel gibt mir robocopy unter Windows7 auf, braucht es doch fast doppelt so lange wie sein XP-Pendant. Die Ursache muß wohl in robocopy selbst zu suchen sein, denn xcopy ist nur unwesentlich langsamer als in XP.
Du solltest auch schreiben welche Hintergrundprogramme gelaufen sind und ob bei der GUI die Vorschau aktiviert war. Das GUI meistens langsamer ist liegt auf der Hand es muß ja andauernd der aktuelle Zustand im Fenster erneuert werden. NTFS ist anders aufgebaut als ext4, teste mal mit einem aktuellen XFS das sollte ext4 überholen.
Win7 braucht schon mal viel mehr Ram als XP. Damit bleibt weniger Platz für den Dateicache. Das könnte durchaus ein Grund sein warum XP schneller ist. Ich kopiere bei mir mit 16GB ram auch mal schnell eine 5GB datei in 2 sekunden. Sie wird halt später erst wirklich geschrieben.
cppler schrieb: > Du solltest auch schreiben welche Hintergrundprogramme gelaufen sind Natürlich gar keine, außer den standardmäßigen Systemprozessen. Alle Systeme im frisch installierten Zustand. > ob bei der GUI die Vorschau aktiviert war. > Das GUI meistens langsamer ist liegt auf der Hand es muß ja andauernd > der aktuelle Zustand im Fenster erneuert werden. Da ich den "umhüllenden" Ordner per DragnDrop kopiert habe, gab es außer dem Forschrittsbalken nix zu aktualisieren oder zu previewen. > teste mal mit einem aktuellen XFS Wird bei Gelegenheit nachgereicht.
Peter II schrieb: > Win7 braucht schon mal viel mehr Ram als XP. Damit bleibt weniger Platz > für den Dateicache. Das könnte durchaus ein Grund sein warum XP > schneller ist. Bei 4GB RAM und 2,54GB zu kopierenden Daten ist dies als Ursache eher unwahrscheinlich. Und erklärt auch nicht, weshalb robocopy plötzlich langsamer arbeitet als der Explorer. Peter II schrieb: > Ich kopiere bei mir mit 16GB ram auch mal schnell eine > 5GB datei in 2 sekunden. Sie wird halt später erst wirklich geschrieben. An der HDD-LED konnte ich den abgeschlossenen Vorgang gut erkennen, da wurde nichts mehr hinterhergeschrieben.
Das sind interessante Ergebnisse, danke für die Mühe. Ich hätte nicht gedacht, dass die Unterschiede so groß sind. Icke ®. schrieb: > debian-7.1.0-i386/Gnome, NTFS/ext4, GUI, 12:40 > debian-7.1.0-i386/Gnome, ext4/NTFS, Shell (cp -r), 02:39 War es Absicht, dass du die Dateien mit GUI in die eine, mit cp aber in die andere Richtung kopiert hast? Oder ist das nur in deinem Beitragstext versehentlich vertauscht? Für eine bessere Vergleichbarkeit zwischen GUI und cp wären Tests für debian-7.1.0-i386/Gnome, ext4/NTFS, GUI und/oder debian-7.1.0-i386/Gnome, NTFS/ext4, Shell (cp -r) noch interessant. Windows braucht ja üblicherweise vor dem eigentlichen Kopiervorgang eine gewisse Zeit, um das Kopieren "vorzubereiten". Da werden wohl sämtliche Dateigrößen ermittelt und zusammenaddiert, um beim Kopieren den Fortschritt darstellen zu können. Hast du noch in Erinnerung, wieviel Prozent diese "Vorbereitung" in Anspruch genommen hat und ob die GUIs unter Linux so etwas ebenfalls machen? Das würde zumindest einen Teil des Unterschieds zwischen GUI und cp bzw. xcopy erklären.
Yalu X. schrieb: > War es Absicht, dass du die Dateien mit GUI in die eine, mit cp aber in > die andere Richtung kopiert hast? Eigentlich wollte ich dort nur reines ext4 testen, weil es mir vordergründig um die Performanceunterschiede zwischen Linux und Windows ging. Das Kopieren von/auf NTFS habe ich dann nur der Neugier halber mit aufgenommen, weil die Daten vom vorangegangenen W7-Test ohnehin noch auf NTFS lagen. Aber ich kann die fehlenden Kombinationen gern nachreichen. Yalu X. schrieb: > Hast du noch in Erinnerung, wieviel > Prozent diese "Vorbereitung" in Anspruch genommen hat und ob die GUIs > unter Linux so etwas ebenfalls machen? Die GUI von Linux tut das ebenfalls, ja. Ich habe zwar nicht genau darauf geachtet, wieviel Zeit dies benötigt, es war jedoch nicht so viel, daß es die teilweise extremen Unterschiede ausmacht. Was mir auffiel, in der GUI von Linux schritt der Kopiervorgang zuerst sehr schnell voran, um dann bei ca. 40% stark nachzulassen. Es ist naheliegend, daß dies irgendwie mit dem Cache zu tun hat.
Interessant wäre noch ein Testlauf mit FAT32 als (Ziel-) Dateisystem. Und, um die allgemeine Schreibgeschwindigkeit der jeweils verwendeten Treiber zu ermitteln, ein weiterer Testlauf mit wenigen, aber sehr großen Dateien (à 1 GB o.ä.), was den Dateisystemoverhead etwas reduzieren helfen sollte. Bei den NTFS-Kopieraktionen wäre als nächste Variante noch das Aktivieren der Dateikompression interessant - und das auch in der Variante, daß Quelle und Ziel komprimiert sind.
Icke ®. schrieb: > Was mir auffiel, in der GUI von Linux schritt der Kopiervorgang zuerst > sehr schnell voran, um dann bei ca. 40% stark nachzulassen. Es ist > naheliegend, daß dies irgendwie mit dem Cache zu tun hat. Das ist besonders eine Pest beim kopieren auf USB-Sticks... 98% geht in wenigen Sekunden und danach kann man dann warten...warten...warten... Yalu X. schrieb: > GUIs unter Linux so etwas ebenfalls machen Gnome "macht" das auch, das dauert besonders bei vielen kleinen und verschachtelten Dateien oft länger als der Kopiervorgang... man müsste mal schauen ob das abschaltbar ist.
Vorweg muß ich ein Ergebnis von gestern korrigieren, der Wert von robocopy unter XP ist nicht korrekt. Ich war wohl vom Telefon abgelenkt und vergaß den Rechner neu zu starten, sodaß der Cache Einfluß hatte. Nochmals getestet und nachvollziehbar benötigt robocopy unter XP 04:56 und nicht, wie fälschlich angegegeben, 03:39. Auf Wunsch heute noch Zahlen zu weiteren Kombinationen: Windows XP, NTFS/FAT32, Explorer, 05:56 Windows XP, NTFS/FAT32, xcopy, 05:34 Windows XP, NTFS/FAT32, robocopy, 05:23 Windows 7 32-Bit, NTFS/FAT32, Explorer, 06:30 Windows 7 32-Bit, NTFS/FAT32, xcopy, 06:03 Windows 7 32-Bit, NTFS/FAT32, robocopy, 07:56 debian-7.1.0-i386/Gnome, ext4/NTFS, GUI, 09:52 debian-7.1.0-i386/Gnome, ext4/FAT32, GUI, 10:09 debian-7.1.0-i386/Gnome, FAT32/ext4, GUI, 10:22 debian-7.1.0-i386/Gnome, ext4/FAT32, Shell (cp -r), 02:15 debian-7.1.0-i386/Gnome, FAT32/ext4, Shell (cp -r), 00:58 ! debian-7.1.0-i386/Gnome, NTFS/ext4, Shell (cp -r), 03:30 Desweiteren wanderte ein 2GB großes AVI-File hin und her. Zwischen NTFS/NTFS und NTFS/FAT32 unter Windows XP/7 sowie ext4/ext4, ext4/FAT32 und ext4/NTFS unter Debian. Bis auf zwei Ausreißer lag die benötigte Zeit UNABHÄNGIG von OS, Dateisystem oder Kopiermechanismus stets um die 18 Sekunden (+/- 1s). Lediglich in der Kombi ext4/NTFS wich die Zeit deutlich ab, die Linux-GUI brauchte 50 und die Shell 39 Sekunden. Die sich aus den 18s ergebende Transferrate von 111MB/s liegt damit nur knapp unter dem für die WD3000HLFS spezifizierten Maximum von 126MB/s. Die Vorbereitung des Kopiervorganges dauert unter Windows 20-25s und in der Linux GUI 30-35s. Trotzdem ist der Windows-Explorer insgesamt nicht oder nur unwesentlich später fertig als die Kommandozeilen-Tools. Unter Linux sollte man dagegen für das Kopieren großer Bestände mit vielen kleinen Dateien besser die Shell nutzen. Ich bitte um Verständnis, daß ich aus Zeitgründen nicht alle denkbaren Kombinationen testen kann, deswegen solls das erst einmal gewesen sein ;-)
Icke ®. schrieb: > Auf Wunsch heute noch Zahlen zu weiteren Kombinationen: Danke! Und die Resultate sind ... interessant: > Windows XP, NTFS/NTFS, Explorer, 04:54 > Windows 7 32-Bit, NTFS/NTFS, Explorer, 05:50 > Windows XP, NTFS/FAT32, Explorer, 05:56 > Windows 7 32-Bit, NTFS/FAT32, Explorer, 06:30 Das Beschreiben von FAT32 scheint also langsamer zu sein als das von NTFS, zumindest, wenn MS das macht. Nutzt die NTFS-Partition Kompression?
Rufus Τ. Firefly schrieb: > Nutzt die NTFS-Partition Kompression Eventuell ist man da das schreiben schon "abgeschlossen" wenn die Aktion im Journal landet und der Rest passiert im Hintergrund und unbemerkt.
Icke ®. schrieb: > Wirklich beeindruckend schnell läuft das Kopieren unter Linux auf der > Kommandozeile ab, wenn die Platten mit ext4 formatiert sind. Naja, du müsstest wohl der Fairness halber anschließend noch ein “sync” ausführen bzw. was auch immer dafür das Äquivalent in Windows wäre, und erst nach dessen Abschluss die Uhr anhalten. Erst dann sind ja alle Daten auf der Platte. Schließlich passen deine zu kopierenden 2,5 GiB bei einem mit 4 GiB ausgestatteten Rechner ja komplett in den Speicher und damit in den Cache.
Vergleich MS-Linux: War bei MS ein Virenscanner aktiv? (als Bremse)
Icke ®. schrieb: > und drei WD Velociraptor Festplatten (S-ATA im IDE-Mode). Warum denn das? Der IDE-Modus ist meines Wissens langsamer und kann vor allem kein NCQ.
ich suche Ergebniss für Netware 6.5. Alles ab 40-50 GB aufwärts. Weil es dann rapide bergab geht. Das alte Novell Problem.
Rufus Τ. Firefly schrieb: > Nutzt die NTFS-Partition Kompression? Nein. Indizierung ebenfalls deaktiviert. Jörg Wunsch schrieb: > Naja, du müsstest wohl der Fairness halber anschließend noch ein > “sync” ausführen bzw. was auch immer dafür das Äquivalent in Windows > wäre, und erst nach dessen Abschluss die Uhr anhalten. Erst dann > sind ja alle Daten auf der Platte. Zumindest erlosch auch die HDD-LED nach Abschluß des Kopierens oder spätestens 2-3 Sekunden später. > Schließlich passen deine zu kopierenden 2,5 GiB bei einem mit 4 GiB > ausgestatteten Rechner ja komplett in den Speicher und damit in den > Cache. Wie ich schon oben schrieb, verlangsamte sich der Kopierfortschritt in der Linux GUI nach ca. 40% dramatisch. Heute beobachtet, immer so ziemlich genau nach einem Gigabyte, obwohl das System genug RAM frei hätte, um die kompletten Daten in den Cache zu schreiben. Offensichtlich wird der aber nicht genutzt. oszi40 schrieb: > War bei MS ein Virenscanner aktiv? Nein. Rolf Magnus schrieb: > Warum denn das? Der IDE-Modus ist meines Wissens langsamer und kann vor > allem kein NCQ. Aus Kompatibilitätsgründen und weil es für den Vergleich keine Rolle spielt, da alle OSse damit auskommen müssen. WinXP besitzt keinen eigenen AHCI-Treiber, man müßte den von Intel installieren, der wiederum die Messung beeinfluusen könnte. Nichtsdestotrotz habe ich außer der Reihe mal den AHCI-Mode unter W7 ausprobiert. Überraschenderweise wurde es jedoch nicht schneller, sondern langsamer!
Stephan Henning schrieb: > Weil es dann rapide bergab geht. > Das alte Novell Problem. Mit Novell ging es doch schon in den 90ern rapide bergab =8P Nee, damit habe ich im letzten Jahrtausend das letzte Mal gearbeitet.
:
Bearbeitet durch User
bin gerade dabei ca. 200GB Daten von einem Novell Server runter zu kopieren. Nach ca. 40-50 GB ging dann alles in den Ersten Gang mit 1-2 MB/Sek. Ja, da muss der Client PC wohl ne Nachtschicht schieben. Das Problem hatte aber schon Netware 4 und 5. Directory und File Buffers sind am oberen Anschlag. Kennt jemand das Problem und hat eine Lösung gefunden ? In diesem Fall ist es ja eigentlich reines Streaming. Womit der Cache des Raid Controllers ehr hinderlich ist. Intel hat es leider nicht vorgesehen den Hardwarecache des Raid Controllers abschalten zu können. Danke
:
Bearbeitet durch User
Stephan Henning schrieb: > bin gerade dabei ca. 200GB Daten von einem Novell Server runter zu > kopieren. > Nach ca. 40-50 GB ging dann alles in den Ersten Gang mit 1-2 MB/Sek. > Ja, da muss der Client PC wohl ne Nachtschicht schieben. > Das Problem hatte aber schon Netware 4 und 5. > Directory und File Buffers sind am oberen Anschlag. > > Kennt jemand das Problem und hat eine Lösung gefunden ? Das einfachste wäre wohl wenn Du ein Skript schreibst das immer nur <40GB kopiert und dann zu den nächsten 40GB übergeht.
Icke ®. schrieb: > debian-7.1.0-i386/Gnome, FAT32/ext4, Shell (cp -r), 00:58 ! Kann es sein, dass das so schnell ist, weil bei FAT32 nicht die Zeit des letzten Zugriffs gespeichert wird? Evlt. könnte man die FAT32->ext4 -Zeit mit > debian-7.1.0-i386/Gnome, ext4/ext4, Shell (cp -r) und mit der mount-option "noatime" noch toppen.. ( http://wiki.ubuntuusers.de/tuning#Bei-einer-ext3-oder-ext4-Partition )
:
Bearbeitet durch User
Simon S. schrieb: > Kann es sein, dass das so schnell ist, weil bei FAT32 nicht die Zeit des > letzten Zugriffs gespeichert wird? Das kann bei NTFS abgeschaltet werden: http://technet.microsoft.com/en-us/library/cc959914.aspx
Simon S. schrieb: > Kann es sein, dass das so schnell ist, weil bei FAT32 nicht die Zeit des > letzten Zugriffs gespeichert wird? Da FAT(32) kein Journaling File System ist, gibt es ohnehin weniger zu schreiben. Wäre also logisch, daß es schneller ist. Daß Windows darauf langsamer zugreift, ist wiederum nicht logisch. Keine Ahnung, warum. Eine mögliche Erklärung könnte sein, daß bei NTFS sehr kleine Dateien direkt in der MFT gespeichert werden, was natürlich Zeit spart.
Wie ich im Fred "Festplatte kopieren dauert endlos lange" schon anmerkte, kann man xcopy mit einer erhoehten Prioritaet deutlich Beine machen. Es darf auch gern "Realtime" sein. Zumindest hat es bei mir das Kopieren einer (1,5 TB) USB-Platte auf eine 2. USB-Platte deutlich beschleunigt (WinXPSP3). Ausserdem kann man sich mit den ueblichen Umlenkungsmechanismen ein Log-File erzeugen.
Stephan Henning schrieb: > Kennt jemand das Problem und hat eine Lösung gefunden ? Ja und nein. Ja, ich kenne das Problem von Netware 3 und 4. Nein, ich habe trotz Drehen an allen möglichen Parametern auch keine Lösung gefunden. Da seinerzeit gerade das Internet aufkam und Linux mit Samba bessere TCP/IP-Unterstützung bot sowie damit die leidigen Novell-Clients obsolet wurden, verbannte ich IPX endgültig aus meinen Netzen.
Icke ®. schrieb: > Stephan Henning schrieb: >> Kennt jemand das Problem und hat eine Lösung gefunden ? > > Ja und nein. Ja, ich kenne das Problem von Netware 3 und 4. Nein, ich > habe trotz Drehen an allen möglichen Parametern auch keine Lösung > gefunden. > Da seinerzeit gerade das Internet aufkam und Linux mit Samba bessere > TCP/IP-Unterstützung bot sowie damit die leidigen Novell-Clients obsolet > wurden, verbannte ich IPX endgültig aus meinen Netzen. naja IPX ist wirklich obsolete. IP ging aber schon für Routing unter 4 und im Filesystem ab 5. Hilft mir aber auch nicht, außer Nachtschicht des Client :-)))) Danke
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.