Wie schlimm ist es wirklich, Linux auf einer großen Partition zu installieren?

Lösung 1:

Die primären (historischen) Gründe für die Partitionierung sind:

• um das Betriebssystem von Ihren Benutzer- und Anwendungsdaten zu trennen . Bis zur Veröffentlichung von RHEL 7 gab es keinen unterstützten Upgrade-Pfad und ein Hauptversions-Upgrade würde eine Neuinstallation erfordern und dann zum Beispiel /home haben und andere (Anwendungs-)Daten auf separaten Partitionen (oder LVM-Volumes) ermöglicht es Ihnen, die Benutzerdaten und Anwendungsdaten einfach aufzubewahren und die Betriebssystempartition(en) zu löschen.

• Benutzer können sich nicht richtig anmelden und Ihr System beginnt auf interessante Weise zu versagen, wenn Ihnen der Speicherplatz vollständig ausgeht. Mehrere Partitionen ermöglichen es Ihnen, Festplattenplatz für das Betriebssystem zuzuweisen und diesen getrennt von den Bereichen zu halten, in denen Benutzer und/oder bestimmte Anwendungen schreiben dürfen (z. B. /home /tmp/ /var/tmp/ /var/spool/ /oradata/ usw.) , Minderung des Betriebsrisikos von schlecht benommenen Benutzern und/oder Anwendungen.

• Quote. Mit Festplattenkontingenten kann der Administrator verhindern, dass ein einzelner Benutzer den gesamten verfügbaren Speicherplatz belegt, wodurch der Dienst für alle anderen Benutzer des Systems unterbrochen wird. Jedem Dateisystem wird ein individuelles Festplattenkontingent zugewiesen, sodass eine einzelne Partition und damit ein einzelnes Dateisystem nur ein Festplattenkontingent bedeutet. Mehrere (LVM) Partitionen bedeuten mehrere Dateisysteme, die eine granulare Kontingentverwaltung ermöglichen. Abhängig von Ihrem Nutzungsszenario möchten Sie beispielsweise jedem Benutzer 10 GB in seinem Home-Verzeichnis und 2 TB im /data-Verzeichnis auf dem externen Speicher-Array zulassen und einen großen gemeinsam genutzten Scratch-Bereich einrichten, in dem jeder Datensätze speichern kann, die zu groß für sein Home-Verzeichnis sind und wo die Politik "voll ist voll" wird, aber wenn das passiert, geht auch nichts kaputt.

• Bereitstellung von dedizierten IO-Pfads . Möglicherweise haben Sie eine Kombination aus SSDs und sich drehenden Festplatten und täten gut daran, sie anders anzugehen. Nicht so sehr ein Problem in einem Universalserver, aber ziemlich üblich in Datenbank-Setups ist es, auch bestimmte Spindeln (Festplatten) verschiedenen Zwecken zuzuweisen, um IO-Konflikte zu verhindern, z. separate Festplatten für die Transaktionsprotokolle, separate Festplatten für die eigentlichen Datenbankdaten und separate Festplatten für den temporären Speicherplatz. .

• Starten Möglicherweise benötigen Sie einen separaten /boot Partition. Historisch gesehen, um BIOS-Probleme beim Booten über die 1024-Zylinder-Grenze hinaus zu beheben, ist heutzutage häufiger eine Anforderung, verschlüsselte Volumes zu unterstützen, bestimmte RAID-Controller zu unterstützen, HBAs, die das Booten von SAN oder Dateisystemen nicht unterstützen, die nicht sofort vom Installationsprogramm unterstützt werden usw.

• Abstimmung Möglicherweise benötigen Sie unterschiedliche Tuning-Optionen oder sogar völlig unterschiedliche Dateisysteme.

Wenn Sie feste Partitionen verwenden, müssen Sie es bei der Installation mehr oder weniger richtig machen, und dann ist eine einzelne große Partition nicht das Schlimmste, aber sie bringt einige der oben genannten Einschränkungen mit sich.

Normalerweise empfehle ich, Ihr Hauptvolume als einziges großes physisches Linux-LVM-Volume zu partitionieren und dann logische Volumes erstellen die Ihren aktuellen Anforderungen entsprechen, und für den Rest Ihres Speicherplatzes nicht zugewiesen lassen, bis er benötigt wird .

Sie können diese Volumes und ihre Dateisysteme dann nach Bedarf erweitern (was eine triviale Operation ist, die auf einem Live-System durchgeführt werden kann) oder auch zusätzliche erstellen.

Das Verkleinern von LVM-Volumes ist trivial, aber oft wird das Verkleinern der Dateisysteme darauf nicht sehr gut unterstützt und sollte wahrscheinlich vermieden werden.

Lösung 2:

Das Konzept der Verwendung mehrerer Partitionen besteht darin, dass eine volle an der falschen Stelle nicht dazu führt, dass das gesamte System unerwartet funktioniert.

Stellen Sie sich einen Prozess auf der Maschine vor, der eine Protokolldatei ziemlich schnell bis zu dem Punkt füllt, an dem kein freier Speicherplatz mehr verfügbar ist. Auf einem Single-Partition-Rechner könnte dies dann beispielsweise das System daran hindern, neue Daten nach /tmp zu schreiben. Wenn es einen anderen Prozess gibt, der nach /tmp schreiben möchte, würde er wahrscheinlich mit einem Fehler enden und unerwartetes Verhalten verursachen.

Dies kann verhindert werden, wenn Sie unterschiedliche Partitionen für Orte verwenden, an denen Benutzer oder Prozesse normalerweise schreiben (/home, /var, /tmp).

Ich würde empfehlen, dass Sie Ihren alten Server überprüfen, welche Ordner dazu neigen, groß zu werden. Das geht auf der Kommandozeile mit

du -h -d 1 / 2> /dev/null

Sie sehen, wo die meisten Daten angesammelt werden, und gestalten Ihr nächstes System entsprechend. Das "-d 1" begrenzt die Ausgabe auf nur eine Ebene der Ordnertiefe, wodurch sie besser lesbar ist.

Lösung 3:

Das Hauptproblem bei einer einzelnen großen Partition besteht darin, dass durch das Füllen des Dateisystems möglicherweise keine Anmeldung mehr möglich ist.

Der Benutzer root hat seinen Heimatordner (/root ) außerhalb von /home aus diesem Grund. Wenn das Dateisystem voll ist, kann sich unter Umständen sogar root nicht einloggen und das System nicht reparieren.

Aus diesem Grund erstellen Sie normalerweise separate Befestigungspunkte für /var , /tmp und /home sich zumindest als root anmelden zu können, um das System zu reparieren, wenn eine der anderen Partitionen voll ist.

Lösung 4:

IMHO, eine Partition als / zu haben, ist ziemlich vernünftig.

Aber Sie können lvm (Logical Volume Manager) verwenden. Verwenden Sie alle Festplatten als lvm-Gruppe, aber erstellen Sie kleine logische Festplatten für /,/home,/usr und was auch immer Ihr Systemadministrator bevorzugt. Setzen Sie dann eine Überwachung ein, die Sie kennen, wenn Ihr System voll wird, und erweitern Sie die Festplatten, die Sie benötigen. lvresize und resize2fs sind Online-Tools und Sie können eine Erweiterung vornehmen, ohne den Server neu zu starten. Sie können die Festplatten jedoch nicht reduzieren, also müssen Sie relativ klein anfangen und erhöhen, wo Sie Bedarf sehen.

Lösung 5:

Es gibt minimale Probleme bei der Einrichtung von Linux mit großen einzelnen Partitionen, aber es hat große Vorteile.

Das Ändern eines Partitionslayouts ist eine etwas schwierige und riskante Sache, die Sie oft nicht ohne lange Ausfallzeiten tun können.

Der einzige Vorteil besteht darin, dass Sie einen gewissen Schutz vor Problemen mit einer vollen Festplatte haben. Aber Sie werden diese Probleme viel finden häufig. Stellen Sie sich die Situation vor, wenn eine Ihrer Partitionen voll ist und Sie den Platz auf den anderen Partitionen nicht nutzen können, selbst wenn sie fast leer sind !

Einige professionelle Systemadministratoren haben darüber eine ganz andere Meinung. Sie sagen, dass mehrere Partitionen Ihr System zuverlässiger machen können und Sie vor der Partitionierung wissen müssen, wie groß Ihre Partitionen sein werden. Meiner Meinung nach kann man das einfach nicht sagen, es ist ein schrecklicher Nachteil für die Flexibilität des Systems, und ihre wahre Motivation ist, dass sie einfach gerne mit den Partitionskarten spielen .

Es gibt ein einfaches System namens lvm, das das spontane Verschieben/Skalieren von "Partitionen" (in seiner Terminologie Volumes) ermöglicht. Aber auf einem einzelnen lokalen Abteilungsserver wird es meiner Meinung nach normalerweise nicht benötigt.