Diskussion:Dd (Unix)

Statusabfrage während des Vorganges

Es gibt gab einen Trick, mit dem man den Zwischenstand der Kopieroperation ausgeben lassen konnte. Kennt jemand den zufällig gerade?
(Der vorstehende Beitrag stammt von 217.237.149.206 – 13:51, 23. Jun. 2007 (MESZ) – und wurde nachträglich unterschrieben.)

Es gibt diverse Tools, die die Daten zählen, die durch eine Pipe laufen. Was du suchst ist eventuell

dd <quelle |pv >ziel
cat <quelle |pv >ziel

oder kurz

pv <quelle >ziel

quelle und ziel können beliebige Dateien sein (auch Gerätedateien).

(Der vorstehende Beitrag stammt von Kn0rke (Beiträge) – 20:01, 20. Nov. 2007 (MEZ) – und wurde nachträglich unterschrieben.)

Man Page:

Schickt man einem laufenden „dd“-Prozess ein USR1-Signal, gibt dieser
auf der Standardfehlerausgabe Eingabe-/Ausgabe-Statistiken aus und fährt
mit dem Kopieren fort.

  $ dd if=/dev/zero of=/dev/null& pid=$!
  $ kill -USR1 $pid; sleep 1; kill $pid

(Der vorstehende Beitrag stammt von 89.60.214.38 – 14:08, 30. Nov. 2007 (MEZ) – und wurde nachträglich unterschrieben.)

Ja, das Tool heisst pv (Pipe View) http://www.ivarch.com/programs/pv.shtml.

(Der vorstehende Beitrag stammt von 217.113.176.185 – 00:09, 26. Dez. 2007 (MEZ) – und wurde nachträglich unterschrieben.)

Mittlerweile bietet dd in der GNU-Coreutils-Version eine Statusanzeige: status=progress. Vielleicht spricht sich das jetzt mal rum. --Raumhafen (Diskussion) 15:36, 30. Apr. 2016 (CEST)

Laut Ubuntuwiki seit Version 8.24. --93.233.179.49 14:55, 26. Jan. 2018 (CET)

Mythos dd

Ich habe den dd-Artikel korrigiert und vom großen dd-Mythos befreit. Leider wurde die Änderung rückgängig gemacht. Ich möchte nun hier eine Diskussion starten, die mir und anderen helfen soll, den Artikel korrekt und leicht verständlich zu halten.
Mein Anliegen ist es, den dd-Mythos zu entkräften und eben NICHT durch die Wikipedia noch zu verstärken. Es gibt eben KEINEN faktischen Unterschied zwischen dd und cp und cat, wenn es um das Kopieren(!) von Dateien ODER Gerätedateien geht. Dies ist nicht nur durch logisches Nachdenken, Codereviews und strace nachvollziehbar, sondern auch durch Hinterfragen des Mythos "dd als Gerätekopiertool".
Anmerkungen, Kritik, Anfragen, etc. beantworte ich sehr gern. Ich bitte die korrekte und entmystifizierte Version des Artikels nicht rückgängig zu machen sondern lediglich zu verbessern! Danke. schrub kn0rke 20:53, 20. Nov. 2007 (CET)

Es gibt definitiv einen wesentlichen Unterschied zwischen dd und den Pfeilchen! <> liefert:

sudo gzip -c < /dev/sda1 > sda1.img.gz
bash: /dev/sda1: Permission denied

und dd liefert:

sudo dd if=/dev/sda1 | gzip > sda1.img.gz
97659072+0 records in
97659072+0 records out
50001444864 bytes (50 GB) copied, 4588.03 s, 10.9 MB/s

Die Pfeilchen-Loesung ist somit unbrauchbar, zumindest auf einem Ubuntu Bootstick.Manech 12:56, 17. Mär. 2011 (CET)

Da liegt ein Verständnisfehler deinerseits vor: Als normaler Benutzer hast du auf /dev/sda1 keinen Lesezugriff, erst per sudo erhält der damit aufgerufene Prozess root-Rechte. Im zweiten Fall ist das der dd-Prozess, der dadurch von /dev/sda1 lesen kann. Die Ausgaben werden an das nicht mit Root-Rechten laufende gzip-Programm weitergeleitet, dessen Ausgaben leitet die nicht mit Root-Rechten laufende aktuelle Shell in die Datei sda1.img.gz weiter.

Im ersteren Fall hingegen liegt folgendes vor: Du startest den gzip-Prozess mit Root-Rechten. Das bringt aber gar nichts, da die Eingabe von der Shell, die keine Root-Rechte hat, gefüttert wird und die Ausgabe ebenso von der gleichen Shell in eine Datei umgeschrieben wird (unkritisch).

Damit also in diesem Fall mit den Dateirechten die "Pfeilchen-Lösung" äquivalent funktioniert, muss die Shell selbst mit Root-Rechten laufen. Das geht etwa per sudo bash, anschließend wird die Lösung 1 (sudo kannst du weglassen da du komplett als Root arbeitest) funktionieren. Enthusiastischere Benutzer dürften sich selbiges auch auf einer Kommandozeile zusammenschrauben (sudo bash -c 'gzip < ... > ...').

Grüße, --Benji 14:05, 17. Mär. 2011 (CET)

Ah ok, vielen Dank für den Hinweis! Dann ist die "Pfeilchen-Lösung" ja doch ganz nett ;) Manech 13:16, 18. Mär. 2011 (CET)

Das ist falsch. Ein cp kann eine Gerätedatei als solche (d.h. Spezialdatei die ein Blockdevice repräsentiert) kopieren, wohingegen dd nur Datenströme aus und in Filehandles leiten kann (die Handles können natürlich auch von Devicedateien sein, aber es werden eben Daten und keine Gerätedateien kopiert) --89.0.64.90 22:07, 9. Feb. 2013 (CET)

DD-Statement

Hallo,
ich habe das wieder rückgängig gemacht, weil es sich meines Wissens bei den besprochenen Großrechnern auch um Unix-Systeme handelt.
Ansonsten könnte man auch diese Vorlage:Dieser Artikel sowohl von DD-Statement als auch dd (Unix) entfernen und stattdessen DD-Statement in DD auflisten, dann wäre ich auch zufrieden.
Grüße, --Benji 11:18, 12. Mai 2008 (CEST)

Quelle? ("JCL wurde 1964 für OS/360 IBM entwickelt" klingt gar nicht nach Unix.) Ich habe deinen zweiten Vorschlag umgesetzt. --08-15 11:23, 12. Mai 2008 (CEST)

Sowohl den JCL-Befehl als auch das Unix-Kommando sucht man unter der Bezeichnung „dd“ bzw. „DD“, und weil Groß-/Kleinschreibung in der Suchfunktion nicht signifikant ist (und es ja Leute gibt, die immer klein schreiben) finde ich die „Dieser Artikel“-Vorlage in den beiden Artikeln schon sinnvoll.

Der andere Punkt ist aber ganz gegenstandslos, JCL hat überhaupt nichts mit Unix zu tun, und die OS-Familie ebenfalls nicht. Viele Grüße, --GottschallCh 11:44, 12. Mai 2008 (CEST)

Mit den Eingaben DD und dd kommt man auf die Begriffsklärungsseite, von der beide Bedeutungen verlinkt sind. --08-15 11:46, 12. Mai 2008 (CEST)

Wow, das artet ja fast in einen Editwar aus ;-)

Dann wär die Sache jetzt geregelt, okay? --Benji 12:10, 12. Mai 2008 (CEST)

Nutzlose Beispiele

Ich würde gern eine Diskussion zum Thema sinnfreie Beispiele anstoßen. Es wurde mehrfach Code der Art

dd if=/dev/foo |gzip -c >foo.gz

gepostet. Nun ist das aber ein hinreichend sinnfreies Beispiel, denn der saubere Weg wäre

gzip -c </dev/foo >foo.gz

Also interessiert mich, ob wenige gute Beispiele besser sind als viele gute und schlechte Beispiele.
Hintergrund: Die Wikiseite zu dd soll ja IMHO nicht nur den dd-Befehl etwas näher erläutern sondern vor allem auch entmystifizieren. Gerade Anfänger wissen nicht wirklich, was in der Shell bei Pipes, |, oder Umleitungen, < und >, passiert. Deswegen wird oft vom KISS-Prinzip abgewichen. Aber das kann nicht Ziel der Übung sein. -- kn0rke
(Der vorstehende Beitrag stammt von 139.18.2.46 – 10:19, 16. Jun. 2008 (MESZ) – und wurde nachträglich unterschrieben.)

FULL ACK. Du bist herzlich eingeladen, dabei beizutragen. Hiermit wurde ja schon ein Schritt dahin getan. Vielleicht könnte man ja eine eigene Überschrift um diesen "Mythos dd" machen und dazu mal etwas schreiben. --Benji 15:46, 16. Jun. 2008 (CEST)

So, ich hab mal etwas erläutert, in wie fern dd nicht nur gegenüber cp, sondern auch cat und Streamumleitungsoperatoren unnötig ist. Das ist natürlich noch ausbaufähig. --Benji 16:07, 16. Jun. 2008 (CEST)

Ja super Benji, Danke. Ich ergänze, wenn ich mir noch was sinnvolles einfällt. :) schrub kn0rke 17:00, 17. Jun. 2008 (CEST)

Infokasten?

Hi kann mal einer so einen Infokasten (rechts oben), wie bei Moodle machen.
(nicht signierter Beitrag von 213.61.134.138 (Diskussion | Beiträge) 10:13, 1. Dez. 2009 (CET))

Die würde bei dd wohl ziemlich leer aussehen, weil es ein Unix-Kommando und damit ein abstraktes Konzept ist. Mit dem Artikel wird also nicht etwa die konkrete GNU-Implementierung beschrieben. Das einzige, was als Feld noch übrig bleibt, ist dann Kategorie – und das ist etwas dürftig für eine Infobox.... Aber fühl dich frei und erstell trotzdem eine – vielleicht kommt ja was sinnvolles hinzu... --Benji 17:43, 1. Dez. 2009 (CET)

Ungepufferte Geraete

"Bei ungepufferten Geräten muss allerdings sichergestellt werden, dass jede Leseoperation mit Ganzzahligen Vielfachen der Sektorgröße arbeitet." Was ist damit gemeint? Google zeigt unter "Ungepufferte Geraete" zuallererst auf dieses Lemma! Durch diesen Hinweis bin ich verunsichert; zwar verstehe ich jetzt, dass der dd-Befehl ueberfluessig ist und ich es eleganter direkt mit gzip machen koennte. Jedoch wird das direkt im Anschluss sofort wieder gebremst, weil ich als Leser eine Einschraenkung der eleganten Loesung bezueglich gepufferten Geraeten erfahre. Da ich nicht weiss, was damit gemeint ist, ist der gesamte Ratschlag entwertet = ich verwende dann als Leser eben doch lieber wieder die "unelegante" Loesung mit dd, denn die scheint ja offenbar keine Probleme mit ungepufferten Geraeten zu haben. Hier sollte im Lemma nachgebessert werden: Entweder man gibt eine bessere Loesung vor, dann sollte diese jedoch auch praktikabel und verstaendlich sein, oder man laesst es lieber. --62.169.207.133 20:57, 11. Jun. 2014 (CEST)

Hallo!

Ich glaube, da geht es um engl. “unbuffered I/O” auf der einen Seite, was so viel heißt wie engl. “raw access” oder “direct access” versus “buffered I/O”, bei dem die Daten zuerst in einem Zwischenspeicher („Puffer“) landen, und erst dann auf dem eigentlichen Gerät.

Die genauen Unterschiede und Probleme, die es beim ungepufferten I/O gibt, sind wohl bei den Geräten unterschiedlich, liegen aber vermutlich sehr oft an der Größe der Datenblocks, der auf einmal – in einem Rutsch sozusagen – geschrieben werden (muss). Daher muss man beim direkten Zugriff (unbuffered) genauer schauen, dass die Blockgrößen stimmen. Auch kann es wohl sein, dass die Daten immer schon bereitliegen müssen, wenn es um Schreibzugriffe geht. Da ist ein Zwischenspeicher vermutlich keine schlechte Idee.

(Ein gutes Beispiel ist sicherlich der Schreibvorgang auf einer CD-R…)

Leider bin ich kein Programmierer und verstehe es daher vermutlich nicht ganz richtig; dieser Link (englisch) könnte dennoch hilfreich sein.

‣Andreas•⚖ 19:49, 12. Jun. 2014 (CEST)

Hallo Andreas! Vielen Dank fuer Deine Hilfe & Infos! Das Grundprinzip von Puffernspeichern verstehe ich; ein typisches Beispiel davon sollte AFAIK der Festplatten-cache sein. Was mir allerdings im Konkreten Bezug zu dd nicht klar ist, ist wann wir es mit "gepufferten und wann mit ungepufferten Geraeten" zu tun haben. Sprich: Mir fehlen in den eigentlich sehr konkreten Beispiel mit dd konkretere Geraete-Beispiele. Ist z.B. eine USB flash disk ("USB stick") ein gepuffertes oder ungepuffertes Geraet? Oder eine SSD, Festplatte, Netzwerkfreigabe, Pipe, CD-ROM mit Buffer-underrun-schutz, etc.? Jede Info hierzu im Lemma wuerde das vorhandene Beispeil deutlich verstaendlicher und nuetzlicher machen, IMHO. VG --62.169.207.133 21:40, 12. Jun. 2014 (CEST)

Tja, nicht nur das Beispiel "eleganter mit Umleitungen" ist ziemlich seltsam, leider befinden sich im Artikel noch einige Merkwürdigkeiten. Da ist der Satz "Bei ungepufferten Geräten muss allerdings sichergestellt werden, dass jede Leseoperation mit Ganzzahligen Vielfachen der Sektorgröße arbeitet" nur die Spitze des Eisbergs. Ich versuch mal die Fragen kurz zu beantworten:

• Unter Unix(-Ähnlichen) ist praktisch alles eine (benannte) Datei, diese Dateien werden in einer Verzeichnisstruktur geordnet. Damit wird auch die Ansteuerung von Peripheriegeräten über Gerätedateien abgewickelt. Dort ist zu einiges verbessern, aber auch in Inode#Aufbau fehlt noch vieles ;-(
• Die Ausgabe von ls -l /dev/* zeigt gleich in der 1. Spalte einen Kennbuchstaben für block oder character devices (andere tun hier nichts zur Sache).
• Nur die blockorientierten Geräte sind im hier verwendeten Sinn "gepuffert", diese verwenden einen vom Kernel verwalteten Cache im RAM, der im Hintergrund auf die langsamere Festplatte geschrieben wird, vgl. sync(1). Insbesondere das gleichzeitige Lesen und Schreiben mehrerer Prozesse erfolgt auf logischer Ebene unabhängig voneinander. Erst der Kernel organisiert im Hintergrund die tatsächlichen Zugriffe. Das Verhalten von Uxen und den WinNT-Nachfolgern ist hier schon vom Design her prinzipiell unterschiedlich, das führt hier allerdings zu weit.
• Für die blockorientierten (= gepufferten) Geräte ist mounten und umount charakteristisch: So wird der gesamte auf der Partition befindliche Verzeichnisbaum an einem entsprechenden Zeig eingehängt, beim aushängen werden noch austehende Pufferoperationen ausgeführt und auf die Platte geschrieben. Ein umount schlägt übrigens fehl, wenn noch andere Programme auf die Partition zu greifen. fuser (Unix) fehlt zwar noch, aber fuser(1) hilft vielleicht.

Ein häufiger Fall (es gibt auch andere) ist das kopieren und sichern von Datenträger-Images mit dd. Angenommen auf /dev/sda1 befindet sich z.B. ein "alternatives" Betriebssystem, das gesichert werden soll. Gleichzeitig ist die Partition über /media/sda1/ eingehängt. Dann gibt's mindestens zwei Varianten:

# Variante A
 umount /dev/sda1
 dd if=/dev/sda1 > /var/tmp/partition_image
 mount /media/sda1

# Variante B
gzip -c < /dev/hda1 > /tmp/partition_image.gz

Wo ist der Unterschied zwischen (A) und (B)? Das (A) nicht komprimiert ist bei heutigen Platten eher kein Problem. Und wenn doch, warum nicht bzip2? Auch das das Backup von (B) nach einem Reboot weg ist, interessiert hier nur am Rande. Das wirklich unelegante der Variante B erschliesst sich vielleicht aus dem vorher Geschriebenen ... --grixlkraxl (Diskussion) 01:34, 13. Jun. 2014 (CEST)

Hallo!

Ich verstehe die Beispiele nicht bzw. was du daran auszusetzen hast.

(1) Denn in beiden Fällen handelt es sich um ein Backup – dieses aber von einem eingehängten Dateisystem anzufertigen ist nicht als sicher zu bezeichnen: daher muss grundsätzlich auch in der gzip-Variante (Variante B) das Gerät/die Partition zuerst ausgehängt werden (umount /dev/sda1) oder zumindest als Nur-Lesen eingehängt sein (was jedoch trotz des Nur-Lesen-Modus ebenfalls als nicht sicher zu bezeichnen ist).

(2) /tmp ist nicht automatisch beim nächsten Start wieder weg. Das hat sich erst in den letzten Jahren als Standard etabliert. Alte Linux-Distributionen löschen /tmp meist nicht. Außerdem ist es in Mode gekommen, /tmp als RAM-Laufwerk einzuhängen, was einen gewissen Geschwindigkeitsvorteil verspricht und bei SSDs obendrein das Speichermedium etwas mehr schont. Moderne Distributionen haben außerdem einen Script beim Herunterfahren oder Starten, das in allen anderen Fällen das /tmp-Verzeichnis bereinigt. Letzteres war früher wie gesagt nicht der Standard.

(3) Beide Varianten arbeitet letztlich mit Ausgabeumleitungen bzw. allgemein mit Ein-/Ausgabeumlenkung (englisch I/O redirection), könnten aber genauso gut mit Pipes arbeiten. Statt gzip kann man jedes andere Komprimierprogramm verwenden. Oder sogar ein anderes Programm, das Daten in welcher Wiese auch immer in eine Datei oder auf ein Gerät schreibt. Beispiele:

• dd if=/dev/sda1 of=/media/USBpendrive/partition_backup.bin bs=4k
• dd if=/dev/sda1 | gzip -c > /media/USBpendrive/partition_backup.bin.gz
• dd if=/dev/sda1 | 7za a -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on -si /media/USBpendrive/partition_backup.bin.7z
• 7za a -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on -si /media/USBpendrive/partition_backup.bin.7z < /dev/sda1
• dd if=/dev/sda bs=512 count=1 | md5sum > /tmp/mbr.md5
• dd if=/dev/sda bs=512 count=1 | md5sum -c /tmp/mbr.md5

‣Andreas•⚖ 14:44, 13. Jun. 2014 (CEST)

Was mit dem Artikel nicht stimmt

Wie eingangs 62.169.207.133 und jetzt Andreas "verstehe (auch ich!) die Beispiele nicht" bzw. was sollen diese Beispiele zeigen? Der Reihe nach:

• Ich fand den Artikel in diesem Zustand vor, dachte mir "Hm, na ja" (vorsichtig ausgedrückt) und habe mit der eigentlichen Arbeit weitergemacht. Anschließend ging (und geht es mir immer noch) erstmal um Inode.
• Nun hat 62.169.207.133 oben nach Sinn und Zweck der Aussage

> "Bei ungepufferten Geräten (eg. character devices!) muss allerdings sichergestellt werden, dass jede Leseoperation mit Ganzzahligen Vielfachen der Sektorgröße(sic!) arbeitet." (Herv. von mir)

gefragt. Der Satz aus der Spalte Erläuterung rechts neben eleganter mit Umleitungen im Abschnitt Beispiele lässt auch mich rätseln: was hat das mit dem Erstellen der Abbilddatei einer Festplattenpartition zu tun?

• Weiter oben liest man im Abschnitt Hintergrund:

> "dd erweitert die Funktionalität von cp und cat. ..."

Supi klasse Hintergrund-Information ;-) also:

 dd  < /dev/sda1 > /var/tmp/sda1_dump
 cp  < /dev/sda1 > /var/tmp/sda1_dump
 cat < /dev/sda1 > /var/tmp/sda1_dump

Das ist so trivial wie richtig! oder anders ausgedrückt: "There are many ways to do things."

Im Artikel sind also sowohl die relevanten Besonderheiten herauszuarbeiten, als auch die Beispiele auf das wesentliche zu reduzieren! Wie auch immer, genug gejammert. Bei meinen weiteren Bearbeitungen werde ich mich also (andere dürfen natürlich auch) auf diesen Abschnitt beziehen.

Im übrigen halte ich besonders "elegante" Kommandozeilen-Zauberei für überflüssig, weil damit das Thema des Artikels verfehlt wird. --grixlkraxl (Diskussion) 16:43, 13. Jun. 2014 (CEST)