Hallo, On Fri, 04 Jul 2003, Michael Messner schrieb:

David Haller <david@dhaller.de> 07/03 5:50 >>>

...

On Thu, 03 Jul 2003, Michael Messner schrieb:

...

Z.B.: mit Yast das Dateisystem der vorh. Partition ändern (hdb3) Rettungssystem booten, ein Verzeichnis von / umkopieren auf die neue Platte, alte Daten in Sicherungsverzeichnis schieben, neuen Mount-Punkt anlegen, /etc/fstab anpassen und neu booten, wenn alles gut geht dann kannst du die Sicherung wieder löschen!

...

Wozu booten? Wenn's nicht gerade um /var/ geht, laesst sich sowas wunderbar auch ohne booten machen. Ok, init 1 ist empfehlenswert.

Im Ernst?

Na aber sicher! Du musst nur dafuer sorgen, dass deine User (insbesonder du selbst ;) nicht waehrend des Kopierens die alte Partition aendern, ein init 1 / und oder 'mount -o remount,ro' wirkt da aber Wunder... Die neue Partition legt man vorher in aller Ruhe an. Die haengt man dann irgendwo ein, z.B. unter /mnt/ und kopiert dann die Daten mit cd <quelle>; tar cp --atime-preserve . \ | (cd <temp_ziel>; tar xp --atime-preserve;); sync; sync auf die neue Partition. Dann die neue wieder unmounten. Dann kommt der "kritische" Moment: mv ./mountpunkt ./mountpunkt_alt \ && mkdir ./mountpunkt \ && mount /dev/hdXY ./mountpunkt sync; sync Bei diesem Befehls-tripel hat man eine "race-condition", wobei IMO der "worst-case"[3] auch noch ertraeglich ist. Hat man bisher nur eine Partition, so muss man natuerlich vor dem 'mv' die Partition wieder rw remounten, und handelt sich damit eine weitere race-condition ein, in dem Fall sollte man also auch mind. init 1 bemuehen. Probleme gibt's immer genau dann, wenn Dateien der Quellpartition/-verzeichnisse (schreibend) geoeffnet sind. Anschliessend passt man noch die fstab an, und das wars auch. So hab ich u.a. schon mehrfach meine /var-Partition umgezogen. Sind keine Dateien (schreibend) offen, gibt's keine Probleme. Siehe dazu auch 'man lsof' und 'man fuser'. Bei mir ist historisch bedingt inzwischen ein Grossteil des Systems auf diverse Partitionen verteilt und per symlinks eingebunden, so u.a. /var, /tmp, /opt/ (und in /var/ und /opt/ sind dann wieder symlinks auf wieder andere Partitionen ;) Ich komm einfach nicht dazu, das aufzuraeumen, und bei einem so alten[5] System wie meinem passiert sowas eben, wenn mal die eine oder andere Partition voll wird[4]... Und wie gesagt: ein reboot ist nicht noetig, nach Aenderungen der Partitionierung[1] aber generell eher angebracht. Das haengt aber nur damit zusammen, wie der Kernel die Partitionen verwaltet, da klappt eine Aenderung im Betrieb nicht immer ganz sauber. Will man aber z.B. nur eine FAT in ein ext3 umwandeln, so muss man nur den Typ umsetzen, formatieren und weiter wie oben. In dem Fall ist ein reboot nicht noetig, da sich der Kernel eh nicht weiter um den FS-Typ schert[2]. Achso, die meisten "Umzuege" (von Daten, eben nicht gerade /home, /usr/{bin,lib}, /var usw.) habe ich im root-xterm gemacht, und nebenher froehlich News oder Mails gelesen, ferngeschaut, gespielt... -dnh [1] d.h. Aenderungen der Groessen oder neue / geloeschte Partitionen [2] ich hatte mal vergessen den FS-Typ zu aendern... Aufgefallen ist mir das erst Wochen spaeter, als ich mal wieder Win bootete und ein komisches LW, auf das sich nicht zugreifen liess, sah (klar, war ja auch ein reiserfs drauf ;) [3] ggfs. wird eben in Dateien geschrieben, die dann durch's mounten verdeckt werden... Daher sollte man eben Vorkehrungen treffen... [4] / ist inzwischen auf der 4ten Festplatte... Der Rest ist mehr oder weniger parallel mitgewandert oder auch nicht ;) Und wenn's eng wird, dann schaufelt man eben rum ;) [5] und "aktiven", also nix von wegen "never change a running system" ;) -- It takes a million monkeys at typewriters to write Shakespeare, but only a dozen monkeys at computers to run Network Solutions. -- Patrick Delahanty