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