Mailinglist Archive: opensuse-de (4628 mails)

[Adalbert Michelic <adalbert+list@xxxxxxxx>]

* 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@xxxxxxxx