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

Gelegentlich habe ich Kommentare online gesehen, die lauten: "Stellen Sie sicher, dass Sie 'bs =' setzen, da der Standardwert zu lange dauert." Zeit letzte Woche "scheinen das zu belegen. Wenn ich 'dd' verwende (normalerweise im Bereich von 1-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. den Rest der Zeit wähle ich eine Nummer aus der 'fdisk -l'-Liste, von der ich annehme, dass sie langsamer ist (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 einen einfachen Weg, um 90-95% des Weges dorthin zu bekommen? Oder ist "nur etwas größer als 512 auswählen" sogar die richtige Antwort?

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

ddstammt aus der Zeit, als es für die Übersetzung alter IBM-Mainframe-Bänder erforderlich war, und die Blockgröße musste mit der übereinstimmen, die zum Schreiben des Bandes verwendet wurde, oder Datenblöcke wurden übersprungen oder abgeschnitten. (9-Spur-Bänder waren heikel. Seien Sie froh, dass sie lange tot sind.) Heutzutage sollte die Blockgröße ein Vielfaches der Größe des Gerätesektors sein (normalerweise 4 KB), aber auf neueren Festplatten können sie viel größer sein und einen sehr kleinen Daumen haben 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 1MB Blockgrößen mit Festplatten. (Wir haben heutzutage auch viel mehr Gedächtnis.)

Es gibt nur einen Weg, die optimale Blockgröße zu bestimmen, und das ist ein Maßstab. Ich habe gerade einen kurzen Benchmark gemacht. Die Testmaschine ist ein PC, auf dem Debian GNU / Linux mit Kernel 2.6.32 und Coreutils 8.5 ausgeführt wird. Beide beteiligten Dateisysteme sind ext3 auf LVM-Volumes auf einer Festplattenpartition. Die Quelldatei hat eine Größe von 2 GB (2040000 KB, um genau zu sein). Caching und Pufferung sind aktiviert. Vor jedem Lauf habe ich den Cache mit geleert sync; echo 1 >|/proc/sys/vm/drop_caches. Die Laufzeiten enthalten kein Finale synczum Leeren der Puffer. Das Finale syncdauert in der Größenordnung von 1 Sekunde. Die sameLäufe waren Kopien auf demselben Dateisystem; Die diffLäufe waren Kopien in ein Dateisystem auf einer anderen Festplatte. Aus Gründen der Konsistenz sind die angegebenen Zeiten die mit der. Erhaltenen WanduhrzeitentimeNutzen, in Sekunden. Ich habe jeden Befehl nur einmal ausgeführt, daher weiß ich nicht, wie stark das Timing variiert.

             same   diff
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 catund cpnicht so schlecht abschneiden. Mit diesen Zahlen finde ich es nicht ddwert , mich damit zu beschäftigen. Geh mit cat!

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

Wenn Sie die Blockgröße finden möchten, stat -c "%o" filenameist dies wahrscheinlich die einfachste Option.

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

Jeder Systemaufruf ist mit einem Kontextwechsel verbunden, der mit einem gewissen Aufwand verbunden ist. Je nach E / A-Planer können Lesevorgänge mit dazwischenliegenden Schreibvorgängen dazu führen, dass die Festplatte viele Suchvorgänge ausführt. (Wahrscheinlich kein großes Problem mit dem Linux-Scheduler, aber dennoch ein Grund zum Nachdenken.)

Wenn Sie dies tun bs=8K, lassen Sie die Festplatte zwei Blöcke gleichzeitig lesen, die sich wahrscheinlich nahe beieinander auf der Festplatte befinden, bevor Sie den Schreibvorgang an einer anderen Stelle ausführen (oder die E / A für einen anderen Prozess warten).

Nach dieser Logik bs=16Kist noch besser, etc.

Ich würde also gerne wissen, ob es eine Obergrenze gibt, an der die Leistung schlechter wird, oder ob sie nur durch das Gedächtnis begrenzt ist.

Wie Gilles sagt, können Sie den optimalen Parameter für die Option bs to 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 :)

Ich optimiert für SD-Kartenleser USB2.0, die am besten zu laufen scheint bs=10M. Ich habe versucht 4k, auf bis zu 16M, nach 8-10M keine Besserung. Sie können sehen, wie sich die Übertragungsrate verschlechtert. Dies liegt wahrscheinlich daran, dass die Puffer auf dem Gerät geladen werden und darauf gewartet wird, dass das Gerät auf das eigentliche Medium übertragen wird.

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