it-swarm.com.de

Gibt es eine Möglichkeit, den optimalen Wert für den Parameter bs für dd zu bestimmen?

Gelegentlich habe ich online Kommentare gesehen, die lauten: "Stellen Sie sicher, dass Sie 'bs =' setzen, da der Standardwert zu lange dauert", und meine eigenen äußerst unwissenschaftlichen Erfahrungen mit "Nun, das schien länger zu dauern als der andere." Zeit letzte Woche "scheinen das zu bestätigen. Wenn ich also 'dd' verwende (normalerweise im Bereich von 1 bis 2 GB), muss der Parameter bytes angegeben werden. Ungefähr die Hälfte der Zeit verwende ich den Wert, der in dem Online-Handbuch angegeben ist, aus dem ich kopiere. In der restlichen Zeit werde ich eine Nummer auswählen, die aus der Liste 'fdisk -l' sinnvoll ist, da ich davon ausgehe, dass es sich um das langsamere Medium handelt (z. B. die SD-Karte, auf die ich schreibe).

Gibt es für eine bestimmte Situation (Medientyp, Busgröße oder was auch immer wichtig ist) eine Möglichkeit, einen "besten" Wert zu ermitteln? Ist es leicht zu bestimmen? Wenn nicht, gibt es eine einfache Möglichkeit, 90-95% des Weges dorthin zu erreichen? Oder ist "wähle einfach etwas Größeres als 512" sogar die richtige Antwort?

Ich habe darüber nachgedacht, das Experiment selbst auszuprobieren, bin mir aber nicht nur sicher, welche Faktoren die Antwort beeinflussen, sondern weiß auch nicht, wie ich ein gutes Experiment entwerfen soll.

74
user4443

dd stammt aus der Zeit, als alte IBM Mainframe-Bänder übersetzt werden mussten, und die Blockgröße musste mit der zum Schreiben des Bandes verwendeten übereinstimmen, oder Datenblöcke wurden übersprungen oder abgeschnitten. (9-Spur-Bänder waren pingelig. Seien Sie froh, dass sie schon lange tot sind.) Heutzutage sollte die Blockgröße ein Vielfaches der Größe des Gerätesektors betragen (normalerweise 4 KB, aber auf neueren Festplatten kann sie viel größer und auf einem sehr kleinen Daumen sein Laufwerke mögen kleiner sein, aber 4 KB sind ein vernünftiger Mittelweg, und je größer, desto besser für die Leistung. Ich verwende oft 1 MB Blockgrößen mit Festplatten. (Wir haben heutzutage auch viel mehr Gedächtnis.)

29
geekosaur

Es gibt nur einen Weg, um die optimale Blockgröße zu bestimmen, und das ist ein Maßstab. Ich habe gerade einen schnellen Benchmark gemacht. Die Testmaschine ist ein PC mit Debian GNU/Linux mit Kernel 2.6.32 und Coreutils 8.5. Beide beteiligten Dateisysteme sind ext3 auf LVM-Volumes auf einer Festplattenpartition. Die Quelldatei ist 2 GB (um genau zu sein 2040000kB). Caching und Pufferung sind aktiviert. Vor jedem Lauf habe ich den Cache mit sync; echo 1 >|/proc/sys/vm/drop_caches Entleert. Die Laufzeiten enthalten kein endgültiges sync zum Leeren der Puffer. Das endgültige sync nimmt eine Größenordnung von 1 Sekunde an.

Die same - Läufe waren Kopien auf demselben Dateisystem. Die diff - Läufe waren Kopien in ein Dateisystem auf einer anderen Festplatte. Aus Gründen der Konsistenz sind die angegebenen Zeiten die Wanduhrzeiten, die mit dem Dienstprogramm time in Sekunden ermittelt wurden. Ich habe jeden Befehl nur einmal ausgeführt, daher weiß ich nicht, wie unterschiedlich das Timing ist.

             same   diff
             t (s)  t (s)
dd bs=64M    71.1   51.3
dd bs=1M     73.9   41.8
dd bs=4k     79.6   48.5
dd bs=512    85.3   48.9
cat          76.2   41.7
cp           77.8   45.3

Fazit : Eine große Blockgröße (mehrere Megabyte) hilft, aber nicht dramatisch (viel weniger als ich für Kopien mit demselben Laufwerk erwartet hatte). Und cat und cp schneiden nicht so schlecht ab. Mit diesen Zahlen finde ich dd nicht lohnenswert. Gehen Sie mit cat!

Ich stimme Geekosaurier zu, dass die Größe ein Vielfaches der Blockgröße sein sollte, die oft 4 KB beträgt.

Wenn Sie die Blockgröße ermitteln möchten, ist stat -c "%o" filename Wahrscheinlich die einfachste Option.

Aber sagen Sie, Sie tun dd bs=4K, Das heißt, es tut read(4096); write(4096); read(4096); write(4096)...

Jeder Systemaufruf beinhaltet einen Kontextwechsel, der einen gewissen Overhead mit sich bringt. Abhängig vom E/A-Scheduler können Lesevorgänge mit eingestreuten Schreibvorgängen dazu führen, dass die Festplatte viele Suchvorgänge ausführt. (Wahrscheinlich kein großes Problem mit dem Linux-Scheduler, aber dennoch etwas zum Nachdenken.)

Wenn Sie also bs=8K Ausführen, können Sie der Festplatte erlauben, zwei Blöcke gleichzeitig zu lesen, die wahrscheinlich nahe beieinander auf der Festplatte liegen, bevor Sie nach einem anderen Ort suchen, um das Schreiben durchzuführen (oder E/A für einen anderen Prozess zu warten) ).

Nach dieser Logik ist bs=16K Noch besser usw.

Ich würde gerne wissen, ob es eine Obergrenze gibt, an der sich die Leistung verschlechtert, oder ob sie nur durch den Speicher begrenzt ist.

8
Mikel

Wie Gilles sagt, können Sie den optimalen Parameter für die Option bs bis dd durch Benchmarking bestimmen. Dies wirft jedoch die Frage auf: Wie können Sie diesen Parameter bequem bewerten?

Meine vorläufige Antwort auf diese Frage lautet: benutze dd-opt , das Dienstprogramm, an dem ich kürzlich gearbeitet habe, um genau dieses Problem zu lösen :)

5
sampablokuper

Ich habe für den SD-Kartenleser usb2.0 optimiert, der bei bs=10M Am besten zu laufen scheint. Ich habe 4k auf bis zu 16M ausprobiert, nach 8-10M keine Verbesserung. Sie können sehen, wie sich die Messung der Übertragungsrate verschlechtert ... höchstwahrscheinlich aufgrund des Ladens der Puffer auf dem Gerät und des Wartens auf die Übertragung des Geräts auf das eigentliche Medium.

angstrom/sdcard# dd if=/dev/zero of=/dev/sdb bs=10M
123+0 records in
123+0 records out
1289748480 bytes (1.3 GB) copied, 21.4684 s, 60.1 MB/s
341+0 records in
341+0 records out
3575644160 bytes (3.6 GB) copied, 117.636 s, 30.4 MB/s
816+0 records in
816+0 records out
8556380160 bytes (8.6 GB) copied, 326.588 s, 26.2 MB/s
955+0 records in
955+0 records out
10013900800 bytes (10 GB) copied, 387.456 s, 25.8 MB/s
0
wwright