Hallo, bei uns läuft "dd" unter Kernel 2.0.36 und 2.2.3 seeeehr langsam (2 GByte Datei über eine Stunde). Wir nutzen dd, um Festplatten, Partitionen und DAT-Bänder in Dateien zu schreiben und vice versa. Gibt es ein ähnliches Programm, welches deutlich schneller arbeitet? Der Rechner (AMD K6 350 MHz, Festplatten 2 x 17 GByte, hdparm -t liefert 11MByte/Sek.) ist ausreichend schnell (unter DOS sehr schnell, dort aber leider nur max. 8GByte Platten :-( ). Wer kennt ein besseres Programm, eventuell sogar mit Verify Funktion? Gruß Thomas -- Um aus der Liste ausgetragen zu werden, eine Mail an majordomo@suse.com schicken, mit dem Text: unsubscribe suse-linux
On Mon, 29 Mar 1999, Thomas Schwarze wrote:
bei uns läuft "dd" unter Kernel 2.0.36 und 2.2.3 seeeehr langsam (2
Deine Info ist sehr duenn, aber das Problem scheint sich leicht beheben zu lassen, spiele mit der block size (bs=NNN). Eine kurze Schleife oefters zu durchlaufen, kostet nunmal den Verwaltungsaufwand fuer die Schleife ... Wenn Du die Platte MB-weise liest bzw beschreibst und dieser Kopierpuffer noch in den RAM passt, erwarte ich dramatische Steigerungen. Fange z.B. mit bs=1048576 an.
Wer kennt ein besseres Programm, eventuell sogar mit Verify Funktion?
Besser als dd? Fuer diesen Zweck kaum zu wollen ... Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. empty subject, richtext, vcard, HTML messages > /dev/null -- Um aus der Liste ausgetragen zu werden, eine Mail an majordomo@suse.com schicken, mit dem Text: unsubscribe suse-linux
Hallo Gerhard,
bei uns läuft "dd" unter Kernel 2.0.36 und 2.2.3 seeeehr langsam (2
Deine Info ist sehr duenn, aber das Problem scheint sich leicht beheben zu lassen, spiele mit der block size (bs=NNN). Eine kurze Schleife oefters zu durchlaufen, kostet nunmal den Verwaltungsaufwand fuer die Schleife ... Wenn Du die Platte MB-weise liest bzw beschreibst und dieser Kopierpuffer noch in den RAM passt, erwarte ich dramatische Steigerungen. Fange z.B. mit bs=1048576 an.
Wer kennt ein besseres Programm, eventuell sogar mit Verify Funktion?
Besser als dd? Fuer diesen Zweck kaum zu wollen ...
Gerhard Sittig
das haben wir ausprobiert bis bs=1024k, da ich denke, daß 1 Mbyte als Blockgröße schon nicht schlecht ist. Am RAM kanns auch nicht liegen, da die Rechner alle 128 MByte haben. Mit einem entsprechenden DOS-Programm, unter Windows gestartet, kommen wir auf ca. 2:30 Minuten für ein GByte, unter Linux mit dd etwa 20 x langsamer :-((( Hat jemand bessere Erfahrung mit dd gesammelt? Würde mich interessieren. Gruß Thomas -- Um aus der Liste ausgetragen zu werden, eine Mail an majordomo@suse.com schicken, mit dem Text: unsubscribe suse-linux
Thomas Schwarze wrote:
bei uns läuft "dd" unter Kernel 2.0.36 und 2.2.3 seeeehr langsam (2
Deine Info ist sehr duenn, aber das Problem scheint sich leicht beheben zu lassen, spiele mit der block size (bs=NNN). Eine kurze Schleife oefters zu durchlaufen, kostet nunmal den Verwaltungsaufwand fuer die Schleife ... Wenn Du die Platte MB-weise liest bzw beschreibst und dieser Kopierpuffer noch in den RAM passt, erwarte ich dramatische Steigerungen. Fange z.B. mit bs=1048576 an.
Wer kennt ein besseres Programm, eventuell sogar mit Verify Funktion?
Besser als dd? Fuer diesen Zweck kaum zu wollen ...
Gerhard Sittig
das haben wir ausprobiert bis bs=1024k, da ich denke, daß 1 Mbyte als Blockgröße schon nicht schlecht ist. Am RAM kanns auch nicht liegen, da die Rechner alle 128 MByte haben. Mit einem entsprechenden DOS-Programm, unter Windows gestartet, kommen wir auf ca. 2:30 Minuten für ein GByte, unter Linux mit dd etwa 20 x langsamer :-(((
hmm, 20x ist schon ein ziemlich hoher Faktor, könnte es sein, daß Deine Festplatte unter Linux nicht so richtig läuft, vielleicht Controller nicht unterstützt oder nur fehlerhaft? Probiere doch mal folgenden kleinen benchmark aus: ------------------------------------------------ #!/bin/sh # 200 MB-Datei anlegen, muß größer als der RAM sein wegen Cachewirkung, # wenn auf "/" keine 200MB mehr frei sind den Pfad entsprechend anpassen dd if=/dev/zero of=/testarea.dat bs=1024 count=204800 time dd if=/testarea.dat of=/dev/null rm /testarea.dat ------------------------------------------------ Vergleichswerte auf meinen Systemen: AMD K6-2 300 3dnow! 96MB RAM Adaptec 2940 AU Micropolis 9,1 GB (U-SCSI) Ermittelter Durchsatz: 7.8 MB/sec Lesen von hdb auf einem anderen Rechner: ADM K5 133 64MB RAM Onboard EIDE (kein U-DMA) IBM 10.1 GB (5400 U/min) 1GB lesen von /dev/hdb mit bs=4MByte: 6.5 MB/sec: rhb:~ # time dd if=/dev/hdb of=/dev/null bs=4194304 count=256 256+0 records in 256+0 records out real 2m37.174s user 0m0.010s sys 0m41.410s rhb:~ # Ich halte diese Werte für normal und würde von jedem halbwegs vergleichbaren System eine ähnliche Leistung erwarten. Ein Gedanke noch, der die Leistungsschwäche auf Deinem System erklären könnte: Du liest und schreibst ja gleichzeitig, wenn Du Platten clonst, d.h. der EIDE-Controller muß beide Datenströme verarbeiten (war doch EIDE, oder?) und auch der Prozessor hat bei EIDE viel Arbeit (jemand sagte mal: "Bei EIDE wird jedes Bit von der CPU per Handschlag begrüßt", bei SCSI erledigt die meiste Arbeit der Controller selbst.) -- Gruß Raphael Becker -- Um aus der Liste ausgetragen zu werden, eine Mail an majordomo@suse.com schicken, mit dem Text: unsubscribe suse-linux
Raphael Becker wrote:
96MB RAM
ram macht viel aus...nicht nur bei Linux ;) erfahrung zeit: manchmal ist mehr (neues) ram besser, als ein neuer schnellerer prozessor ;)
Du liest und schreibst ja gleichzeitig, wenn Du Platten clonst, d.h. der EIDE-Controller muß beide Datenströme verarbeiten (war doch EIDE, oder?) und auch der Prozessor hat bei EIDE viel Arbeit (jemand sagte mal: "Bei EIDE wird jedes Bit von der CPU per Handschlag begrüßt", bei SCSI erledigt die meiste Arbeit der Controller selbst.)
es gibt shit, und enhanced-shit ;))) sorry, couldnt resist ;)
Gruß Raphael Becker
-- Mfg. Joerg -- Henner & Bullinger, Datentechnik GbR | Tel.: +49 (7 11) 2 85 19 05 Linux, Netzwerke, Webhosting & Authoring | D2: +49 (1 72) 7 35 31 09 | Fax: +49 (7 11) 5 78 06 92 Geschäftsleitung, Perl/CGI, Support | <A HREF="http://www.star.bawue.com"><A HREF="http://www.star.bawue.com</A">http://www.star.bawue.com</A</A>> -- Um aus der Liste ausgetragen zu werden, eine Mail an majordomo@suse.com schicken, mit dem Text: unsubscribe suse-linux
Joerg Henner wrote:
Raphael Becker wrote:
96MB RAM
ram macht viel aus...nicht nur bei Linux ;)
Der RAM macht deshalb besobders viel aus, weil Daten möglichst lange im Speicher gehalten werden können (cache). Wenn aber die zu verabeitenden Daten mehr sind als der Speicher groß ist, dann wird eben keine Cachewirkung zu sehen sein. Angenommen es werden 100M Daten linear von hier nach da kopiert, und der Kernel stellt 60M Cache für Dateien bereit (weil er den Rest für sonstige Sachen verbraucht), dann sind nach 60M Kopiervorgang alle Daten im Cache. Es werden aber weitere 40M kopiert, der Kernel verwirft also schrittweise die alten Daten im Cache. Zum Schluß hat man (idealerweise) im Cache folgende Anordnung: "die letzten 40M der Datei" // "[40M-60M] der Datei" Der Anfang wurde überschrieben und ist nicht mehr im Cache. Wenn nun die Datei ein zweites mal zugegriffen wird, dann beginnt das Spiel von neuem: der Kernel beginnt wieder diese Datei zu lesen, beginnt aber mit dem Ablegen der Cacheinformationen dort, wo er vorher aufgehört hat. Bis er soweit ist die zweite Hälft zu lesen wurde der dazugehörige Cache überschrieben. Fazit: Es ist (fast) völlig egal, wieviel RAM man hat solange es weniger ist als die zu bearbeitenden Dateien groß sind, denn es wird zwar gecached aber die gecacheten Daten werden überschrieben noch bevor sie verwendet werden können. Solle ich mich so geirrt haben?? Wenn ja, nehme ich alles zurück und warte auf eine Erklärung, wie es wirklich ist. Möglicherweise wird beim direkten Zugriff auf "raw"-Devices kein Zugriff gecached, das würde diese Diskussion hier ohnehin überflüssig machen, mehr RAM wäre aber trotzdem unwirksam.
erfahrung zeit: manchmal ist mehr (neues) ram besser, als ein neuer schnellerer prozessor ;)
Ja, das stimmt schon aber in diesem Fall spielt RAM nur eine eher untergeordnete Rolle und selbst der Prozessor kommt mit vielleicht 7-9 MB/sec spielend zurecht. Mein K5/133 (ich habe es im xosview beobachtet) hatte nicht mal schubweise 100% Auslastung (jedenfalls nicht, als ich mit 4MB-Blocks kopiert habe). Nach einem GB Kopiervorgang war zwar die LOAD auf 1 aber die durchschnittliche CPU-ZEit (unterer Balken) war nie über 40 0ewesen. Der Flaschenhals ist hier immer noch die Festplatte bzw der Controller.
es gibt shit, und enhanced-shit ;))) sorry, couldnt resist ;) meinst Du damit deinen unpassenden Kommentar in die Liste?
Mfg. Joerg
-- Gruß Raphael Becker -- Um aus der Liste ausgetragen zu werden, eine Mail an majordomo@suse.com schicken, mit dem Text: unsubscribe suse-linux
On 30-Mar-99 Raphael Becker wrote:
Fazit: Es ist (fast) völlig egal, wieviel RAM man hat solange es weniger ist als die zu bearbeitenden Dateien groß sind, denn es wird zwar gecached aber die gecacheten Daten werden überschrieben noch bevor sie verwendet werden können.
Nicht ganz. Intelligente Cache-Algorithmen arbeiten nach einem "Last Recently Used"-Verfahren. Und beim Kopieren ist das Ganze z.B. eh egal, weil die I/O-Devices idR zu langsam sind. Cache bringt nur dann was, wenn wiederholt auf Daten zugegriffen wird und mit vielen relativ kleinen Datenblöcken gearbeitet wird. =========================================================== Erhard Schwenk - alias Bitrunner =)B==o) =========================================================== No Spam replies please. -- Um aus der Liste ausgetragen zu werden, eine Mail an majordomo@suse.com schicken, mit dem Text: unsubscribe suse-linux
Hallo Raphael,
Probiere doch mal folgenden kleinen benchmark aus:
------------------------------------------------
#!/bin/sh # 200 MB-Datei anlegen, muß größer als der RAM sein wegen Cachewirkung, # wenn auf "/" keine 200MB mehr frei sind den Pfad entsprechend anpassen dd if=/dev/zero of=/testarea.dat bs=1024 count=204800 time dd if=/testarea.dat of=/dev/null rm /testarea.dat
------------------------------------------------
Vergleichswerte auf meinen Systemen: AMD K6-2 300 3dnow! 96MB RAM Adaptec 2940 AU Micropolis 9,1 GB (U-SCSI) Ermittelter Durchsatz: 7.8 MB/sec
Lesen von hdb auf einem anderen Rechner: ADM K5 133 64MB RAM Onboard EIDE (kein U-DMA) IBM 10.1 GB (5400 U/min) 1GB lesen von /dev/hdb mit bs=4MByte: 6.5 MB/sec:
rhb:~ # time dd if=/dev/hdb of=/dev/null bs=4194304 count=256 256+0 records in 256+0 records out
real 2m37.174s user 0m0.010s sys 0m41.410s rhb:~ #
Ich halte diese Werte für normal und würde von jedem halbwegs vergleichbaren System eine ähnliche Leistung erwarten.
habe ich gleich ausprobiert und komme auf folgende Werte: Datei testarea.dat auf ext2fs real 0m23.953s user 0m5.160s sys 0m10.430s Datei testaread.dat auf VFAT (bei uns Standard, wegen der Zugriffsmöglichkeit unter Windows 98 für z.B. Quick View Plus): real 0m54.606s user 0m3.140s sys 0m11.250s So, wie es aussieht, ist die 14GByte VFat Partition der eine Hemmschuh (zumindest unter Linux). Als zweiten Grund habe ich inzwischen die nicht-DMA Unterstützung im Verdacht. Wir haben ein Asus P5A mit AMD K6-350 Proz. mit einem Alladin 1543 Chipsatz, der vom Kernel 2.0.36 bzw. 2.2.3 anscheinend nicht unterstützt wird. Des weiteren habe ich herausgefunden, daß auch beim cp oder anderen Kopieraktionen mittels mc der Rechner bei großen Dateien in die Knie geht. Dabei fängt er schnell an und wird dann immer langsamer, bis die Blöcke (am Leuchten der HD-Lampe zu erkennen) "einzeln über die Leitung getragen werden". Also alle Anschludigungen an dd zurückgenommen ;-) Gibt es dafür eine Erklärung oder besser eine Lösung ? (Bitte nicht DOS, das mit seinen 64 KByte Happen zwar schnell kopiert, aber sonst kleinere Mängel aufweist *g*). Gruß Thomas -- Um aus der Liste ausgetragen zu werden, eine Mail an majordomo@suse.com schicken, mit dem Text: unsubscribe suse-linux
Thomas Schwarze wrote: [Benchmark]
habe ich gleich ausprobiert und komme auf folgende Werte:
Datei testarea.dat auf ext2fs
8.6MB/sec (oder?)
Datei testaread.dat auf VFAT (bei uns Standard, wegen der Zugriffsmöglichkeit unter Windows 98 für z.B. Quick View Plus):
3.7MB/sec, das ist wohl nicht so viel :-)
So, wie es aussieht, ist die 14GByte VFat Partition der eine Hemmschuh (zumindest unter Linux).
okokok kommen wir zu dem zurück, was Du eigentlich wolltest. Wenn ich das richtig in Erinnerung habe willst Du doch ganze Partitionen kopieren/sichern, oder? Linux hat mit dem Dateisystem nichts zu tun denn es wird ja nur das pure Device kopiert/angefaßt ergo kann auch evtl. langsamer Dateisystemcode daran nicht schuld sein.
Als zweiten Grund habe ich inzwischen die nicht-DMA Unterstützung im Verdacht. Wir haben ein Asus P5A mit AMD K6-350 Proz. mit einem Alladin 1543 Chipsatz, der vom Kernel 2.0.36 bzw. 2.2.3 anscheinend nicht unterstützt wird.
Daran könnte es liegen. Ich kenne deine Hardware nicht aber wenn kein DMA unterstützt wird bzw läuft, dann ist das schon eine erhebliche Leistungsbremse.
Des weiteren habe ich herausgefunden, daß auch beim cp oder anderen Kopieraktionen mittels mc der Rechner bei großen Dateien in die Knie geht. Dabei fängt er schnell an und wird dann immer langsamer, bis die Blöcke (am Leuchten der HD-Lampe zu erkennen) "einzeln über die Leitung getragen werden". Also alle Anschludigungen an dd zurückgenommen ;-) Gibt es dafür eine Erklärung oder besser eine Lösung ? (Bitte nicht DOS, das mit seinen 64 KByte Happen zwar schnell kopiert, aber sonst kleinere Mängel aufweist *g*).
Ich habe sowas noch nie beobachtet und kann es daher auch nicht einschätzen. Da es aber unter DOS geht, sind wohl Hardwarefehler nicht beteiligt. Wie ist denn der Verlauf, wenn Du Dir gleichzeitig mit xosview (oder vergleichbaren CPU-Lastanzeigern) die Aktivität Deines Rechners betrachtest? Wird die CPU-Belastung im selben Maße geringer oder bleibt diese konstant? -- Gruß Raphael Becker -- Um aus der Liste ausgetragen zu werden, eine Mail an majordomo@suse.com schicken, mit dem Text: unsubscribe suse-linux
On Tue, 30 Mar 1999, Thomas Schwarze wrote:
bei uns läuft "dd" unter Kernel 2.0.36 und 2.2.3 seeeehr langsam (2
[ ... bs= erhoehen ... ]
das haben wir ausprobiert bis bs=1024k, da ich denke, daß 1 Mbyte als Blockgröße schon nicht schlecht ist. Am RAM kanns auch nicht liegen, da die Rechner alle 128 MByte haben. Mit einem entsprechenden DOS-Programm, unter Windows gestartet, kommen wir auf ca. 2:30 Minuten für ein GByte, unter Linux mit dd etwa 20 x langsamer :-(((
Das sind nicht zufaellig TX- oder VX-Boards? Denen hilft der ganze RAM herzlich wenig, wenn's mehr als 64 MB sind. Aber das sollte sich dann auf ALLES unter Linux auswirken. Der Festplattendurchsatz unter Linux ist generell schlecht? Oder nur mit dd? Ein wenig mehr Info waere tatsaechlich nicht schlecht. Sonst wird's nur ein heiteres Beruferaten ... Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. empty subject, richtext, vcard, HTML messages > /dev/null -- Um aus der Liste ausgetragen zu werden, eine Mail an majordomo@suse.com schicken, mit dem Text: unsubscribe suse-linux
participants (5)
-
beckerra＠rumms.uni-mannheim.de -
eschwenk＠fto.de -
Gerhard.Sittig＠gmx.net -
jhe＠star.bawue.com -
LKA364＠t-online.de