Gerhard Gaussling schrieb: > und ich dachte, trotz meiner fast (immer noch :-( ) nicht > vorhandenen Shellkenntnisse das schon richtig verstanden zu haben > und entsprechend abwandeln zu k�nnen.
Kein Vorwurf. Ist auch f�r mich hilfreich zu sehen, an welchen Stellen solche Tipps nicht ganz narrensicher sind oder schlecht funktionieren. Und zu guter letzt habe ich peinlicherweise genau den gleichen Fehler gemacht und etwas gewohntes mal noch ein klein wenig abge�ndert, in dem Glauben, dass es keine Nebenwirkungen hat. Ich hoffe, Du bist so weise und testest die neue Partitionsinstallation erst ausf�hrlich, bevor die alte wegfliegt und Du hast schon gemerkt, dass die absoluten symbolischen Links (z.B. in /etc/alternatives) im Eimer sind. Die Ursache ist die Option "S" bei tar. Ich dachte, auch diese (eher seltene) Eventualit�t noch mit abzufangen, wobei die Nebenwirkung ist, dass er absolute symbolische Links, die w�hrend des Kopierens nicht aufl�sbar sind, auf Null eindampft - b�se Falle. Nun, was sind eigentlich "sparse" Dateien? Vielleicht dazu erst eine kurze Erkl�rung. Von alleine, wirst Du typischerweise keine auf Deinem System haben. Man kann bei Dateien, die zu grossen Teilen aus Nullwerten bestehen, diese Bereiche aussparen. Das heisst, es wird nur die Gr�sseninformation in den Verzeichnissen gespeichert. Eigentliche Datensektoren werden nicht belegt. Ein Beispiel: dd if=/dev/zero of=testdatei bs=1k count=1 seek=1G erzeugt eine Datei mit ca. 1 GiB (exakt 1GiB+1KiB). Das geht aber nicht nur �berraschend schnell, sondern es wurde neben den Verzeichnis- informationen auch tats�chlich nur 1KiB auf der Platte verbraucht. Durch den seek wird nur der letzte Datensektor wirklich geschrieben. Den wirklichen Platzverbrauch kann man mit "ls -lsa" sehen. Erst wenn weitere Daten innerhalb der Datei ver�ndert werden, werden die dazu n�tigen Sektoren angelegt. Dieser Mechanismus ist hilfreich, wenn man Dateisystem-Images angelegt, die beispielsweise mit User-Mode-Linux verwendet werden. Dann befindet sich dessen Dateisystem innerhalb einer Datei, die im normalen Dateisystem des Hosts gespeichert wird. Nach der Grundinstallation eines Debian-Linux, wird innerhalb so einer Datei dann nur Platz f�r 100 MiB ben�tigt. Auf der anderen Seite, will man noch Freiraum f�r die Zukunft haben. Also lege ich eine Containerdatei mit 1 GiB an. Und wenn ich zwei dutzend solcher Installationen habe, dann habe ich in den Verzeichnis Dateien im Umfang von 24 GiB stehen, die auf der Platte aber im Moment nur 2,4 GiB Platz verbrauchen. Und genau an diesem Punkt liegt das Problem mit dem Umkopieren begraben. Bei einem normalen Umkopieren, werden aus den gel�cherten sparse Dateien, ganz normale Dateien in voller Gr�sse, ausser man macht entsprechende Angaben. Ich denke, dass man weiss, wenn man solche Dateien hat, weil Sie meistens absichtlich angelegt werden. Selbst zum nachtr�glichen L�chern gibt es Tools (Kommando "zum" - Paket "perforate"). Von daher widerufe ich mein Geschw�tz von (vor-)gestern und denke, dass folgende Verfahren alle Eventualit�ten abdeckt: o Booten von Rettungsystem o Verzeichnisse /neu und /alt in der Ramdisk anlegen o mount /dev/altbla /alt -r o mkfs.bla /dev/neubla ; mount /dev/neubla /neu o cp --sparse=always -av /alt/. /neu 2>errors | tee listing Wobei das "--sparse=always" ein ziemlicher Durchsatzfresser (nicht getestet) sein d�rfte. Wenn man also weiss, keine solchen Dateien in grossem Umfang zu haben, kann man sich's komplett sparen. -- [EMAIL PROTECTED] -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
