Linux Server - Wie partitioniere ich am besten?

[Christoph Zurnieden]

Hi,

Wegen zu lang gekürzt, hoffe ist noch verständlich.
Kann auch irgendjemand mal der Fehlermeldung "Das war jetzt etwas viel."  eine Maxwert zustellen? Muß ich mir dafür erst den Code besorgen? *GNAA*

Außerdem: die Tatsache, das
ein Hardwareschaden wahrscheinlicher als ein
Dateisystemschaden ist bedeutet /nicht/, daß man auf
jeden Fall keinen Dateisystemschaden bekommt, weil ja
vorher die Hardware kaputtgehen würde.

Das ist jetzt auch schlecht zu trennen, denn der FS Schaden kann durch Hardwareschaden entstehen (Es gab mal Zeiten da ging das sogar umgekehrt ;-). Die Sektoren lösen sich meist nur sehr langsam auf, die Platte raucht extrem selten wirklich mit "offener Flamme" ab. Irgendwann kann das FS nicht mehr damit umgehen und gibt auf. Spielst Du das dann neu auf, werden die beschädigten Sektoren umgangen und die Zählung beginnt von neuem. Es ist mit einem als stabil bekanntem FS deutlich eher anzunehmen, das ein HW-Schaden vorliegt als ein verwirrtes FS.
Oder irgendjemand hat das Dingen kaputgespielt, das habe ich auch schon mal geschafft, gebe ich unumwunden zu ;-)
(Kleine Nickligkeiten mit rohem (raw) Schreibzugriff)

Diese Trennung ermöglicht es Dir auch, das System
durch eine neuere Version zu ersetzen (ist bei Debian
natürlich nicht nötig;-)),

Alle mir bekannte Distributionen sind aufwärtskompatibel.
Was einen natürlich nicht davon abhalten sollte, vorher ein Backup zu machen ;-)

es durch eine andere Distribution zu ersetzen,

Gut, das ist ein Argument. Aber da reicht die Trennung von /home und dem Rest.
Aber eigentlich reicht da auch ein simples Backup.

oder es aus irgendwelchen Gründen neu zu installieren.

Hey, wir reden von Linux, nicht von Windows!
Nein, kein Smiley dahinter.

/* Hier könnte ein infiniter Loop enstehen, deshalb: */
goto weiter;

ist der wichtigste Grund für diese Trennung schlicht
und einfach Bequemlichkeit.

weiter:
Gut, _das_ ist ein Argument, dem ich nichts entgegenzusetzen habe, schließlich bin ich auch einer der bequemen Sorte.

Aber ein schlichtes Backup ist auch nicht viel Arbeit, oder? ;-)

Je nach Szenario
gibt es aber Obergrenzen für die Häufigkeit von
Backups.

Das ist natürlich eine ganz normale Kosten/Nutzen Rechnung und muß jeder mit sich selbst ausmachen.

[Backup von Mail usw]
Dafür habe ich z.B. Redundanz: ich lasse die Mails auf dem Server (POP3 ohne abschließendes Löschen) und schicke erst am Ende vom - allerdings täglichem - Backup ein DELE an den POP3. Bei der Flut von Spam heutzutage ist dafür aber auch eine 20 MB große Mailbox nötig, die zudem schon das gröbste selber rausfiltert :-/

Aber wie gesagt: Backup ist natülich individuell und muß auch  maßgerecht zugeschnitten sein.

Aber mal ganz statistisch an die Sache gegangen:
Wenn Du die Platte in verschiedene Partitionen aufteilst, muß da auch ein FS drauf. Entweder sind das verschiedene oder überall das gleiche. Viele verschiedene gibt es nicht. Da Du auf Datensicherheit Wert legst käme nur ein Jornailing-FS in Frage. Da hätten wir dann ext3 und ReiserFS zur Auswahl (Die kommerziellen sind leider noch(?) nicht so weit).
ext3 hat den Vorteil des Fallback, es kann zur Not auch mit ext2 Tools darauf zugegriffen werden. Die ideale Lösung ist also ext3, die Auswahl ist also nicht sehr groß.
Demnach hast Du also nur ein FS drauf. Die Wahrscheinlichkeit, das eines der FS auf den Partitionen durch Software zerstört wird ist also erstmal überall gleich. Sie erhöht sich durch Schreibzugriffe. Schreibzugriffe sind aber am ehestem auf Deinem /home Verzeichniss zu erwarten sonst wär's ja auch recht witzlos bzw extrem eingeschränkt, und natürlich /tmp bzw /var allgemein.
Also ist die Wahrscheinichkeit recht groß, das es ausgerechnet den Teil treffen wird, den Du durch Verteilung zu schützen suchtest. Fast 0,5, um genau zu sein.
Viel Arbeit also für wenig Effekt.
Backup-Sequenz beschleunigen ist da sinnvoller.

[ mount ro ]

Es ist richtig, daß es keinen Schutz bietet, wenn der
Rechner gerooted wurde. Das macht es noch nicht gleich
sinnlos. Außerdem war das "read-only" nur ein Beispiel,
es gibt weitere sinnvolle Optionen, zum Beispiel nosuid
und noexec (letzteres ist wohl nur bei Kernel 2.6
brauchbar),

Beides kann theoretisch umgangen werden, da es sich um Software handelt. Sichereste Alternative für read-only ist ein nichtbeschreibbares Medium, für nosuid die Abschaffung von root und für noexec die Abschaffung der User.

Keine Scherze, meine ich alles ernst.

Die Abschaffung von Root ist zur Zeit nicht wirklich möglich. Es geht aber abstrakt http://askemos.org und das funktioniert sogar!
Für noexec gilt es wirklch die User abzuschaffen, das geht bei Programm- _und_ Datenhaltung auf dem Server. Der User bekommt nur ein "Dumb X Terminal" (das dann aber natürlich mit LCD und in knallbunt! ;-)
Experimente (Development u.ä.) dann nur in einer Sandkiste.

Das ist aber alles recht kompliziert und dauert bis es wirklich rund laufen würde. Zu lange für die meisten Geldgeber.

oder Einstellungen, mit denen man die
Performance steigern kann.

Die sind nicht mehr relevant, da gibt es bessere Möglichkeiten. Wenn man natürlich am Ende hängt und nur noch 2 Wochen bis zur Lieferung des dicken Eisens überbrücken muß, kann man, nein, muß man wohl eher, alles probieren.

Bei einem System mit vielen
Dateien, auf die dauernd zugegriffen wird (z.B.
Newsspool-Verzeichnis auf einem Newsserver) könnte man
beispielsweise noatime verwenden.

Ein guter Cachingalgorithmus brächte mindestens das zehnfache.

Von der Möglichkeit,
für unterschiedliche Bereiche unterschiedliche
Dateisysteme oder angepasste Einstellungen bei der
Formatierung zu verwenden mal ganz zu schweigen.

Auch das ist heutzutage eher Spielerei. Ich habe zwei Wetten laufen, wann genau im nächstem Jahr die erste TiByte-Platte auf den Markt kommt und Du versuchst Dich noch in Inodekalkulation? Wenn Du soviele kleine Dateien hast, das es signifikant wird: nimm 'ne DB auf roher (raw) Platte.

Die im File Hierarchy Standard vorgeschlagene Struktur
erfüllt einen Zweck.

Ja, dem herrschendem Durcheinander ein Ende zu bereiten.

Einige der von mir erwähnten
Punkte werden dort auch explizit aufgeführt.

Ja, und?
Der einzige triftige Grund für ein standartisiertes Dateisystem ist eben ein standartisiertes Dateisystem. Mehr Gründe braucht es nicht.
Man hätte dei Positionen der einzelnen Einträge genausogut auswürfeln können, nur möchte man isch diese Blöße natürlich nicht geben. ALso hat man eine guten Schnitet durch ads genommen, was sie eh schon alee so machen und sich für jeden Eintrag einen Grund gesucht. Nicht umgekehrt, da interpretierst Du etwas rein, was nicht drin ist, gar nicht drin sein kann.

Beispiel:

,---
|Disk errors that corrupt data on the root filesystem

[...]

|corruption as the result of a system crash.
`---

Die moderen Journailing-FS sind gegen Fehler nach einem Systemcrash sicher.

,---
|/var is specified here in order to make it possible to

[...]

|must be in /var.
`---

Das ist ein Beispiel für den gesuchten Grund. Statt einfach zu statuieren, das das Durcheinander ein Ende hat und alles, was außerhalb /home geschrieben wird nach /var gehört zieht man sich eine Grund an den kaum noch vorhandenen Haaren herbei.

Dafür, daß /usr nur und genau dann beschreibbar ist,
wenn ich über die Paketverwaltung etwas dorthin
installieren will, sonst nicht.

Das setzt voraus, das die Paketverwaltung sicher ist.
Das setzt voraus, das die Paketverwaltung funktioniert.
Das setzt voraus, das die Pakete sicher sind.
Das setzt voraus, das der Kernel sicher ist.
Das setzt voraus, das alle Bibliotheken der Paketverwaltung sicher sind.

Und noch ein paar Kleinigkeiten mehr.
Das sind alles zuviel Abhängigkeiten, als das man sich daruf verlassen kann. Kann man sich nicht drauf verlassen ist es nicht sehr sinnvoll.

Ich habe mir die Frage andersherum gestellt: macht es
einen Sinn, sie größer zu machen, wenn ich den Platz
dort nicht brauche?

andreas@sirius:~$ df -h | grep boot
/dev/hda6              30M  3,1M   25M  12% /boot

Das ist mehr als genug Platz für mehrere Kernel.

Schön.

"Warum ist das Dingen so klein?" ist ein Frage mit Hintersinn.
Einstmals, als die Platten langsam größer wurden, stand man auf einmal vor dem Problem, das LILO nicht mit den ganz großen Platten klarkam, wenn der Kernel zu weit weg war. Nun hatte man aber meistens ganz vorne die Swap-Partition, der Geschwindigkeit wegen. So entstand dann die /boot Partition gleich zusammen mit der kleine Größe.
Der Grund ist schon lange hinfällig geworden, nur die /boot-Partition in Größe und Standort wird noch beibehalten.
Warum?
Aus Tradition? ;-)

Mein Gott, er hat 80 GiB! Er muß sich nun wahrlich
keine Sorgen wg Platz machen!

Das dachte ich auch mal. Ich habe mittlerweile eine
120-GB-Platte. Die mit 40 GB ist zu klein geworden.
Davor dachte ich, 6.4 GB wären genug für alle Zeiten.
Und davor waren es 520 MB.

Ja, _genau so_ erging's mir auch ;-)
(Nur fing das bei mir mit 20MiB an und das war sogar noch die größere der verfügbaren Platten und _schweineteuer_! ;-)

Erst waren es Spiele, dann MP3-Sammlungen, jetzt Filme.

Dann hast Du ja wenigstens einen Grund! Bei mir weiß ich das gar nicht so richtig. Ich habe nur ein Modem, viel mit runterladen ist da also nicht. (Gottseidank, was den Plattenverbrauch angeht. Wüßte nicht, wieviel ich schon angesammelt hätte mit DSL ;-)

OpenOffice auf dem Server ist übrigens so schlecht
nicht, da man das Dingen mittlerweile als Filter
gebrauchen kann also z.B. Rohdaten als PDF ausgeben.

Ja, außerdem gibt es doch andere Möglichkeiten. Es gibt
eine ganze Reihe von kleineren Programmen, mit denen
man aus diversen Dateiformaten PDF erstellen kann.

Ja, aber ist die einzige Möglichkeit, da auch mit Word-Dateien zu tun. Zumindest mit minimalem Aufwand.

Und für CUPS kann man sich recht einfach ein Backend
für einen PDF-Drucker erstellen. Das ganze geht dann
auch, ohne irgendwelche Abhängigkeiten von XFree o.ä.
zu haben.

X wird in oben beschriebenem Fall nicht benötigt. Sonst hätte ich es auch nicht erwähnt ;-)

[SelfHTML]

/usr/local/share/doc, um genau zu sein. Mal ganz im
Ernst: mir ist auch nichts anderes eingefallen, außer
vielleicht /opt.

Ja, da habe ich es auch liegen. Ist allerdings hier auch ein Multiusersystem. Wäre ich nur alleine drauf, hätte ich es in /home/$meinereiner gelassen.

Der einzige Vorteil dafür ist, das man eine ganze
Partition schneller gelöscht hat, mehr auch nicht.

Oder das man sie nicht löschen muß, wenn man das System
neu installieren oder ersetzen will.

Das verstehe ich jetzt ni ... ah, so, Mißverständnis, ich meinte den Inhalt des FS der jeweiligen Partition bequem durch dd und überschreiben löschen zu können, nicht die Partition selber. Das wäre ja auch ein wenig sinnfrei ;-)

so short

Christoph Zurnieden