staging.inyokaproject.org

Hallo,

habe eine Wiki Beitrg zu dd geschrieben - Baustelle/dd.

Ist auch soweit fertig, habe aber ein paar Fragen / Anmerkung:

1. Ist es richtig / sinnvoll, den Beitrag als "Fortgeschritten" zu markieren?
2. Das Layout im Bereich des Inhaltsverzeichnisses finde ich nicht gerade schön (große weiße Fläche) - gibt's 'ne Möglichkeit das zu ändern?
3. Mach es Sinn allgemeine Beispiele zu geben (zumal weiter unten die "realen" Anwendungen kommen)? Bin mir selber nicht schlüssig...

Ansonsten sind wie immer Verbesserungsvorschläge, Korrektur von inhaltlichen Fehlern etc. willkommen!

Gruß
noisefloor

Hallo noisefloor,

dein Artikel gefällt mir sehr gut. Er gibt in kompakter Form sehr viele Informationen.

noisefloor hat geschrieben:

1. Ist es richtig / sinnvoll, den Beitrag als "Fortgeschritten" zu markieren?

Das macht auf jeden Fall Sinn. Wie du in dem Beitrag erwähnst, kann man bei unvorsichtiger Verwendung sehr leicht seine Daten verlieren.

noisefloor hat geschrieben:

3. Mach es Sinn allgemeine Beispiele zu geben (zumal weiter unten die "realen" Anwendungen kommen)?

Ich denke es sind genügend Beispiele vorhanden.

noisefloor hat geschrieben:

Ansonsten sind wie immer Verbesserungsvorschläge, Korrektur von inhaltlichen Fehlern etc. willkommen!

Du schreibst, dass es nicht mit CD-/DVD-Dateisystemen funktioniert. Das ist nicht korrekt. Ich habe testweise einmal einen Dump von einer CD gezogen und als Loopback-Device gemountet und es funktioniert einwandfrei.

$ sudo dd if=/dev/hdc of=/tmp/knoppix.img bs=1024
712926+0 Datensätze ein
712926+0 Datensätze aus
730036224 Bytes (730 MB) kopiert, 186,457 Sekunden, 3,9 MB/s
$ sudo mount -o loop /tmp/knoppix.img /mnt
$ ls /mnt
autorun.bat  autorun.inf  autorun.pif  boot  cdrom.ico  index.html  KNOPPIX

Etwas anderes hätte mich auch gewundert, denn ISO-9660 ist ein Dateisystem und wenn passende Treiber installiert sind, kann dd es natürlich auch lesen.

Gruß, Holger

Wow, umfangreicher Artikel ☺

1. Ist es richtig / sinnvoll, den Beitrag als "Fortgeschritten" zu markieren?

Ich würde sagen ja.

2. Das Layout im Bereich des Inhaltsverzeichnisses finde ich nicht gerade schön (große weiße Fläche) - gibt's 'ne Möglichkeit das zu ändern?

Kürzere Überschriften 😉

3. Mach es Sinn allgemeine Beispiele zu geben (zumal weiter unten die "realen" Anwendungen kommen)? Bin mir selber nicht schlüssig...

Ich gebe mittlerweile Beispiele immer in der Form

# Allgemein
befehl <-option> {wasauchimmer}
# Beispiel
befehl -c /opt

Ähnlich wie in Samba_Client#head-c405e0b39024181aa22cf73a2bb6db6ac8bdbf96

Das soll nur ein Beispiel sein. So erkläre ich die Syntax und gebe ein Beispiel die Syntax zu verstehen.

Dazu noch. Vielleicht eine kurze Erklärung einfügen was "bit-genaues" Kopieren ist. So füllt sich auch noch die weisse Fläche etwas. Die "Warnung" Box könntest du auch über den Artikel packen, so würde hier auch wieder Platz frei.

Tschuess
Christoph

@noisefloor: Zur Syntax:

1. Verzeichnisse bitte fett, nicht kursiv.
2. kleine Typos.
3. "", kann ein komplettes Device sein (z.B. hda), " → Das ist doch falsch. Müßte doch "/dev/hda/" sein. Auch wenn der Artikel fortgeschritten ist, solltest Du das korrigieren.
4. Die zwei Hinweisboxen zu eienr zusammenfassen.
5. Die Beispiel kannst Du ja, wenn Du sie nummerierst auch als Liste schreiben.
6. Beim Klonen würde ich aus dem Hinweis eine Warnung machen. Oder überprüft dd das vorher? Ich glaube nicht. Was passiert, wenn sie verschieden groß sind? Geht zum Beispiel klein auf groß?
7. Das Inhaltsverzeichnis ggf. nur auf Stufe 1.

Das war's. ☺

Gruß, Dee

Hallo,

danke für euer Feed-Back.

Habe soweit alles korrigiert.

@holger63: stimmt, geht! Mir war nicht klar, dass das nur mit Root-Rechten geht. Außerdem funktioniert dd nur mit Daten CDs - ist im Wiki-Eintrag bereits korrigiert.

@Dee, Punkt 6: Habe ich gemacht. Es ist in der Tat so, dass dd knallhart & gnadenlos ist - dd schreibt erstmal lustig drauf los.

Ansonsten habe ich auch alle auskommentierten Zeilen entfernt. Wenn keiner mehr einen Verbesserungsvorschlag hat ist dd von mir aus fertig.
Ach ja: Inzwischen habe ich den Beitrag ca. 738 mal gelesen und sehe keine (Rechtsschreib-) Fehler mehr - betriebsblind? ☺

Gruß
noisefloor

Naja, waren noch kleiner Typos und an manchen Stellen hat die Syntax nicht gestimmt. Außerdem habe ich /home/user ersetzt, weil man bei Befehlen (und fortgeschrittenen Artikel) ruhig die Tilde nehmen kann. Zusätzlich habe ich das erste /media/sicherungen ersetzt, weil Du ohne sudo gearbeitet hast und man dort keine Schreibrechte hat. Das habe ich auch ganz unten beim Netzwerkpart ergänzt.

Zwei große Bitten aber:
1. Verlinke Wiki-Artikel in Zukunft nicht mehr absolut!
2. Benutze deutsche Worte, wo es geht.

Link: Shell/dd.

Gruß, Dee

Hallo,

wie ich gesehen habe, ist dd ins reguläre Wiki verschoben, sehr schön.

Soll dd noch einen Link in Shell/Befehlsübersicht bekommen?

Gruß
noisefloor

EDIT:
@Dee - was meinst du mit "Verlink Artikel nicht mehr absolut?"

@noisefloor: Ich habe oben noch einiges ergänzt. Bitte lesen!

Wegen absolut: Nicht

 [http://wiki.ubuntuusers.de/Seite Seitenname] 

sondern

 [:Seite:Seitennamen] 

nutzen, siehe Wiki/Syntax. Du bescherst uns nämlich so bei Änderungen Deadlinks, die wir nicht überprüfen können.

Gruß, Dee

Hallo,

ok, mache ich in Zukunft!

Nochmal Danke!
noisefloor

Wäre es nicht sinnvoll bei den Beispielbefehlen zum Klonen von Partitionen und Festplatten die Blocksize anzugeben? Weiter vorne im Artikel wird ja schon erwähnt, dass es ohne Angabe einer ausreichend großen Blocksize extrem langsam kopiert.

In der englischen Wikipedia steht auch, dass es schneller laufen soll, wenn man

dd if=/dev/sda bs=1M | dd of=/dev/sdb bs=1M

anstatt

dd if=/dev/sda of=/dev/sdb bs=1M

verwendet, weil dann angeblich parallel gelesen und geschrieben werden soll.

Edit: Ich habe jetzt mal einen kurzen Test durchgeführt. Ich habe von einem 1,5TB auf ein 2TB Raid5 kopiert. Ohne Angabe der BlockSize konnte ich mit 8,3MB/s kopieren. Ohne Angabe der BlockSize und im "parallelen Modus" wurden die Daten etwa mit 11MB/s kopiert, also ist an der Aussage aus der Wikipedia scheinbar etwas dran. Im "parallelen Modus" und einer BlockSize von 1MB wurde mit etwa 26MB/s kopiert.

Hallo,

kannst du gerne einbauen.

ABER nicht mit der Pipe - das geht auch ohne. Die Optionen heißen ids und ods. Schau' mal in die Manpage von dd. ☺

Gruß, noisefloor

???

Die Optionen ibs und obs werden doch von bs=1M bereits mit erschlagen ? (ids / ods finde ich nicht)
Lt. man dd:

bs=BYTES
    force ibs=BYTES and obs=BYTES

Wenn dieser putzige Pipe-Trick tatsächlich die Datenrate verdoppelt (wieso auch immer), warum darf er dann nicht in das Wiki ?

track

Hallo,

ups - ihr müsst natürlich das d zum b spiegeln... 😉

Die Sache mit der Pipe - wenn's das ganze schneller macht → warum nicht. Ich hatte nur erstmal den Sinn davon nicht gesehen.

Kann es sein, dass die Pipe schneller ist, weil dd als Prozess 2x gestartet wird, 1x zum Lesen und 1x zum Schreiben?

Gruß, noisefloor

In diese Richtung geht die Erklärung dazu in http://en.wikipedia.org/wiki/Dd_(Unix) wo die Idee wohl her stammt.
(Es klingt mehr so als wenn der Device-Zugriff innerhalb von dd immer nacheinander erfolgt... das habe ich allerdings nicht verifiziert)

edit: Lt. Quelltext liest dd mit seiner main_loop tatsächlich nacheinander jeweils einen Block (rsp. Puffer) ein, konvertiert ihn ggf. und schreibt danach.
Damit wäre das plausibel, denn das schreiben / lesen einer Pipe geht ungleich schneller als ein Device. Praktisch kommen allerdings noch die Caches von Linux und in den Festplatten mit ihrem read-ahead ins Spiel, die das wieder relativieren... Das beste wäre wohl wirklich, das einfach per Vergleichstest zu bewerten.

Schneller geht das natürlich nur zwischen unabhängigen Kanälen, z.B. bei SATA, und definitiv nicht, wenn man z.B. innerhalb eines ATA-Strangs (Master ←> Slave) kopiert, der sowieso immer nacheinander zugreift.

track

Hej,

ich teste gerade Mit-dd-erstellte-Images-einbinden. Das klappt, solange der Stick nur eine Partition enthält.

Bei mehreren soll zum mounten der -o loop,offset= verwendet werden, um den zu erhalten, soll

sudo fdisk -l -u /Pfad/zum/Image.img 

verwendet werden.

Hier mein 'fagwürdiges' Ergebnis:

blacktencate@tmh4440:~/Desktop$ sudo fdisk -l -u st4gb_g-l.img
Sie müssen angeben Zylinder.
Sie können dies im Zusatzfunktionsmenü tun.

(lustiges Deutsch)

In der man-page steht zum Thema:

OPTIONS

...

• C cyls

Specify the number of cylinders of the disk. I have no idea why
anybody would want to do so.

...

nun wollte ich die ja eigentlich erst mal erfahren! 😬

Es hilft offensichtlich auch nicht, wenn ich das vom Stick direkt abgreife:

Platte /dev/sdc: 8054 MByte, 8054636032 Byte
255 Köpfe, 63 Sektoren/Spuren, 979 Zylinder
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
Disk identifier: 0x0005ae85

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sdc1             589         979     3140707+   5  Erweiterte
/dev/sdc2               1         588     4723078+   b  W95 FAT32
/dev/sdc5             589         680      738958+   b  W95 FAT32
/dev/sdc6             681         978     2393653+  83  Linux
/dev/sdc7             979         979        8001   83  Linux

also z. B. für sdc2

sudo mount -o loop,offset=512 -t vfat st4gb_g-l.img /media/loop_mount
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error
       Manchmal liefert das Syslog wertvolle Informationen – versuchen
       Sie  dmesg | tail  oder so

setze, dmesg | tail liefert:

[14227.397628] FAT: invalid media value (0xca)
[14227.397637] VFS: Can't find a valid FAT filesystem on dev loop0.

Was mache ich falsch?

Gruß Reinhard

PS.:

... Der Offset für die 3. Partition währe also 109065285 * 512 = 55841425920

wird hier immer wieder gern genommen 😈