Archiv verlassen und diese Seite im Standarddesign anzeigen : Fragen zu dd
Hallo
ich habe 3 Fragen zu dd
1.wie kann ich mit dd oder etwas anderem eine 1,44 MB Diskete komplett mit Hex 0
überschreiben
2.wie kann ich mit dd ein Image von einer 1,44 MB Diskette erstellen
3.wie schreibe ich das Image wieder auf Diskette
1) dd if=/dev/zero of=/dev/fd0 bs=512
2) dd if=/dev/fd0 of=disk.bin bs=512
3) dd if=disk.bin of=/dev/fd0 bs=512
hallo
danke für die info das wars was ich gesucht habe :)
Original geschrieben von zander
1) dd if=/dev/zero of=/dev/fd0 bs=512
Hi Zander!
Vieleicht kannst Du mir ja mal kurz erklären, *wann* oder *warum* ich die Blockgrösse angeben muss. Und woher ich die richtige Blockgrösse weis.
Geht es nicht auch ohne diese Angabe?
Gruß,
Taylor
Vieleicht kannst Du mir ja mal kurz erklären, *wann* oder *warum* ich die Blockgrösse angeben muss. Und woher ich die richtige Blockgrösse weis.
Geht es nicht auch ohne diese Angabe?
Ich habe die Blockgröße angegeben, weil ich mir das bei meinen ersten UNIX Gehversuchen so angewöhnt und hier nicht weiter darüber nachgedacht habe; bitte entschuldigt, falls ich für Verwirrung gesorgt haben sollte.
Notwendig ist dieser Schritt hier aus zweierlei Gründen nicht: dd benutzt standardmässig eine Blockgröße von 512 Bytes und Linux behandelt I/O mit Blockgeräten (mit Ausnahme von RAW I/O Geräten und ggf. Bandlaufwerken, die sich meiner Kenntnisse entziehen) über einen zentralen Cache (buffer cache); die dd Blockgröße entspricht also nicht zwingend der physikalischen Blockgröße der jeweiligen Hardware und ist somit als logischer Wert zu verstehen. Auf anderen UNIX Systemen kann das Verhalten abweichen (möglicherweise ist die Blockgröße auf einigen Systemen und Komponenten leistungsrelevant), im Endeffekt hängt es davon ab, wie der Kernel und die jeweiligen Gerätetreiber mit Blockgrößen umgehen, die nicht der physikalischen Blockgröße der korrespondierenden Hardwarekomponenten entsprechen, insbesondere wenn es keine Vielfachen dieser sind; falls bestimmte Blockgrößen als fehlerhaft gewertet werden, so wird das im Verlauf des read(2) Systemrufs festgestellt und gemeldet; dd wird sich dann entsprechend dazu äussern (also z.B. I/O Fehler oder partielle Transfers melden).
Solaris auf SPARC hat eine Blockgrösse von 1024 ;)
cu
adme
Hi,
Ich wollte mal etwa 20GB von einer SCSI-Platte auf eine andere kopieren. Mit bs=512 hätte es etwa 4Std gedauert, mit bs=1k waren es 20min.
Ciao, Bernie
Ulli Ivens
08.01.03, 10:37
Das heist ich könnte mir z.B. ein Backup von meiner HD anlegen mit
dd if=/dev/hdx1 | gzip > image.gz bs=1k
Und dann würde die Sicherung nicht mehr eine Stunde sondern nur noch ca. 20 Minuten dauern oder wie ??
Mich wundert immer das das so lange dauert.
Außerdem ist die Komprimierung irgendwie dürftig... die HD ist fast leer (5 von 20 Gigs sind belegt) und die Sicherung ist 7 Gigs groß....)
Falls jemand noch nen tip dazu hat währe ich auch dankbar...
Original geschrieben von Ulli Ivens
Außerdem ist die Komprimierung irgendwie dürftig... die HD ist fast leer (5 von 20 Gigs sind belegt) und die Sicherung ist 7 Gigs groß....)
Falls jemand noch nen tip dazu hat währe ich auch dankbar...
Vieleicht hilft es, den freien Festplattenplatz vor dem Backup einheitlich mit Nullen zu beschreiben.
dd if=/dev/zero of=/freier/platz/grosse_datei_mit_lauter_nullen
Wenn man sowas auf / oder /var anwendet, wird es warscheinlich Probleme geben. Aber Backups von / macht man ja ansich eh im Single User Mode, oder? Dann sollte das IMHO ungefährlich sein.
Wenn das irgenwann fertig ist (abbricht :cool: ) kannst Du die Datei ja wieder löschen.
Gruß,
Taylor
Ulli Ivens
08.01.03, 11:20
Hhm... das werde ich mal versuchen...
Das Backup mache ich immer von knoppix aus. Mein System läuft dann gar nicht !
Hi,
Du hast dann das Problem, dass das Komprimieren einige Zeit dauern wird, und ich weiss auch nicht genau in welchem Zustand der >2GB Filesystem Support von Linux jetzt ist. Meine bs=1k Theorie funktioniert glaub ich nur für SCSI-Systeme da IDE-Systeme sowieso 512k Blocks verwenden.
Ciao, Bernie
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.