Dateisysteme von verschiedenen installierten Distris (Multi-Boot) aus nutzen?
Hallo liebe MitListige, ist es ratsam, die Dateisysteme bzw. Partitionen für /tmp und /root (letzteres extra, damit ich die Root-Partition / nicht beschreibbar mounten muss) von verschiedenen installierten Linux Distributionen aus zu nutzen, oder gibt es da Fallstricke? Bisher habe ich verschiedene Distris zum Ausprobieren auf die Schnelle auf einer einzigen Partition installiert, was sich bei langen Uptimes nicht immer bewährt hat. Wenn das Dateisystem gravierende Fehler hatte, konnte ich schon mehrmals das System nicht mehr starten, weil auch nach der FS-Reparatur von einem Rettungssystem aus viele Binaries kaputt waren. Dann half nur noch Neuinstallation (ich mache keine Sicherung von Systemdateien, außer den Konfigurationsdateien, die ich verändert habe). Also möchte ich bei jeder Installation zukünftig lieber wieder partitionieren und separate Dateisysteme für swap, /, /root, /tmp, /usr, /var/, u.s.w. anlegen. Ich möchte aber wenigstens die Dateisysteme für /tmp und /root gemeinsam in allen Distris verwenden, um auf einer kleinen SSD Platz zu sparen. Soviel nur zu meiner Motivation. Vielen Dank schon im Voraus für Eure Meinungen und Ideen. Gruß, Thomas P.S.: Nur so am Rande: Das Dateisystem für den Bootmanager (nicht automatisch gemountet), das ich für die Startauswahl der Distris verwende, ist sowieso ein eigenes. Für verschiedene Kernel einer Distri habe ich ggf. noch einen grub im Boot-Sektor der jeweiligen Root-Partition. Die Heimatverzeichnisse liegen bei mir auf /home immer auf einer eigenen Partition und die existiert 'natürlich' nur einmal pro Rechner. Allerdings habe ich hier die Besonderheit festgestellt, dass einige Dateien in Verzeichnissen für verschiedene Desktop-Umgebungen (z.B. ~/.kde* oder ~/.gnome2*) anscheinend in Unordnung geraten können, wenn man den gleichen Desktop in verschiedenen Distris nutzt. Deshalb müsste man hier eigentlich /home/<benutzer> mit eigenen Einstellungsdateien und -verzeichnissen in jeder Distri extra haben und die persönlichen Arbeitsdaten in einer eigenen Partition oder NFS-Freigabe (z.B. auf /work gemountet) mit einem symbolischen Link in jedem /home auf /work. Das wäre wohl auch sinnvoll, wenn man auf verschiedenen Rechnern verschiedene Programmversionen einsetzt, z.B. scheint Thunderbird 3 überhaupt nicht mit dem Einstellungsverzeichnis eines TB 2 zurechtzukommen, eigentlich enttäuschend :-( -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On 14/11/10 19:07, Thomas Michalka wrote:
Bisher habe ich verschiedene Distris zum Ausprobieren auf die Schnelle auf einer einzigen Partition installiert, was sich bei langen Uptimes nicht immer bewährt hat. Wenn das Dateisystem gravierende Fehler hatte, konnte ich schon mehrmals das System nicht mehr starten, weil auch nach der FS-Reparatur von einem Rettungssystem aus viele Binaries kaputt waren. Dann half nur noch Neuinstallation (ich mache keine Sicherung von Systemdateien, außer den Konfigurationsdateien, die ich verändert habe). Also möchte ich bei jeder Installation zukünftig lieber wieder partitionieren und separate Dateisysteme für swap, /, /root, /tmp, /usr, /var/, u.s.w. anlegen.
Meiner Meinung nach macht heutzutage mit Journaling Filesystemen das Aufteilen eines Systems auf viele kleine Partitionen fuer einen normalen Heimanwender keinen Sinn mehr (Web-Server und aehnliches lasse ich hier absichtlich mal aussen vor) - lediglich /home liegt bei mir hier (und so handhaben wir das auch in der Firma) auf einer separaten Partition, das hat aber mehr oder weniger hpts. Backup-Gruende. Ansonsten ist nachher dann eine Partition ein bissl zu klein, eine andere dafuer viel zu gross, usw. - diese Problematik kann man sich heutzutage in vielen Faellen einfach sparen. An Deiner Stelle wuerde ich mich eher fragen, warum gravierende Fehler im Dateisystem auftraten - selbst wenn das gesamte System auf einer Partition installiert ist, sollte das ja nicht der Fall sein. Es sei denn, Du setzt experimentelle Dateisysteme ein - in dem Falle wuerde aber auch das Partitionieren inicht wirklich helfen und nur eine Scheinsicherheit vermitteln. Ist es moeglich, dass Deine Hardware vielleicht nicht 100% funktioniert? In einem anderen Thread berichtest Du ja auch von exzessivem Swapping usw. Gruesse, Thomas -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Thomas Hertweck schrieb:
On 14/11/10 19:07, Thomas Michalka wrote:
[...] Also möchte ich bei jeder Installation zukünftig lieber wieder partitionieren und separate Dateisysteme für swap, /, /root, /tmp, /usr, /var/, u.s.w. anlegen.
Meiner Meinung nach macht heutzutage mit Journaling Filesystemen das Aufteilen eines Systems auf viele kleine Partitionen fuer einen normalen Heimanwender keinen Sinn mehr (Web-Server und aehnliches lasse ich hier
Ich hatte früher mit ext2 (ohne Journaling) seltener das Problem eines defekten Dateisystems.
absichtlich mal aussen vor) - lediglich /home liegt bei mir hier (und so handhaben wir das auch in der Firma) auf einer separaten Partition, das hat aber mehr oder weniger hpts. Backup-Gruende. Ansonsten ist nachher dann eine Partition ein bissl zu klein, eine andere dafuer viel zu gross, usw. - diese Problematik kann man sich heutzutage in vielen Faellen einfach sparen.
In dieser Hinsicht stimme ich Dir zu, aber für Partitionen (eigtl. Dateisysteme), in die häufig geschrieben wird, ist das Risiko von Dateisystemfehlern wohl eher höher, auch wenn es nicht vorkommen sollte. Deshalb halte ich es noch für sinnvoll, wenigstens für /var und /temp (wenn man hier nicht tempfs verwendet) eigene Dateisysteme vorzusehen. Für /, /usr u.s.w. von mir aus nur ein Dateisystem.
An Deiner Stelle wuerde ich mich eher fragen, warum gravierende Fehler im Dateisystem auftraten
Immer nur nach _sehr_ langen Uptimes (teilw. über ein Jahr). Ich denke, dass mit zunehmender Uptime das Risiko von Fehlern steigt.
- selbst wenn das gesamte System auf einer Partition installiert ist, sollte das ja nicht der Fall sein. Es sei denn, Du setzt experimentelle Dateisysteme ein
Niemals.
- in dem Falle wuerde aber auch das Partitionieren inicht wirklich helfen und nur eine Scheinsicherheit
Es mindert aber das Risiko einer umfassenden Systemzerstörung. Ich habe jedenfalls nie beobachtet, dass nach langer Uptime mehr als zwei oder drei Dateisysteme gleichzeitig defekt waren. Einmal hatte ich ein /home-FS mit Datenverlusten, die durch Restore leicht wieder rückgängig zu machen waren, einmal hatten das Root-Dateisystem (z.B. kein /sbin/init mehr) und das /usr-FS viele Binaries verloren, was durch Neuinstallation zu beheben war. Kann man sich eigentlich eine Liste der installierten Pakete auf einem USB-Stick abspeichern und bei einer Neuinstallation von YaST wieder einlesen lassen?
vermitteln. Ist es moeglich, dass Deine Hardware vielleicht nicht 100% funktioniert? In einem anderen Thread berichtest Du ja auch von exzessivem Swapping usw.
Das liegt, wie ich in dem Thread ("Erfahrungen mit Swap-Partition auf SSD gesucht") berichte, ziemlich sicher an den vielen Browser-Fenstern. Ansonsten scheint meine Hardware einandfrei zu funktionieren, zumindest habe ich keine rätselhaften Fehlfunktionen. Gruß, Thomas -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 18.11.2010 15:28, schrieb Thomas Michalka:
Hallo,
Thomas Hertweck schrieb:
On 14/11/10 19:07, Thomas Michalka wrote:
[...] Also möchte ich bei jeder Installation zukünftig lieber wieder partitionieren und separate Dateisysteme für swap, /, /root, /tmp, /usr, /var/, u.s.w. anlegen.
Meiner Meinung nach macht heutzutage mit Journaling Filesystemen das Aufteilen eines Systems auf viele kleine Partitionen fuer einen normalen Heimanwender keinen Sinn mehr (Web-Server und aehnliches lasse ich hier
Ich hatte früher mit ext2 (ohne Journaling) seltener das Problem eines defekten Dateisystems.
absichtlich mal aussen vor) - lediglich /home liegt bei mir hier (und so handhaben wir das auch in der Firma) auf einer separaten Partition, das hat aber mehr oder weniger hpts. Backup-Gruende. Ansonsten ist nachher dann eine Partition ein bissl zu klein, eine andere dafuer viel zu gross, usw. - diese Problematik kann man sich heutzutage in vielen Faellen einfach sparen.
In dieser Hinsicht stimme ich Dir zu, aber für Partitionen (eigtl. Dateisysteme), in die häufig geschrieben wird, ist das Risiko von Dateisystemfehlern wohl eher höher, auch wenn es nicht vorkommen sollte. Deshalb halte ich es noch für sinnvoll, wenigstens für /var und /temp (wenn man hier nicht tempfs verwendet) eigene Dateisysteme vorzusehen. Für /, /usr u.s.w. von mir aus nur ein Dateisystem.
An Deiner Stelle wuerde ich mich eher fragen, warum gravierende Fehler im Dateisystem auftraten
Immer nur nach _sehr_ langen Uptimes (teilw. über ein Jahr). Ich denke, dass mit zunehmender Uptime das Risiko von Fehlern steigt.
- selbst wenn das gesamte System auf einer Partition installiert ist, sollte das ja nicht der Fall sein. Es sei denn, Du setzt experimentelle Dateisysteme ein
Niemals.
- in dem Falle wuerde aber auch das Partitionieren inicht wirklich helfen und nur eine Scheinsicherheit
Es mindert aber das Risiko einer umfassenden Systemzerstörung. Ich habe jedenfalls nie beobachtet, dass nach langer Uptime mehr als zwei oder drei Dateisysteme gleichzeitig defekt waren. Einmal hatte ich ein /home-FS mit Datenverlusten, die durch Restore leicht wieder rückgängig zu machen waren, einmal hatten das Root-Dateisystem (z.B. kein /sbin/init mehr) und das /usr-FS viele Binaries verloren, was durch Neuinstallation zu beheben war. Kann man sich eigentlich eine Liste der installierten Pakete auf einem USB-Stick abspeichern und bei einer Neuinstallation von YaST wieder einlesen lassen?
vermitteln. Ist es moeglich, dass Deine Hardware vielleicht nicht 100% funktioniert? In einem anderen Thread berichtest Du ja auch von exzessivem Swapping usw.
Das liegt, wie ich in dem Thread ("Erfahrungen mit Swap-Partition auf SSD gesucht") berichte, ziemlich sicher an den vielen Browser-Fenstern. Ansonsten scheint meine Hardware einandfrei zu funktionieren, zumindest habe ich keine rätselhaften Fehlfunktionen.
Gruß, Thomas
Hi, uptimes von einem Jahr... das mag ja toll klingen, aber es beraubt natürlich alle tunefs-Einstellungen zum fsck ihres Sinnes. Spricht denn etwas gegen einen, meinetwegen wöchentlichen Reboot? Oder, wenn Du das gar nicht magst, gegen manuelle oder zeitgesteuerte fsck's? Generell empfehle ich auch immer, /var und /tmp extra Partitionen zu geben, weil die auch gern mal überlaufen und das ist weitaus schlimmer wenn dann / mit voll ist - es geht relativ leicht, mit einem gut durchdachten php-Fehler /var/log/apache2/error_log auf mehrere GB zu bringen ;-) Vielleicht ist es sogar noch sinnvoller, /var/tmp und /var/log eigene Partitionen zu geben, denn wenn man es schafft /var zuzumüllen, fängt auch cups an zu stottern... (ja, ich weiß, es gibt quota's und sowas, aber das scheint mir overkill, und weil logs ja oft auch von root kommen, nicht so einfach, wie ein paar Partitionen mehr anzulegen, wenn man neu installiert) cu jth -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo zusammen, Am 18.11.2010 16:06, schrieb Joerg Thuemmler:
uptimes von einem Jahr... das mag ja toll klingen, aber es beraubt natürlich alle tunefs-Einstellungen zum fsck ihres Sinnes. Spricht denn etwas gegen einen, meinetwegen wöchentlichen Reboot? Oder, wenn Du das gar nicht magst, gegen manuelle oder zeitgesteuerte fsck's?
Also, ich reboote meinen Server nur, wenn es Kernel-Updates gibt. Bei der Gelegenheit schraube ich auch mit tunefs herum, um die Partitionen per fsck durchchecken zu lassen. Es dauert ja zum Glück bei Ext4 nicht so lange. ;-)
Generell empfehle ich auch immer, /var und /tmp extra Partitionen zu geben, weil die auch gern mal überlaufen und das ist weitaus schlimmer wenn dann / mit voll ist - es geht relativ leicht, mit einem gut durchdachten php-Fehler /var/log/apache2/error_log auf mehrere GB zu bringen ;-)
Hm, sowas darf natürlich nicht passieren. Um ein Überlaufen der Logdateien zu verhindern, setze ich Logrotate für die Error-Logs ein und setze zusätzlich die Optionen "maxage 7" und "daily", um ältere rotierte Logdateien zu löschen. Dann läuft auch nix mehr über. ;-) Wer die rotierten Dateien behalten möchte, kann ja per rsync einseitig synchronisieren ohne die vorhandenen Dateien zu löschen. Es geht halt alles, man muss nur wissen wie. ;-)
Vielleicht ist es sogar noch sinnvoller, /var/tmp und /var/log eigene Partitionen zu geben, denn wenn man es schafft /var zuzumüllen, fängt auch cups an zu stottern...
(ja, ich weiß, es gibt quota's und sowas, aber das scheint mir overkill, und weil logs ja oft auch von root kommen, nicht so einfach, wie ein paar Partitionen mehr anzulegen, wenn man neu installiert)
Quota hilft beim Überlaufen der Logs herzlichst wenig und würde ich auch dafür nicht einsetzen, sondern eher gegen User die eine Sammelwut haben. :-) -- Gruß Sebastian - openSUSE Member (Freespacer) Webseite/Blog: http://www.sebastian-siebert.de Wichtiger Hinweis zur openSUSE Mailing Liste: http://de.opensuse.org/OpenSUSE_Mailinglisten-Netiquette -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 18.11.2010 17:03, schrieb Sebastian Siebert:
Hallo zusammen,
Also, ich reboote meinen Server nur, wenn es Kernel-Updates gibt. Bei der Gelegenheit schraube ich auch mit tunefs herum, um die Partitionen per fsck durchchecken zu lassen. Es dauert ja zum Glück bei Ext4 nicht so lange. ;-)
die gibt es doch aber öfter als einmal im Jahr, oder...
Generell empfehle ich auch immer, /var und /tmp extra Partitionen zu geben, weil die auch gern mal überlaufen und das ist weitaus schlimmer wenn dann / mit voll ist - es geht relativ leicht, mit einem gut durchdachten php-Fehler /var/log/apache2/error_log auf mehrere GB zu bringen ;-)
Hm, sowas darf natürlich nicht passieren. Um ein Überlaufen der Logdateien zu verhindern, setze ich Logrotate für die Error-Logs ein und setze zusätzlich die Optionen "maxage 7" und "daily", um ältere rotierte Logdateien zu löschen. Dann läuft auch nix mehr über. ;-)
Wer die rotierten Dateien behalten möchte, kann ja per rsync einseitig synchronisieren ohne die vorhandenen Dateien zu löschen.
Es geht halt alles, man muss nur wissen wie. ;-)
ich habe mit einem einzigen php-Fehler schon mal in 10 Minuten 5 GB /var gefüllt... da helfen logrotates gar nix mehr... Jetzt habe ich immer ein Auge auf das Apache-Logfile, wenn ich was heikles probiere...
Vielleicht ist es sogar noch sinnvoller, /var/tmp und /var/log eigene Partitionen zu geben, denn wenn man es schafft /var zuzumüllen, fängt auch cups an zu stottern...
(ja, ich weiß, es gibt quota's und sowas, aber das scheint mir overkill, und weil logs ja oft auch von root kommen, nicht so einfach, wie ein paar Partitionen mehr anzulegen, wenn man neu installiert)
Quota hilft beim Überlaufen der Logs herzlichst wenig und würde ich auch dafür nicht einsetzen, sondern eher gegen User die eine Sammelwut haben. :-)
Na, quota würde wenigstens zeitnah reagieren...user mit Sammelwut gibt's hier zum Glück systembedingt nicht... die müssen auf ihren Windowskisten sammeln ;-) cu jth -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Jörg, Joerg Thuemmler schrieb:
Am 18.11.2010 15:28, schrieb Thomas Michalka:
Hallo,
Thomas Hertweck schrieb:
On 14/11/10 19:07, Thomas Michalka wrote:
[...] Also möchte ich bei jeder Installation zukünftig lieber wieder partitionieren und separate Dateisysteme für swap, /, /root, /tmp, /usr, /var/, u.s.w. anlegen. Meiner Meinung nach macht heutzutage mit Journaling Filesystemen das Aufteilen eines Systems auf viele kleine Partitionen fuer einen normalen Heimanwender keinen Sinn mehr (Web-Server und aehnliches lasse ich hier Ich hatte früher mit ext2 (ohne Journaling) seltener das Problem eines defekten Dateisystems.
absichtlich mal aussen vor) - lediglich /home liegt bei mir hier (und so handhaben wir das auch in der Firma) auf einer separaten Partition, das hat aber mehr oder weniger hpts. Backup-Gruende. Ansonsten ist nachher dann eine Partition ein bissl zu klein, eine andere dafuer viel zu gross, usw. - diese Problematik kann man sich heutzutage in vielen Faellen einfach sparen. In dieser Hinsicht stimme ich Dir zu, aber für Partitionen (eigtl. Dateisysteme), in die häufig geschrieben wird, ist das Risiko von Dateisystemfehlern wohl eher höher, auch wenn es nicht vorkommen sollte. Deshalb halte ich es noch für sinnvoll, wenigstens für /var und /temp (wenn man hier nicht tempfs verwendet) eigene Dateisysteme vorzusehen. Für /, /usr u.s.w. von mir aus nur ein Dateisystem.
[...]
Hi,
uptimes von einem Jahr... das mag ja toll klingen,
Nur nebenbei, ich verbrauche den Strom nicht, damit es "toll" klingt, aber das hast Du sicher nicht so gemeint ;-)
aber es beraubt natürlich alle tunefs-Einstellungen zum fsck ihres Sinnes.
Habe ich nicht so recht bedacht. Natürlich habe ich bemerkt, dass nach einem Reboot nach so langer Zeit jedesmal eine umfassende Überprüfung aller Dateisysteme nötig war, was die Zeit bis zum grafischen Login um einiges und unangenehm verlängert.
Spricht denn etwas gegen einen, meinetwegen wöchentlichen Reboot?
Dagegen spricht, dass bei derart vielen Fenstern das Starten der Benutzeroberfläche extrem lange dauert, weil die Dauer vom Flaschenhals Festplatte bestimmt wird. Ich habe mir ja, wie in einem anderen Thread geschrieben, eine SSD angeschafft -- mal sehen, ob's damit erträglicher wird.
Oder, wenn Du das gar nicht magst, gegen manuelle oder zeitgesteuerte fsck's?
Dagegen spräche gar nichts, denn Nachts sitze ich selten am Rechner. Du meinst, nach vorherigem mount -o remount,ro /dev/sd<xy>? Kann man das mit dem Root-FS auch machen?
Generell empfehle ich auch immer, /var und /tmp extra Partitionen zu geben, weil die auch gern mal überlaufen und das ist weitaus schlimmer wenn dann / mit voll ist - es geht relativ leicht, mit einem gut durchdachten php-Fehler /var/log/apache2/error_log auf mehrere GB zu bringen ;-)
Noch'n Argument, danke!
Vielleicht ist es sogar noch sinnvoller, /var/tmp und /var/log eigene Partitionen zu geben, denn wenn man es schafft /var zuzumüllen, fängt auch cups an zu stottern...
Spricht etwas gegen tmpfs für /tmp und /var/tmp?
(ja, ich weiß, es gibt quota's und sowas, aber das scheint mir overkill,
Elegant, aber wohl einiges an Konfigurationsarbeit, oder? Gruß, Tom -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On 18/11/10 14:28, Thomas Michalka wrote:
[...] Es mindert aber das Risiko einer umfassenden Systemzerstörung. Ich habe jedenfalls nie beobachtet, dass nach langer Uptime mehr als zwei oder drei Dateisysteme gleichzeitig defekt waren. Einmal hatte ich ein /home-FS mit Datenverlusten, die durch Restore leicht wieder rückgängig zu machen waren, einmal hatten das Root-Dateisystem (z.B. kein /sbin/init mehr) und das /usr-FS viele Binaries verloren, was durch Neuinstallation zu beheben war.
Das ist aus meiner Sicht nicht normal. Auch nicht nach langer Uptime. Wir haben Festplattenkapazitaeten im Petabyte-Bereich (lokale Festplattenkapazitaeten der einzelnen Cluster-Knoten nicht mitgerechnet) und ich kann nicht von solchen Problemen berichten. Die meisten Probleme, die wir haben, treten im Bereich Netzwerk/NFS auf. Wir haben auch Cluster-Knoten, die sehr lange Uptimes haben, allerdings variiert das, weil die Processing-Cluster ggf. schlafen, wenn es weniger Arbeit zu tun gibt. Kaputte Filesysteme treten hier nur sehr selten auf, und dann hat das oft als Ursache eine defekte Hardware (sprich: Festplatten sind defekt oder andere Hardware wie Speicher oder CPU).
Kann man sich eigentlich eine Liste der installierten Pakete auf einem USB-Stick abspeichern und bei einer Neuinstallation von YaST wieder einlesen lassen?
Eine Liste kann man soweit ich weiss im YaST Software Manager exportieren und auch ggf. wieder importieren. Gruesse, Thomas -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (4)
-
Joerg Thuemmler -
Sebastian Siebert -
Thomas Hertweck -
Thomas Michalka