Grub geom error nach Update auf 9.2: solution
Hallo, ich habe jetzt eine Lösung für ein Problem, das hier auf der Liste schon diskutiert wurde. Nachdem dem Update auf 9.2 blieb die Kiste mit einem "grub geom error" hängen, obwohl vorher alles prima funktionierte. Problem war, dass die Installationspartition auf einer 160 GB-Platte am Ende lag. Bei der Installation von 9.0 landeten die kernels noch vor der 128GB Grenze, bei 9.2 dahinter, so dass grub keine korrekten 32bit-LBA-Adressen zum Laden des kernels erzeugen konnte. Nach dem Kopieren und Löschen einiger alter Files entstand am Beginn der Partition wieder freier Platz. Jetzt nochmal den kernel kopieren, so dass er im soeben entstandenen freien Platz am Beginn der Partition landet, sicherheitshalber ein grub-install und schon bootet die Kiste wieder :-) Ich hoffe, das hilft vielleicht dem einen oder anderen weiter ... Gruss, Rainer
On Monday 14 February 2005 18:26, Rainer Kaluscha wrote:
Nachdem dem Update auf 9.2 blieb die Kiste mit einem "grub geom error" hängen, obwohl vorher alles prima funktionierte. Problem war, dass die Installationspartition auf einer 160 GB-Platte am Ende lag. Bei der Installation von 9.0 landeten die kernels noch vor der 128GB Grenze, bei 9.2 dahinter, so dass grub keine korrekten 32bit-LBA-Adressen zum Laden des kernels erzeugen konnte. Nach dem Kopieren und Löschen einiger alter Files entstand am Beginn der Partition wieder freier Platz. Jetzt nochmal den kernel kopieren, so dass er im soeben entstandenen freien Platz am Beginn der Partition landet, sicherheitshalber ein grub-install und schon bootet die Kiste wieder :-)
Das hört sich aber sehr wackelig an. Eine /boot Partition am Anfang der Platte ist sicher besser, oder? Torsten
Torsten Foertsch schrieb:
Das hört sich aber sehr wackelig an. Eine /boot Partition am Anfang der Platte ist sicher besser, oder? Möglicherweise ja ...
Über Sinn und Unsinn von Boot-, Swap- und sonstigen Partitionen könnte man aber auch lange diskutieren :-) In diesem Fall gibt es aber eine Vorgeschichte: nach dem vorzeitigen Ableben einer 120GB-Platte (wo es das Problem nicht gab) hatte ich einfach die 160GB-Platte eingebaut und die root-Partition vergrössert, was bis zum Update prima funktionierte - erst dann wurde das Problem evident und ich brauchte eine "einfache" Lösung. Gruss, Rainer
Hallo, Am Mon, 14 Feb 2005, Torsten Foertsch schrieb:
On Monday 14 February 2005 18:26, Rainer Kaluscha wrote:
Nachdem dem Update auf 9.2 blieb die Kiste mit einem "grub geom error" hängen, obwohl vorher alles prima funktionierte. Problem war, dass die Installationspartition auf einer 160 GB-Platte am Ende lag. Bei der Installation von 9.0 landeten die kernels noch vor der 128GB Grenze, bei 9.2 dahinter, so dass grub keine korrekten 32bit-LBA-Adressen zum Laden des kernels erzeugen konnte. Nach dem Kopieren und Löschen einiger alter Files entstand am Beginn der Partition wieder freier Platz. Jetzt nochmal den kernel kopieren, so dass er im soeben entstandenen freien Platz am Beginn der Partition landet, sicherheitshalber ein grub-install und schon bootet die Kiste wieder :-)
Das hört sich aber sehr wackelig an. Eine /boot Partition am Anfang der Platte ist sicher besser, oder?
Das finde ich heutzutage nicht mehr sinnvoll. Ich bevorzuge seit einiger Zeit folgendes Schema (fuer Platten >= 8 GB oder so). /-Partition ~500 MB, enthaelt /bin, /boot(!), /dev, /etc, /lib, /root und /sbin (sowie die mountpoints) aber nicht /tmp[1]. swap-Partition /tmp ist ein symlink nach /var/roottmp Wer sich noch nicht auskennt sollte '/' entsprechend groesser (~1.5-2 GB) machen und auch /var auf der /-Partition liegen lassen, denn wenn man mal z.B. in den runlevel S bootet, dann fehlen /tmp und /var. /var-Partition: nach Bedarf, z.B. 500-1500 MB, enthaelt das uebliche plus /var/roottmp/. Fette Brummer woie /var/spool (/var/mail, /var/news), evtl. weitere "Datenverzeichnisse" wie z.B. /var/mysql, /var/lib/rpm usw. kann man bei Bedarf leicht auslagern und per symlink einbinden. Achtung: nen leafnode-newsspool darf man nicht einfach kopieren. Siehe sdb-Artikel 'maddin_kopieren'. Der Rest wird nach Bedarf zwischen /home, /usr und ggfs. weiteren Partitionen aufgeteilt wobei /opt ein symlink auf /usr/opt oder so sein kann. Evtl. haelt Yast beim Installieren die /-Partition fuer zu klein, dann kann man z.B. KDE erst anschliessend installieren. Wobei bei obiger Dimensionierung der /-Partition wird's zwar knapp, aber KDE sollte mit draufpassen (landet dank symlink aber in /usr/opt, nur sonst meckert YaST). Achso: /srv/ oder so ist da nicht beruecksichtigt, das wuerde ich wie /var/mysql behandeln. -dnh, mit seiner aktuellen Installation (Juli '99 installiert) schon von der urspruenglichen Platte auf die 5te oder 6te Festplatte und von ext2 ueber reisswolffs zu ext3 migriert. Mit Umpartitionierung/-formatierung, verlinken und rumkopieren der Daten habe ich also Erfahrung ;) [1] # du -hsx /{bin,boot,dev,etc,lib,root,sbin}/ 6.5M /bin 55M /boot 92k /dev 8.3M /etc 86M /lib 40M /root 14M /sbin Also gut 200 MB. Und dabei liegt v.a. in /root/ einiges Ueberfluessige. Und 24 Kernels (samt Modulen) haben wohl wenige in /boot und /lib rumfliegen, oder? Noch Fragen? -- Ich sehe schon, bald kommen diese "haste ma ne Maak"-Typen am Bahnhof nicht mehr mit Pappbechern, sondern mit diesen Geraeten zum Geldkartenauslesen.... -- V. Regina Kappes
Am Montag, 14. Februar 2005 22:14 schrieb David Haller:
(...). /-Partition ~500 MB, enthaelt /bin, /boot(!), /dev, /etc, /lib, /root und /sbin (sowie die mountpoints) aber nicht /tmp[1]. (...).
/boot? Meine persönliche Erfahrung mit einem journaling FS und /boot auf /: grub versteht ja das FS. Mir scheint es so, als würde es bei jedem Zugriff das Journal (im RAM?) "replayen". Sprich, nach einem Absturz o. ä. dauert es ewig, bis "gebootet" wird ... MfG, Jan -- There is more to fear from an army of 100 sheep led by a lion, than an army of 100 lions led by a sheep.
Hallo, Am Mon, 14 Feb 2005, Jan Ritzerfeld schrieb:
Am Montag, 14. Februar 2005 22:14 schrieb David Haller:
(...). /-Partition ~500 MB, enthaelt /bin, /boot(!), /dev, /etc, /lib, /root und /sbin (sowie die mountpoints) aber nicht /tmp[1]. (...).
/boot? Meine persönliche Erfahrung mit einem journaling FS und /boot auf /: grub versteht ja das FS. Mir scheint es so, als würde es bei jedem Zugriff das Journal (im RAM?) "replayen". Sprich, nach einem Absturz o. ä. dauert es ewig, bis "gebootet" wird ...
$ mount /dev/root / ext3 rw 0 0 Keine Probleme. Boot ist so schnell wie mit ext2. Normal habe ich aber ein ext2 auf der /-Partition (was bei der Groesse[1] ja auch geht ;), ich bin grad nur am Umziehen auf ne neue HDD und die /-Partition macht grad auf obiger ext3 Zwischenstation *g* und ich muss erst wieder sortieren. Und dazu habe ich halt grad keine Zeit, da ich umziehe. Allerdings verwende ich LILO (und Grub) und nen Vanilla-Kernel 2.4.25. Hatte aber auch mit Grub noch keine Probleme. Achso: nach einem Absturz (hatte ich lange nicht) bootet das Teil ganz normal, bis auf die 1-2s fuer's Replay. Mit ext2 hab ich dann halt ein paar Sekunden mehr fuer den fsck. Der Rest landet bei mir dann auf ext3. -dnh [1] und ich mach meine naechste /-Partition wieder kleiner, aktuell ist's ne 20G Partition, aber da ist sie nur zwischendurch. Ich denke so an 500-750 MB oder noch weniger ;) -- - Macs sind für die, die nicht wissen wollen, warum Ihr Rechner funzt. - Linux ist für die, die wissen wollen, warum er funzt. - DOS ist für die, die wissen wollen, warum er nicht funzt, und - Windows ist für die, die nicht wissen wollen, warum er nicht funzt.
Am Dienstag, 15. Februar 2005 00:36 schrieb David Haller:
(...). Allerdings verwende ich LILO (und Grub) und nen Vanilla-Kernel 2.4.25. Hatte aber auch mit Grub noch keine Probleme.
Mit LILO hatte ich da auch keine Probleme, sonst hätte ich das beim damaligen Umstieg auf SL 9.0 nicht wieder so eingerichtet. :-)
Achso: nach einem Absturz (hatte ich lange nicht) bootet das Teil ganz normal, bis auf die 1-2s fuer's Replay. (...).
Es schien mir so, als würde GRUB das Replay (im RAM?) für jede Datei machen, die er da so öffnet, damit dauerte das dann eben n * 10 s.
[1] und ich mach meine naechste /-Partition wieder kleiner, aktuell ist's ne 20G Partition, aber da ist sie nur zwischendurch. Ich denke so an 500-750 MB oder noch weniger ;)
Die Partition, bei der ich dieses lahme Booten nach einen Absturz erlebt habe, ist 120 GB groß. Da dauert das Mounten auch ohne Journal-Replay schon ein wenig. MfG, Jan -- Don't force it, get a larger hammer.
Hallo, Am Fri, 18 Feb 2005, Jan Ritzerfeld schrieb:
Am Dienstag, 15. Februar 2005 00:36 schrieb David Haller: [..]
Achso: nach einem Absturz (hatte ich lange nicht) bootet das Teil ganz normal, bis auf die 1-2s fuer's Replay. (...).
Es schien mir so, als würde GRUB das Replay (im RAM?) für jede Datei machen, die er da so öffnet, damit dauerte das dann eben n * 10 s.
Grub hat damit gar nichts zu tun. Das Replay findet bei ext3 und reiserfs erst (nur) beim mounten statt. -dnh -- Auch ich rate von Sandpapier dringend ab! Ein Fehler, der, besonders von Anfängern, immer wieder gemacht wird! Ein Spritzer Pril auf 1/2 Tasse Java Kaffee und damit spülen - das ist IMO wesentlich schonender. [Olaf Andersen erklärt das Putzen einer Festplatte in suse-linux]
Am Freitag, 18. Februar 2005 18:24 schrieb David Haller:
Am Fri, 18 Feb 2005, Jan Ritzerfeld schrieb: (...).
Es schien mir so, als würde GRUB das Replay (im RAM?) für jede Datei machen, die er da so öffnet, damit dauerte das dann eben n * 10 s.
Grub hat damit gar nichts zu tun. Das Replay findet bei ext3 und reiserfs erst (nur) beim mounten statt.
Das dachte ich auch, aber was hat grub dann so lange gemacht?! MfG, Jan -- Whatever hits the fan will not be evenly distributed.
David Haller schrieb:
Das finde ich heutzutage nicht mehr sinnvoll. Ich bevorzuge seit einiger Zeit folgendes Schema (fuer Platten >= 8 GB oder so).
/-Partition ~500 MB, enthaelt /bin, /boot(!), /dev, /etc, /lib, /root und /sbin (sowie die mountpoints) aber nicht /tmp[1].
swap-Partition
/tmp ist ein symlink nach /var/roottmp
...
Wie schon gesagt - über Sinn und Unsinn verschiedener Partitionen lässt sich trefflich streiten :-> M.E. sind diese vielen Partitionen ein alter Zopf mit vielen Nachteilen: Irgendeine Partition ist immer zu klein, abwechselnder Zugriff auf verschiedene Partitionen erzwingt lange Kopfbewegungen (langsam) etc. Vorteile sehe ich hingegen keine ... In der Regel lege ich nur eine grosse Partition pro Platte an (bzw. eine pro OS bei Multiboot-Systemen + 1x FAT32 für gemeinsame Daten).
Hallo, Am Tue, 15 Feb 2005, Rainer Kaluscha schrieb:
M.E. sind diese vielen Partitionen ein alter Zopf mit vielen Nachteilen:
1, 2, 3, viele? (inkl. swap). *scnr*
Irgendeine Partition ist immer zu klein, abwechselnder Zugriff auf verschiedene Partitionen erzwingt lange Kopfbewegungen (langsam) etc.
Sehe ich nicht so.
Vorteile sehe ich hingegen keine ...
Datensicherheit, Einfachheit von Updates / Backups usw... Wie gesagt: das sind meine Erfahrungen nach viel rumprobieren. -dnh -- Reporter (to Mahatma Gandhi): Mr Gandhi, what do you think of Western Civilization? Gandhi: I think it would be a good idea.
Am Dienstag, 15. Februar 2005 17:51 schrieb David Haller:
Vorteile sehe ich hingegen keine ...
Datensicherheit, Einfachheit von Updates / Backups usw...
Wie gesagt: das sind meine Erfahrungen nach viel rumprobieren.
Man wird zwar nie die Partitonsgröße optimal voraussehen, aber ich war schon mehrmals ziemlich froh partitioniert zu haben, weil ich dann noch die Daten von anderen Partitionen retten konnte. Ich "schwör" auf Partitionen mit smartd. Leider funktioniert smartd mit S-ATA HDs und 9.2 nicht. Mit dem Kernel auf der 9.1-DVD kann man allerdings die S-ATA-HD mit smartctl testen. Al
Hallo, Am Wed, 16 Feb 2005, Al Bogner schrieb:
Am Dienstag, 15. Februar 2005 17:51 schrieb David Haller:
Vorteile sehe ich hingegen keine ...
Datensicherheit, Einfachheit von Updates / Backups usw...
Wie gesagt: das sind meine Erfahrungen nach viel rumprobieren.
Man wird zwar nie die Partitonsgröße optimal voraussehen, aber ich war schon mehrmals ziemlich froh partitioniert zu haben, weil ich dann noch die Daten von anderen Partitionen retten konnte.
ACK. Und ausserdem: es ist normalerweise absolut kein Problem, Daten einer Partition auf eine andere zu verschieben. Bei mir ist z.Z. das komplette Chaos, nix ist da, wo's eigentlich hin soll. Der Dateibaum selbst aber, der sieht besser aus als ich sonst oft hatte. Die Mountpunkte bei mir sind z.Z. _alle_ faschsl! Auch / und /home. Notloesung eben. Aber kein Problem. Ich hab nur einige symlinks umbiegen bzw. anlegen muessen usw. Und wenn ich was uebersehen habe, habe ich das dann schon gemerkt und "nachgezogen". Und was das umziehen von Daten angeht: da nimmt man sich eben mal ein paar Minuten Zeit.
Ich "schwör" auf Partitionen mit smartd. Leider funktioniert smartd mit S-ATA HDs und 9.2 nicht. Mit dem Kernel auf der 9.1-DVD kann man allerdings die S-ATA-HD mit smartctl testen.
Stimmt, die sollte ich mir auch mal endlich kompilieren, inzwischen koennen meine Platten ja SMART ;) -dnh -- With so many "textbook cases" of single points of failure, you'd think that we'd stop building systems to demonstrate the concept. - Matt Curtin
David Haller schrieb:
Hallo,
Am Tue, 15 Feb 2005, Rainer Kaluscha schrieb:
Irgendeine Partition ist immer zu klein, Früher habe ich öfter Daten verschieben und mit symlinks tricksen müssen, weil mal wieder eine Partition voll war. Schlimme Sachen habe ich auch bei vorkonfigurierten Servern von Dell (mit RedHat) gesehen: da war das rootfs nur 100 MB gross und wegen /tmp war das ruckzuck voll, so dass die Kiste hängenblieb.
Solche Probleme sind m.E. unnötig.
abwechselnder Zugriff auf verschiedene Partitionen erzwingt lange Kopfbewegungen (langsam) etc.
Sehe ich nicht so. Dazu ein Beispiel: Es werde zunächst auf Datei1, dann auf Datei2 zugegriffen.
Szenario 1: Beide befinden sich auf der gleichen Partition. Der Lesekopf der Platte muss maximal den belegten Bereich dieser Partition überwinden ... Szenario 2: Beide befinden sich auf unterschiedlichen Partitionen. Der Lesekopf der Platte muss maximal die erste sowie alle dazwischenliegenden Partitionen (belegte und *leere* Bereiche) sowie den belegten Bereich der Zielpartition überwinden ... Die beiden Szenarien nähern sich mit zunehmendem Füllungsgrad der Platte allerdings aneinander an.
Vorteile sehe ich hingegen keine ...
Datensicherheit, Einfachheit von Updates / Backups usw...
Das verstehe ich nicht: wenn die Platte im Eimer ist, spielt es keine Rolle, auf wieviele Partitionen die Daten verteilt sind, oder ? Und Backups kann ich auch nach directories getrennt vornehmen ... Auch bei Updates sehe ich keinen Vorteil - es wird ja das gesamte System geupdated und nicht nur die /usr-Partition (bzw. Verzeichnis).
Am Mittwoch, 16. Februar 2005 13:03 schrieb Rainer Kaluscha:
David Haller schrieb:
Vorteile sehe ich hingegen keine ...
Datensicherheit, Einfachheit von Updates / Backups usw...
Das verstehe ich nicht: wenn die Platte im Eimer ist, spielt es keine Rolle, auf wieviele Partitionen die Daten verteilt sind, oder ?
Aber wenn nur das _Dateisystem_ hinüber ist, dann mußt du nur eine Partition flicken, weil nicht _alle_ Daten davon betroffen sind.
Und Backups kann ich auch nach directories getrennt vornehmen ...
Wenn du Images als Backup machst, dann spielt das durchaus eine Rolle. Gruß, Michael -- ____ / / / / /__/ Michael Höhne / / / / / / mih-hoehne@t-online.de / _____________________________________/
Michael Hoehne schrieb:
Aber wenn nur das _Dateisystem_ hinüber ist, dann mußt du nur eine Partition flicken, weil nicht _alle_ Daten davon betroffen sind. Was heisst nur das _Dateisystem_ ? Ein bad block in den Verwaltungsstrukturen o.ä. ? Dafür gibt es ja z.B. Backups des Superblocks etc. Und wenn eine Platte bad blocks entwickelt, wird es ohnehin Zeit, sie auszutauschen ...
Wenn du Images als Backup machst, dann spielt das durchaus eine Rolle. Images ziehe ich nur bei Windoofs, da man dort nicht alles einfach im laufenden Betrieb sichern kann. Bei Linux sehe ich keinen Vorteil eines Images gegenüber einem tar-Archiv o.ä. - im single user mode lässt sich das auch von einem read only gemounteten rootfs problemlos erzeugen.
Hallo Rainer, hallo Leute, Am Mittwoch, 16. Februar 2005 14:33 schrieb Rainer Kaluscha:
Michael Hoehne schrieb:
Aber wenn nur das _Dateisystem_ hinüber ist, dann mußt du nur eine Partition flicken, weil nicht _alle_ Daten davon betroffen sind.
Was heisst nur das _Dateisystem_ ? Ein bad block in den Verwaltungsstrukturen o.ä. ? Dafür gibt es ja z.B. Backups des Superblocks etc. Und wenn eine Platte bad blocks entwickelt, wird es ohnehin Zeit, sie auszutauschen ...
Es gibt auch Fälle, in denen ein Dateisystem ohne Hardwaredefekt Fehler abbekommen kann. Ich nenne nur mal den "harten Shutdown" aka Stromausfall...
Wenn du Images als Backup machst, dann spielt das durchaus eine Rolle.
[...] Bei Linux sehe ich keinen Vorteil eines Images gegenüber einem tar-Archiv o.ä. -
5.1. Warum ist .tar.gz oder .tar.bz2 nicht fürs Backup geeignet? http://suse-linux-faq.koehntopp.de/q/q-backup-nicht_targz.html
im single user mode lässt sich das auch von einem read only gemounteten rootfs problemlos erzeugen.
Und wo legst Du das Backup ab, wenn die einzige Partition read-only gemountet ist? *SCNR* Ach so, da wir gerade beim Thema Partitionierung sind, will ich auch meinen Senf dazu abgeben ;-) /home gönne ich grundsätzlich eine eigene Partition. Hat Vorteile, wenn man abwechselnd 2 Systempartitionen nutzt (jeweils eine wird upgedated, auf der anderen liegt das "alte" System für Notfälle). Außerdem habe ich /home verschlüsselt. Sicher ist sicher ;-) Ob man andere Verzeichnisse (/var, /var/spool, /tmp, ...) auf jeweils eine eigene Partition auslagert, ist eher Ansichtssache. - Für getrennte Partitionen spricht, dass z. B. ein überlaufendes Logfile nicht auch gleich den Platz für /tmp oder Mails blockiert. Dieses Argument ist für Server wichtiger als beim heimischen PC. - Für eine große Partition spricht die einfachere Abschätzung der benötigten Größe ;-) Gruß Christian Boltz --
Jetzt, wo du es sagst. Ich benutze aber immer cat. Auch wenn ich mit grep eine Datei durchsuchen will. Keine Ahnung warum. Ich glaube, dass ich das mal am Anfang irgendwo gelesen habe, und dann hat es sich ins Hirn eingebrannt. *tsk* Ich glaub, wir muessen dich mal einer Gehirnwaesche unterziehen... [> Marcus Habermehl und David Haller in suse-linux]
Christian Boltz schrieb: > Es gibt auch Fälle, in denen ein Dateisystem ohne Hardwaredefekt Fehler > abbekommen kann. Ich nenne nur mal den "harten Shutdown" aka Stromausfall... Dann habe ich bei n Filesystemen möglicherweise auch n Fehler ... > 5.1. Warum ist .tar.gz oder .tar.bz2 nicht fürs Backup geeignet? > http://suse-linux-faq.koehntopp.de/q/q-backup-nicht_targz.htm Für bzip2 gibt es m.W. ein recovery-tool (bzip2recover), um aus beschädigten Archiven evtl. noch Daten zu retten. Bei gzip geht das wohl nicht - dafür komprimiert es deutlich schneller ... >> im single user mode lässt sich das auch von einem read only gemounteten >> rootfs problemlos erzeugen. > > Und wo legst Du das Backup ab, wenn die einzige Partition read-only gemountet > ist? *SCNR* Am besten auf /dev/null - das geht am schnellsten :-) Wer mehr Zeit hat und das Backup ggfs. auch wieder einspielen möchte, mag eine 2. Platte, ein Band oder einen DVD-Brenner verwenden ... *SCNR, too* > /home gönne ich grundsätzlich eine eigene Partition. Hat Vorteile, wenn man > abwechselnd 2 Systempartitionen nutzt (jeweils eine wird upgedated, auf der > anderen liegt das "alte" System für Notfälle). Das rescue-System boote ich ggfs. von CD bzw. DVD ... > Außerdem habe ich /home verschlüsselt. Sicher ist sicher ;-) Granted - Encryption ist tatsächlich ein Argument für eine eigene Partition. Bei der nächsten Installation werde ich mir wohl auch so einen "Datentresor" zulegen - das Verschlüsseln einzelner Files mit pgp ist doch auf Dauer etwas lästig.
Am Donnerstag, 17. Februar 2005 11:31 schrieb Rainer Kaluscha:
Christian Boltz schrieb:
/home gönne ich grundsätzlich eine eigene Partition. Hat Vorteile, wenn man abwechselnd 2 Systempartitionen nutzt (jeweils eine wird upgedated, auf der anderen liegt das "alte" System für Notfälle).
Das rescue-System boote ich ggfs. von CD bzw. DVD ...
Was machst Du wenn das Rescue-System deine Hardware nicht vollständig unterstüzt? Ich denke hier speziell an Festplattencontroller und ähnliches. Da ist es durchaus sinnvoll, und vor allem komfortabler, eine zweite Systempartition zu haben. Ok, man kann natürlich sich ein passendes Rescue-System zusammenstellen und brennen, oder auf eins der vielen Knoppix-Derivate ausweichen, wenn da die Hardware unterstüzt wird. Eine zweite Systempartition kann bei Ausfall der Ersten auch erst mal als Ersatz für den laufenden Betrieb dienen, dabei denke ich an Heimanwender wo häufig nur ein Rechner vorhanden ist. Nicht so versierte Linuxer haben dadurch eine einfache Möglichkeit sich Hilfe aus dem Netz oder per Mail zu holen. Grüße René
On Thursday 17 February 2005 11:31, Rainer Kaluscha wrote:
Christian Boltz schrieb:
Es gibt auch Fälle, in denen ein Dateisystem ohne Hardwaredefekt Fehler abbekommen kann. Ich nenne nur mal den "harten Shutdown" aka Stromausfall...
Dann habe ich bei n Filesystemen möglicherweise auch n Fehler ...
Aber eben nicht auf den readonly gemounteten /usr /boot /bin ... Verstehst du es nicht? Asserdem ist es einfach unwahrscheinlicher, dass Du komplett alle Daten verlierst wenn Du mehrere Partitionen hast! UND! wenn ein Filesystem kaputt ist (speziell bei badblocks!) sollte man auf jedenfall ein Image ziehen und dieses reparieren. So hat man mehrere versuche, ausserdem macht es auf einer kaputten HD eh keinen Sinn. Diese Prozedure gestalltet sich um einiges einfacher und schneller wenn man kleinere Partitionen zu bewegen hat! Wenn z.B Deine (echt) groesste Platte kaputt ist musst Du Dir erst noch so eine grosse besorgen bevor Du sie ueberhaupt reparieren kannst... Naja, wenn Du unbedingt /tmp in Deinem Image dabei haben willst dann mach das...
5.1. Warum ist .tar.gz oder .tar.bz2 nicht fürs Backup geeignet? http://suse-linux-faq.koehntopp.de/q/q-backup-nicht_targz.htm
Für bzip2 gibt es m.W. ein recovery-tool (bzip2recover), um aus beschädigten Archiven evtl. noch Daten zu retten.
Aber in dem tar.bz2 steckt IMO nur ein file - also dumm wenn das kaputt ist ...
Außerdem habe ich /home verschlüsselt. Sicher ist sicher ;-)
Granted - Encryption ist tatsächlich ein Argument für eine eigene Partition. Bei der nächsten Installation werde ich mir wohl auch so einen ^^^^^^^^^^^
Aha, wie du siehst ist Deine Riesen Partition recht unflexibel sonst koenntest Du das einfach im laufenden Betrieb machen! Im uebrigen brauchtet Du bei einer Neuinstallation Deine /home Partition gar nicht anzufassen läge sie auf ner extra Partition. Desweiteren hast Du irgendwo geschrieben dass Du mehrere OS auf verschiedenen Platten hast. Wenn Du jedes OS auf mehrere Paltten verteilst, haette das auch Perfomance Vorteile. Was Du über die längeren Wege des Lese/Schreibkopfs geschrieben hast ist IMO totaler Quatsch. Erstens sortiert der Kernel sowieso die Zugriffe damit unnoetige Hin- und Herbewegungen vermieden werden und wenn Deine (beispielsweise) Datenbank (mit potenziell vielen Zugriffen) auf einer kleinen, kompakten Partition liegt dann sind die Wege kuerzer als wenn sie ueber eine Riesen Partition verstreut ist. Du scheinst es nicht verstehen zu wollen. Riesenpartitionen bringen nur Nachteile (performance, Sicherheit, Flexibilitaet), ausser dass es einfacher ist die Plattenkapazitaet voll auszunutzen. cu Ruediger
Hallo, kleine Frage zur Vollständigkeit (und zu meiner Sicherheit) hierzu: Am Donnerstag, 17. Februar 2005 12:14 schrieb Ruediger Meier: [ .. ]
Aber eben nicht auf den readonly gemounteten /usr /boot /bin ...
Ist es richtig, alles bis auf /var /tmp /home kann im Normalbetrieb readonly gemounted werden? (Beim update, install, etc natürlich nicht!) Danke, Calli
Hallo Carl, hallo Leute, Am Donnerstag, 17. Februar 2005 13:15 schrieb Carl A. Schreiber:
Am Donnerstag, 17. Februar 2005 12:14 schrieb Ruediger Meier:
Aber eben nicht auf den readonly gemounteten /usr /boot /bin ...
Ist es richtig, alles bis auf /var /tmp /home
kann im Normalbetrieb readonly gemounted werden? (Beim update, install, etc natürlich nicht!)
So die Theorie. /etc/mtab wird die erste Datei sein, die Dich ärgert (-> durch einen Symlink nach /var/irgendwo ersetzen ;-) Und im schlimmsten Fall gibt es noch /proc/mounts.) Wenn /etc read-only ist, wird übrigens das Konfigurieren "lustig" ;-) /root sollte sinnvollerweise beschreibbar sein, /srv (falls verwendet) auch. Dank hotplug sollte auch /media/ beschreibbar sein, zwecks Anlegen neuer Verzeichnisse als Mountpoints. Genauere Infos findest Du im FHS (/usr/share/doc/FHS/ oder per Google). Dort wird erklärt, welche Daten wo hingehören, ob sie "shareable" sind und ob sie read-only sein können. Gruß Christian Boltz -- # GO AWAY ! # YOU DO NOT WANT TO SEE THIS SCRIPT !!! [aus /opt/kde3/share/apps/krpmview/setup_temp_source]
Danke, Christian, ich hab zwar nach readonly gefragt, aber mein eingentliches Ziel sind drei verschiedene HD und die Aufteilung der Ordner: zwei Compact flash - eine (langsam) für boot, (512MB) - eine (schnellere) für /var /tmp und swap und (1GB) 'richtige ' eine 2.5" für /home (dh. Daten) So hoffe ich werden die hds schön lange halten, da die CF lange halten sollten und sich nicht 'schlafen legen müssen' und die 'Richtige' legt sich schlafen, da nix zugreift, außer wenn sie wirklich gebraucht wird (- oder ?). Anders gedacht, als erstes muss ich die schnellere CF austauschen. Jetzt bräucht ich nur ein (Linux-)Programm, dass eine Compact Flash Card 1:1 kopiert, dann könnt' ich einfach den PC runterfahren, die CF herausnehmen auf eine neue kopieren, einstecken und den PC wieder hochfahren - jemand eine Idee? Calli Am Donnerstag, 17. Februar 2005 23:29 schrieb Christian Boltz:
Hallo Carl, hallo Leute,
Am Donnerstag, 17. Februar 2005 13:15 schrieb Carl A. Schreiber:
Am Donnerstag, 17. Februar 2005 12:14 schrieb Ruediger Meier:
Aber eben nicht auf den readonly gemounteten /usr /boot /bin ...
Ist es richtig, alles bis auf /var /tmp /home
kann im Normalbetrieb readonly gemounted werden? (Beim update, install, etc natürlich nicht!)
So die Theorie.
/etc/mtab wird die erste Datei sein, die Dich ärgert (-> durch einen Symlink nach /var/irgendwo ersetzen ;-) Und im schlimmsten Fall gibt es noch /proc/mounts.)
Wenn /etc read-only ist, wird übrigens das Konfigurieren "lustig" ;-)
/root sollte sinnvollerweise beschreibbar sein, /srv (falls verwendet) auch.
Dank hotplug sollte auch /media/ beschreibbar sein, zwecks Anlegen neuer Verzeichnisse als Mountpoints.
Genauere Infos findest Du im FHS (/usr/share/doc/FHS/ oder per Google). Dort wird erklärt, welche Daten wo hingehören, ob sie "shareable" sind und ob sie read-only sein können.
Gruß
Christian Boltz -- # GO AWAY ! # YOU DO NOT WANT TO SEE THIS SCRIPT !!! [aus /opt/kde3/share/apps/krpmview/setup_temp_source]
Carl A. Schreiber schrieb:
Danke, Christian,
ich hab zwar nach readonly gefragt, aber mein eingentliches Ziel sind drei verschiedene HD und die Aufteilung der Ordner: zwei Compact flash - eine (langsam) für boot, (512MB) - eine (schnellere) für /var /tmp und swap und (1GB) 'richtige ' eine 2.5" für /home (dh. Daten)
So hoffe ich werden die hds schön lange halten, da die CF lange halten sollten und sich nicht 'schlafen legen müssen' und die 'Richtige' legt sich schlafen, da nix zugreift, außer wenn sie wirklich gebraucht wird (- oder ?). Anders gedacht, als erstes muss ich die schnellere CF austauschen. M.W. vertragen EEPROMs lediglich etwa 100.000 Schreibzyklen - das dürfte bei /tmp recht schnell zusammenkommen ... Zumindest sollte noatime gesetzt werden, um nicht bei jedem Lesen (!) einen Schreibvorgang auf den inode zu provozieren ...
Jetzt bräucht ich nur ein (Linux-)Programm, dass eine Compact Flash Card 1:1 kopiert, dann könnt' ich einfach den PC runterfahren, die CF herausnehmen auf eine neue kopieren, einstecken und den PC wieder hochfahren - jemand eine Idee? dd ?
Ruediger Meier schrieb:
Aber eben nicht auf den readonly gemounteten /usr /boot /bin ... Verstehst du es nicht? Asserdem ist es einfach unwahrscheinlicher, dass Du komplett alle Daten verlierst wenn Du mehrere Partitionen hast! Alles was read only ist, kann bei Bedarf leicht vom Installationsmedium bzw. backup eingespielt werden ...
Aber in dem tar.bz2 steckt IMO nur ein file - also dumm wenn das kaputt ist ... RTFM: bzip2 compresses files in blocks, usually 900kbytes long. Each block is handled independently. If a media or trans mission error causes a multi-block .bz2 file to become damaged, it may be possible to recover data from the undamaged blocks in the file.
The compressed representation of each block is delimited by a 48-bit pattern, which makes it possible to find the block boundaries with reasonable certainty. Each block also carries its own 32-bit CRC, so damaged blocks can be distinguished from undamaged ones. M.W. kann tar dann wieder beim nächsten file-header aufsetzen ...
Granted - Encryption ist tatsächlich ein Argument für eine eigene Partition. Bei der nächsten Installation werde ich mir wohl auch so einen
Aha, wie du siehst ist Deine Riesen Partition recht unflexibel sonst koenntest Du das einfach im laufenden Betrieb machen! Bin ja lernfähig :-)
Was Du über die längeren Wege des Lese/Schreibkopfs geschrieben hast ist IMO totaler Quatsch. Erstens sortiert der Kernel sowieso die Zugriffe damit unnoetige Hin- und Herbewegungen vermieden werden und wenn Deine (beispielsweise) Datenbank (mit potenziell vielen Zugriffen) auf einer kleinen, kompakten Partition liegt dann sind die Wege kuerzer als wenn sie ueber eine Riesen Partition verstreut ist. Vielleicht meinst Du ACQ o.ä. - aber so einfach ist das nicht. Erstens klappt das nur bei neueren Platten/kernels und zweitens ist die Frage, wie lange der kernel warten soll, um die Zugriffe zu sortieren. Wenn er erst lange requests sammelt, um diese in einer optimalen Reihenfolge auszuführen, ginge die Performance auch in den Keller - bei zu kurzen Wartezeiten klappt wieder die Sammlung/Optimierung nicht ...
Hallo Rainer, hallo Leute, Am Donnerstag, 17. Februar 2005 11:31 schrieb Rainer Kaluscha:
Christian Boltz schrieb:
Es gibt auch Fälle, in denen ein Dateisystem ohne Hardwaredefekt Fehler abbekommen kann. Ich nenne nur mal den "harten Shutdown" aka Stromausfall...
Dann habe ich bei n Filesystemen möglicherweise auch n Fehler ...
Oder ein Teil kommt unbeschadet davon. Schlimmer als bei einer großen Partition kann es jedenfalls nicht werden, höchstens besser ;-)
5.1. Warum ist .tar.gz oder .tar.bz2 nicht fürs Backup geeignet? http://suse-linux-faq.koehntopp.de/q/q-backup-nicht_targz.htm
Für bzip2 gibt es m.W. ein recovery-tool (bzip2recover), um aus beschädigten Archiven evtl. noch Daten zu retten.
Das Tool existiert, aber ich habe es noch nie getestet. Und bei einem .tar.bz2 muss man dann erst das bz2 recovern und sich danach mit dem beschädigten .tar rumärgern. (Ja, es gibt für tar AFAIK auch ein recovery-Tool, aber auch das habe ich noch nie gebraucht.) Backupprogramme, die dateiweise komprimieren, sind mir da deutlich sympatischer ;-)
Bei gzip geht das wohl nicht - dafür komprimiert es deutlich schneller ...
Tja, alles hat Vor- und Nachteile. Die bz2-Komprimierung ist nach meiner Erfahrung die bessere - was z. B. beim Mailversand einer Datei die Komprimierungszeit locker wieder reinholt ;-)
im single user mode lässt sich das auch von einem read only gemounteten rootfs problemlos erzeugen.
Und wo legst Du das Backup ab, wenn die einzige Partition read-only gemountet ist? *SCNR*
Am besten auf /dev/null - das geht am schnellsten :-)
Also die BOFH-Methode ;-)
Wer mehr Zeit hat und das Backup ggfs. auch wieder einspielen möchte, mag eine 2. Platte, ein Band oder einen DVD-Brenner verwenden ... *SCNR, too*
;-)
/home gönne ich grundsätzlich eine eigene Partition. Hat Vorteile, wenn man abwechselnd 2 Systempartitionen nutzt (jeweils eine wird upgedated, auf der anderen liegt das "alte" System für Notfälle).
Das rescue-System boote ich ggfs. von CD bzw. DVD ...
Ich rede nicht vom rescue-System, sondern von einem funktionierenden, vollständig installierten System. Da ich auch SuSE-Betaversionen installiere, ist die Verfügbarkeit eines solchen manchmal recht praktisch ;-)
Außerdem habe ich /home verschlüsselt. Sicher ist sicher ;-)
Granted - Encryption ist tatsächlich ein Argument für eine eigene Partition.
Auch ohne Verschlüsselung ist /home bei mir immer eine eigene Partition, die ich dann aus den verschiedenen Systempartitionen heraus mounten kann.
Bei der nächsten Installation werde ich mir wohl auch so einen "Datentresor" zulegen -
Viel Spaß beim Verkleinern Deiner Riesenpartitionen ;-) Gruß Christian Boltz -- Spätestens dabei handelt es sich um Filtereffekte, die ImageMagick bestimmt nicht beherrschen kann. Sollten sie _das_ nachprogrammiert haben, würde ich barfuß hinlaufen und ihnen ein halbes Schwein opfern ob ihrer Genialität. [Ratti in suse-linux]
Christian Boltz schrieb:
Für bzip2 gibt es m.W. ein recovery-tool (bzip2recover), um aus beschädigten Archiven evtl. noch Daten zu retten.
Das Tool existiert, aber ich habe es noch nie getestet. Und bei einem .tar.bz2 muss man dann erst das bz2 recovern und sich danach mit dem beschädigten .tar rumärgern. (Ja, es gibt für tar AFAIK auch ein recovery-Tool, aber auch das habe ich noch nie gebraucht.)
bzip2recover ist natürlich nur ein Notnagel (ich musste es noch nicht verwenden, toi, toi, toi), zeigt aber das man sich bei bzip2 Gedanken über die Problematik gemacht hat. Unschön ist allerdings, dass ein einziger defekter physikalischer Block gleich einen Ausfall eines kompletten bzip2-Blockes (900kB) bedeutet :-( Wenn man allerdings Glück hat (so war es bei meinen letzten bad blocks auf einer 80GB Partition) ist nur die japanische Lokalisierung o.ä. betroffen :-)
Backupprogramme, die dateiweise komprimieren, sind mir da deutlich sympatischer ;-) Bei afio z.B. wäre das Problem eines defekten archivs wohl ähnlich zu sehen wie bei tar: suchen, bis man den nächsten intakten file header findet ...
Ich rede nicht vom rescue-System, sondern von einem funktionierenden, vollständig installierten System. Da ich auch SuSE-Betaversionen installiere, ist die Verfügbarkeit eines solchen manchmal recht praktisch ;-) Klar - an meine Maschine kommen mir aber nur ausgetestete Releases ... Zum Ausprobieren habe ich noch externe Platten bzw. ein Jaz-Drive.
Bei der nächsten Installation werde ich mir wohl auch so einen "Datentresor" zulegen -
Viel Spaß beim Verkleinern Deiner Riesenpartitionen ;-)
Wieso verkleinern ? Irgendwann wird die 160 GB Platte durch eine 400 GB Platte ersetzt und vom verbleibenden Platz etwas für eine neue Partition abgezweigt :-) Dann noch ein "( cd /old; tar cf - . | (cd /new; tar xvf - )" über Nacht und der Fall ist erledigt :-)
Hallo, Am Fri, 18 Feb 2005, Rainer Kaluscha schrieb:
Wieso verkleinern ? Irgendwann wird die 160 GB Platte durch eine 400 GB Platte ersetzt und vom verbleibenden Platz etwas für eine neue Partition abgezweigt :-)
Dann noch ein "( cd /old; tar cf - . | (cd /new; tar xvf - )" über Nacht und der Fall ist erledigt :-)
*autsch* Du willst cd /old && tar -cp --atime-preserve -f - . | ( cd /new; tar -xvp --atime-preserve -f -; ) verwenden. Ggfs. auch -l und gewisse Dateien/Verzeichnisse ausschliessen. -dnh -- Now the world has gone to bed, | Now I lay me down to sleep, Darkness won't engulf my head, | Try to count electric sheep, I can see by infrared, | Sweet dream wishes you can keep, How I hate the night. | How I hate the night. -- Marvin
David Haller schrieb:
Dann noch ein "( cd /old; tar cf - . | (cd /new; tar xvf - )" über Nacht und der Fall ist erledigt :-)
*autsch*
Du willst
cd /old && tar -cp --atime-preserve -f - . | ( cd /new; tar -xvp --atime-preserve -f -; )
verwenden. Ggfs. auch -l und gewisse Dateien/Verzeichnisse ausschliessen. Kannst Du Gedanken lesen :-) ?
Spass beiseite: die atime interessiert mich weniger und bei root scheint -p default zu sein, -l ist redundant, da ich nur ein filesystem habe (ggfs. täte es auch ein umount). Verschwiegen habe ich allerdings das -X, um u.a. /proc auszuschliessen ... Jedenfalls hat so der Umzug meines rootfs problemlos geklappt. Aber danke für die Klarstellung - das kurze Kommando könnte sonst andere in die Irre führen. Mir ging es beim letzten posting mehr um den prinzipiellen Ansatz als um eine erschöpfende Darstellung der Syntax.
Hallo, Am Wed, 16 Feb 2005, Rainer Kaluscha schrieb:
David Haller schrieb:
Am Tue, 15 Feb 2005, Rainer Kaluscha schrieb:
Irgendeine Partition ist immer zu klein, Früher habe ich öfter Daten verschieben und mit symlinks tricksen müssen, weil mal wieder eine Partition voll war. Schlimme Sachen habe ich auch bei vorkonfigurierten Servern von Dell (mit RedHat) gesehen: da war das rootfs nur 100 MB gross und wegen /tmp war das ruckzuck voll, so dass die Kiste hängenblieb.
Solche Probleme sind m.E. unnötig.
Deswegen liegen /tmp/ und /var/ bei mir ja auch nicht auf der /-Partition.
abwechselnder Zugriff auf verschiedene Partitionen erzwingt lange Kopfbewegungen (langsam) etc.
Sehe ich nicht so. Dazu ein Beispiel: Es werde zunächst auf Datei1, dann auf Datei2 zugegriffen.
Szenario 1: Beide befinden sich auf der gleichen Partition. Der Lesekopf der Platte muss maximal den belegten Bereich dieser Partition überwinden ...
Und die Daten liegen auch immer schoen sauber am Anfang?
Szenario 2: Beide befinden sich auf unterschiedlichen Partitionen. Der Lesekopf der Platte muss maximal die erste sowie alle dazwischenliegenden Partitionen (belegte und *leere* Bereiche) sowie den belegten Bereich der Zielpartition überwinden ...
IMHO ist das sowieso irrelevant: die Zeit fuer's Positionieren haengt AFAIK mehr am letzten Teil, dem finden der richtigen "Spur", weniger an der Zeit fuer die "Strecke". Vergleiche dazu mal den geringen Einfluss den diese Acoustic Einstellung hat.
Die beiden Szenarien nähern sich mit zunehmendem Füllungsgrad der Platte allerdings aneinander an.
Bei mir sind die Platten fast immer zu >70% voll ;(
Vorteile sehe ich hingegen keine ...
Datensicherheit, Einfachheit von Updates / Backups usw... Das verstehe ich nicht: wenn die Platte im Eimer ist, spielt es keine Rolle, auf wieviele Partitionen die Daten verteilt sind, oder ?
Defekte Sektoren die nur eine Partition und damit ein Dateisystem betreffen. Das hat mir schon mehr als einmal Daten gerettet -- auch schon unter Windows.
Und Backups kann ich auch nach directories getrennt vornehmen ...
Auch bei Updates sehe ich keinen Vorteil - es wird ja das gesamte System geupdated und nicht nur die /usr-Partition (bzw. Verzeichnis).
Aber nicht /home/. Ausserdem kannst du ein getrenntes /home/ unter mehreren Linuxen verwenden (und ~/.* mit Konflikten versionieren, verlinken und beim einloggen dann die symlinks anpassen). Und du kannst /usr/ ro mounten etc. pp. Ausserdem ist ein fsck einfacher und schneller. Ich habe auch mal mit einer grossen Partition angefangen, und habe gemerkt, dass das fuer mich nicht das wahre ist. Aber das kann ja jeder halten wie er oder sie will. Ich wuerde eben aufgrund meiner Erfahrungen eine Aufteilung empfehlen. -dnh -- Auch ich rate von Sandpapier dringend ab! Ein Fehler, der, besonders von Anfängern, immer wieder gemacht wird! Ein Spritzer Pril auf 1/2 Tasse Java Kaffee und damit spülen - das ist IMO wesentlich schonender. [Olaf Andersen erklärt das Putzen einer Festplatte in suse-linux]
David Haller schrieb:
Szenario 1: Beide befinden sich auf der gleichen Partition. Der Lesekopf der Platte muss maximal den belegten Bereich dieser Partition überwinden ...
Und die Daten liegen auch immer schoen sauber am Anfang? Die meisten Daten sind bei mir recht statisch, so dass die Filesysteme nicht so schnell fragmentieren.
IMHO ist das sowieso irrelevant: die Zeit fuer's Positionieren haengt AFAIK mehr am letzten Teil, dem finden der richtigen "Spur", weniger an der Zeit fuer die "Strecke". Vergleiche dazu mal den geringen Einfluss den diese Acoustic Einstellung hat.
AFAIK beschleunigen moderne Platten den Kopf auf den ersten Hälfte der Strecke, um ihn auf der zweiten Hälfte der Strecke wieder zu bremsen. Insofern solte der Zeitbedarf nicht linear, sondern lediglich mit der Wurzel der Anzahl der zu überspringenden Spuren wachsen.
Bei mir sind die Platten fast immer zu >70% voll ;(
Da denke ich schon wieder an die Anschaffung der nächsten Platte :-)
Defekte Sektoren die nur eine Partition und damit ein Dateisystem betreffen. Das hat mir schon mehr als einmal Daten gerettet -- auch schon unter Windows.
Bad blocks hatte ich auch schon auf der grossen Partition - mit Ausnahme weniger Files, die ich aus einem Backup restaurieren musste, liess sich aber alles noch lesen.
Aber nicht /home/. Ausserdem kannst du ein getrenntes /home/ unter mehreren Linuxen verwenden (und ~/.* mit Konflikten versionieren, verlinken und beim einloggen dann die symlinks anpassen). Und du kannst /usr/ ro mounten etc. Stimmt - aber mir reicht ein Linux.
Ausserdem ist ein fsck einfacher und schneller. Eines ja - aber nicht n auf n Partionen :-) Ansonsten ist auch das fsck dank journaling file systems bei grossen Partitionen nicht mehr dramatisch ...
Ich habe auch mal mit einer grossen Partition angefangen, und habe gemerkt, dass das fuer mich nicht das wahre ist. Aber das kann ja jeder halten wie er oder sie will. Ich wuerde eben aufgrund meiner Erfahrungen eine Aufteilung empfehlen. Interessant - bei mir war es genau umgekehrt :-). Bei meiner letzten Maschine kamen nach und nach immer mehr Platten dazu - jede noch schön partitioniert. Zum Schluss waren es 4 Platten mit 15 Partitionen, so dass es unübersichtlich wurde. Bei der neuen Maschine sind es 3 Platten und gerade noch 4 Partitionen (1x NTFS, 1x FAT32, 1 ReiserFS auf der ersten Platte sowie ein RAID 0 aus 2 Platten mit reiserfs). Beim RAID 0 (striping) liegt mir mehr nur an Performance, da die Daten ziemlich statisch und ggfs. leicht wieder einzuspielen sind.
Aber wie gesagt: Partitionierung ist irgendwo auch Geschmacksfrage bzw. von den jeweiligen Bedürfnissen abhängig - daher läßt sich darüber auch trefflich streiten ...
Am Dienstag, 15. Februar 2005 12:46 schrieb Rainer Kaluscha:
David Haller schrieb:
Das finde ich heutzutage nicht mehr sinnvoll. Ich bevorzuge seit einiger Zeit folgendes Schema (fuer Platten >= 8 GB oder so).
/-Partition ~500 MB, enthaelt /bin, /boot(!), /dev, /etc, /lib, /root und /sbin (sowie die mountpoints) aber nicht /tmp[1].
swap-Partition
/tmp ist ein symlink nach /var/roottmp
...
Wie schon gesagt - über Sinn und Unsinn verschiedener Partitionen lässt sich trefflich streiten :->
Schon klar... ;-)
M.E. sind diese vielen Partitionen ein alter Zopf mit vielen Nachteilen: Irgendeine Partition ist immer zu klein, abwechselnder Zugriff auf verschiedene Partitionen erzwingt lange Kopfbewegungen (langsam) etc.
Ich würde das nicht unterschreiben wollen. Erstens lässt sich das durch halbwegs geschickte Anordnung der Partitionen minimieren und bei einer großen muss der arme Kopf auch ständig hin und her düsen, wenn die Platte einen gewissen Füllstand aufweist.
Vorteile sehe ich hingegen keine ...
Wenn es das Dateisystem auf einer Partition zerlegt, sind die anderen meist noch O.K. Zum zweiten kann man beim Backup per Image die Zeitabstände variabel halten. Wären nur zwei Argumente, kannst gerne noch 1-2 mehr haben ;-)
In der Regel lege ich nur eine grosse Partition pro Platte an (bzw. eine pro OS bei Multiboot-Systemen + 1x FAT32 für gemeinsame Daten).
Wenn du einen Laptop hättest, gäbe es bereits ein Problem ;-) Drei Platten (Einmal Win für die Firma, einmal Linux zur arbeiten und ein weiteres zu kaputt spielen) kriegst du da nicht rein ;-) Gruß, Michael -- ____ / / / / /__/ Michael Höhne / / / / / / mih-hoehne@t-online.de / _____________________________________/
participants (10)
-
Al Bogner -
Carl A. Schreiber -
Christian Boltz -
David Haller -
Jan Ritzerfeld -
Michael Hoehne -
Rainer Kaluscha -
René Falk -
Ruediger Meier -
Torsten Foertsch