* On Sun, 22 Sep 2002 at 16:52 -0700, Sebastian Huber wrote:
On Sunday 22 September 2002 07:17, Adalbert Michelic wrote:
Sebastian,
bitte schnapp Dir mal http://learn.to/quote als Nachmittagslektüre zur Entspannung.
Ok, die Zitate waren ueberfluessig.
Ich meinte eigentlich, daß die oebenrauf sollen, so wie Du es jetzt auch gemacht hast. Ich finds beim Lesen ein wenig unpraktisch, wenn man unten anfangen muß :-)
* On Sun, 22 Sep 2002 at 15:39 -0700, Sebastian Huber wrote:
On Sunday 22 September 2002 15:34, Sebastian Huber wrote:
[...]
bei dd kannst du einstellen, was kopiert werden soll. Z.B. /dev/hda die ganze Platte oder /dev/hda1 nur eine Partition. Ich wuerde 'dd if=/dev/hda | bzip2 filesonstwas.bz2' probieren. Habe ich aber noch nie getestet. Wenn die Ausgabedatei zu gross wird, kann man die auch splitten 'dd if=/dev/hda | bzip2 | split --bytes=1000m - filesonstwas.bz2.'.
weiss eigentlich jemand, was passiert, wenn Eingabe und Ausgabe auf der selben Platte bzw. Partition liegen? Das ist glaub ich nicht so optimal.
Nun, in diesen Falle muß der Kopf der Platte ständig zwischen der Position wechseln, an der gelesen wird und der Position, an der geschrieben wird. Das hat zur Folge, daß erstens die Platte viel Krach macht, und zweitens, daß das ganze sehr langsam wird. Und die Lebensdauer der Mechanik wirds bei größeren Datenmengen auch nicht gerade positiv beeinflussen.
Ich war wohl etwas zu unpraezise. Ein dd von einer Platte, auf die gerade geschrieben wird ist glaub ich nicht gut, da das Image dann ja unterschiedliche Zustaende des Dateisystems speichert.
Ach so meintest Du das. Ja stimm auch, eine Partition zu kopieren, auf die man schreibt, ist nicht so sonderlich gut. Da hast Du nachher einen Datensalat.
Deshalb ist es wohl besser man bootet ein Rettungssystem, mountet die Platte gar nicht oder hoechstens readonly und kopiert auf eine andere Platte oder einen Teil, der Platte, der nicht gelesen wird.
Jupp. Zur Schonung der Nerven würde ich bei größeren Datenmengen unbedingt empfehlen auf eine andere Platte oder übers Netzwerk zu kopieren. Wenn die Daten ungünstig liegen, kann bei einer Kopie auf die gleiche Platte die Datenrate auf ein unerträgliches Maß absinken.
Ist das mit der Mechanik wirklich so kritisch, die Ein- und Ausgabe ist ja gepuffert?
Ja, die Pufferung fängt schon ein bißchen was ab. Allerdings sind diese Blöcke AFAIk trotzdem relativ klein, mal eine Modellrechnung: 10 GiB Daten in 32 kiB (Hausnummer) Blöcken, macht also 327680 Einzelblöcke. Sind damit im schlimmsten Fall 327680 Seeks zur Lesestelle und 327680 zur Schreibstelle, macht 655360 Seeks. Macht bei einer angenommenen Dauern von 7ms pro Seek schon mal 4587 Sekunden herumgeseeke, sprich 1 Stunde 16 Minuten. Heißt die Datenrate kommt nicht über 2200 kiB/sec. Merkt man bei einem Versuch recht schön, wenn man den Datenstrom durch buffer -z1k piped - Bis der Cache vollgelaufen ist, gehts recht flott. Dann fängt Linux zwangsläufig zum Schreiben an, ab da geht fast nichts mehr weiter. Auf die Hardware wirds bei ein- oder zweimaliger Ausführung keine Auswirkung haben, wenn sowas aber oft gemacht wird, kann ich mir nicht vorstellen, daß das gut für die Mechanik ist. Für solche Tätigkeiten würde ich mir ein Programm wünschen, daß nicht parallel liest und schreibt, sondern das abwechselnd und durch syncs getrennt macht ... :-) -- Adalbert PGP welcome, request public key: mailto:adalbert+key@lopez.at