staging.inyokaproject.org

Hi,

der nachfolgende Hinweis ist super:

dd sollte auf gar keinen Fall zur Übernahme eines bestehenden Systems auf eine SSD (Solid-State-Drive) genutzt werden, denn dadurch wird die SSD mit unnötigen Schreibprozessen belastet und das Alignment wird höchstwahrscheinlich nicht eingehalten.

Aber ich finde ein SSD- Besitzer sollte folgendes ...machen, das hilft viel mehr. Ich habe leider auch keine passende Idee. Wer kann hier helfen? Vielleicht auf einen anderen Wiki- Artikel verweisen oder etwas ähnliches.

Berlin 1946 schrieb:

Aber ich finde ein SSD- Besitzer sollte folgendes ...machen, [...]

Das habe ich mich eben auch gefragt, als ich die Warnung im dd-Artikel gelesen habe. Es wäre schön, wenn man das Wiki um eine SSD-taugliche Strategie ergänzen könnte.

Theoretischer Anwendungsfall:
SSD-Platte mit beliebigem OS 1:1 in eine Imagedatei sichern und im Notfall wiederherstellen. Notfall ist z. B. ein Ausfall der SSD oder ein zerschossenes System.

Hi

Wäre es sinnig den Wiki-Artikel Shell/dd im Bereich Image-einer_Partition_sichern zu ergänzen, daß man vor dem Sichern den freien Plattenplatz mit Nullen überschreiben sollte, damit das Packen schneller geht und weniger Platz beansprucht?

Aufgrund dieses Thread http://forum.ubuntuusers.de/topic/windows-ntfs-partition-groesse-veraendern/ und kurz zuvor Diesem http://forum.ubuntuusers.de/topic/wipe-fuer-schon-geloeschte-dateien/ denke ich mir, daß diese Vorarbeit durchaus Zeit- und Platzersparnis bringt.

Das Anpassen des Wiki-Artikel traue ich mir halbwegs zu, allerdings gibt es mehrere Stellen, an Denen ein Packer benutzt wird - da wäre die Information überall sinnvoll.

Wäre es da nicht wesentlich besser, für das 'mit Nullen überschreiben' einen eigenen Artikel zu erstellen und nur auf Diesen zu verweisen?

MfG

Hej,

habe gerade hier

...Erfolgreich getestet wurde z.B

ebenfalls ein Ubuntu Pangolin-i386 getestet.

Zusätzlich kann ich bestätigen, daß ebenfalls ein für Windows erhältliches dd (chrysocome.net/dd, downloads/dd-0.6beta3.zip) funktioniert mit folgenden Parametern

• Stick (mit Windows) als FAT32 formatiert

• dd if=iso-file od=i: bs=4M

  man beachte den output: od=, neues Feature aus Version 0.6beta3, damit wird nicht die Partition, sondern der ganze Stick angesprochen; "i:" ist hier der USB Stick.

Gruß black tencate

Hej,

an dieser Stelle steht

dd if=/dev/XXX of=/dev/XXX & ddpid=$! ; while [ $(ps -a | grep $ddpid) ]; do kill -SIGUSR1 $ddpid; sleep 10; done 

was leider mit

root@ubuntu:/home/ubuntu# dd if=/dev/sdc3 of=/dev/sda1 bs=100M & ddpid=$! ; while [ $(ps -a | grep $ddpid) ]; do kill -SIGUSR1 $ddpid; sleep 10; done 
[1] 4262
bash: [: too many arguments

😕

Gruß black tencate

EDIT, Ooops, da läuft ja doch etwas, wird aber nicht angezeigt! (1elf)

Habe mal den Abschnitt Shell/dd#Einige-allgemeine-Beispiele auch dem Abschnitt Shell/dd#Anwendungen zugeordnet und eine Warnung eingebaut:

Siehe dazu:

• wieso-wechseln-die-device-files-meiner-festpla

• sicherung-mit-dd

Hi!

Ich glaube einen Fehler unter "Fesplatte (sicher) löschen" entdeckt zu haben:

dd if=/dev/zero of=/dev/sda bs=8192 & pid=$! 

Wird hier nun eine Blocksize von 8MB, wie beschrieben oder fälschlicherweise von 8KB verwendet?

Bin mir leider nicht ganz so sicher um das gleich zu ändern... vermutlich würde ich auch ein Bock schiessen, wenn es darum geht nun 8192kb oder 8192K anzugeben (kB=1000, K=1024)

Ich glaube, dass bei diesem Befehl nur 8192Bytes bzw. 8KB auf einmal geschrieben werden und somit nur 1/1000tel von dem Festplatten-Buffer genutzt werden.

Schaut euch das bitte mal an...

MfG

PacMan86

PacMan86 schrieb:

Wird hier nun eine Blocksize von 8MB, wie beschrieben oder fälschlicherweise von 8KB verwendet?

Weder noch - bs=8192 steht fuer 8192 Bytes.

PacMan86 schrieb:

Ich glaube, dass bei diesem Befehl nur 8192Bytes bzw. 8KB auf einmal geschrieben werden und somit nur 1/1000tel von dem Festplatten-Buffer genutzt werden.

Genau so ist es. Da sollte wohl eigentlich bs=8M stehen.

Edit: angepasst und gleich noch nen Typo gefunden

stfischr schrieb:

PacMan86 schrieb:

Ich glaube, dass bei diesem Befehl nur 8192Bytes bzw. 8KB auf einmal geschrieben werden und somit nur 1/1000tel von dem Festplatten-Buffer genutzt werden.

Genau so ist es. Da sollte wohl eigentlich bs=8M stehen.

Edit: angepasst und gleich noch nen Typo gefunden

Mmh, ist durch die Angabe in MB nicht irgendwie der Bezug zu der Ausgabe von

1

hdparm -i /dev/sdX

in KB verloren gegangen? Denn in dem Text steht, dass der Wert von BufferSize= exakt so übernommen werden kann.

Da soll dann erstmal einer mitkommen, ob er die Ausgabe von hdparm nun direkt so eintragen kann: (hier mal meine Festplatte:)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

/dev/sda:

 Model=ST9750423AS, FwRev=0001SDM1, SerialNo=5WS0X9F2
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, '''BuffSize=16384kB''', MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1465149168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=yes: unknown setting WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-4,5,6,7

 * signifies the current active mode

Bei diesem Beispiel müsste doch der Befehl dann bei BuffSize=16384kB so lauten:

1

dd if=/dev/zero of=/dev/sda bs=16384K & pid=$!

Wenn das so richtig ist, müsste man den Text so abändern, dass man herauslesen kann, wie man die Blocksize von der Ausgabe von hdparm übernehmen soll

Also mich verwirrt der Text und der Code im Zusammenspiel immer noch; Angabe von bs= nun in K oder KB oder durch 1024 teilen und dann in M und nicht in MB

MfG

Hm, wenn das einfacher ist, können wir das gerne abändern in K. Aber ehrlich gesagt würde ich deswegen nicht so einen Aufriss machen. Ich hatte mal ne Zeit lang verschiedene Festplatten mit verschiedenen Blocksizes getestet und bin irgendwann zu dem Schluss gekommen, das man mit 16M eigentlich immer die maximale Transferrate erreicht. Und das ist auch völlig unabhängig von der Cachegröße der HDD.

Hier mal ne 32MB-Cache Platte:

4 MB 118 MB/s
8 MB 120 MB/s
16 MB 121 MB/s
32 MB 121 MB/s
64 MB 121 MB/s

Solange bs nicht größer als der freie Speicher ist bleibt das dann auch konstant. Und falls mal ein Laufwerk schon bei 4MB seine Sättigung hat, ist es ja auch egal, wenn man es trotzdem mit 16M betreibt. Im schlimmsten Fall läuft der Kopiervorgang mal 1% langsamer als er könnte, da stirbt auch keiner. Von daher würde ich einfach hinschreiben:

um den Kopiervorgang zu beschleunigen kann man bs=16M angeben

ohne weitere Detailnachfrage und Cachegrößenbestimmung.

stfischr Um so besser! Danke Da ich mit dd nicht soo viel Erfahrung habe, ausser das es auch ewig dauern kann, bin ich halt darüber gestolpert.

Ich würde die Box dann einfach so schreiben:

dd if=/dev/zero of=/dev/sda bs=16M & pid=$! 

while true; do kill -USR1 $pid && sleep 1 && clear; done 

Wären damit auch alle anderen Einverstanden?

Also ich plädiere für bs=1M. Optimale Geschwindigkeit gibts schon mit 64-128k, 1M ist so gesehen zu groß, hat aber den Vorteil, daß man mit der Ausgabe von records in/out direkt was anfangen kann, ohne das erst wieder von einer schrägen Blockgröße in M umrechnen zu müssen (sprich human-readable). Für noch größere Blocks gibts kaum Veranlassung. Das kann genausogut auch wieder langsamer werden.

Zur Fortschrittsanzeige:

while killall -SIGUSR1 dd; do sleep 60; done;

...wenn man sich die pid nicht merken will, oder eben analog mit kill $pid.

sleep würde ich in jedem Fall größer als 1 wählen. Denn den Fortschritt auszugeben kostet auch Performanz. Und gerade bei langwierigen Kopieraktionen wo man sich für den Fortschritt interessiert, muss man nicht jede Sekunde das Update haben.

Alternativ zur while-Schleife auch mit watch, aber das terminiert nicht zusammen mit dd.

Beide Vorschläge halte ich für sehr sinnvoll, deshalb dazu mein 👍

Allerdings wäre mir ein Minutentakt für die Anzeige vielleicht doch zu wenig, deshalb würde ich ein sleep 10 vorschlagen.
Beim 10-Sekundentakt kann man noch zugucken, wie sich was ändert, und die Last ist trotzdem praktisch null ... 😉

LG,

track