Ein oder mehrere Partitionen für srv?

  • Thread starter Thread starter cider23
  • Start date Start date
C

cider23

Guest
Hallo,

ich bin gerade dabei meinen alten Rootserver auf neue Hardware umzuziehen. Dazu plane ich die Dateisysteme.

Bisher geplant (je 10GB; swap 1GB; boot 512MB):

  • sda1 /boot
  • sda2 swap
  • sda3 /
  • sda4 /var
  • sda5 /var/log
  • sda6 /usr
  • sda7 /home
var/log lege ich nochmal extra, da meine Trac+Apache Kombination ab und an mal auf die Idee kommt, das error Log mit wsgi Messages vollzumüllen; Ursachenanalyse läuft aber das ein anderes Thema.

home lege ich auch auf dem Server extra, da hierunter meine Windows VM mit DayZ-Server und TFS Express liegt.

Partitioniert wegen der 3TB Platten mittels GPT Label.

Sämtliche Serversoftware (vorerst Minecraft, Teamspeak, Steam, Trac, SVN, PGSQL) und Websitesachen liegen unter /srv.

Für sdb soll XFS zum Einsatz kommen. Meine Hauptfragen daher:

  1. Ist XFS denn das Dateisystem der Wahl wenn es um größere Partitionen geht? Es erfolgen zum Teil mehrere Anfragen auf das Dateisystem parallel. Es existieren zwar einige Benchmarks, welche allerdings nur löschen, schreiben etc in einem Einzelprozess-Skript abdecken. Mich würden eher Erfahrungswerte interessieren.
  2. Wie schaut es mit der Performance bei besagten parallelen Schreib- und Lesezugriffen aus: lieber die Platte auf die Dienste aufteilen (quasi 100gb für SVN, 50gb für Trac etc) oder ist die Performance gleich/schlechter wie wenn die gesamten 3TB für /srv verwendet werden?
  3. Vorschläge bzw Kritik zur bisher geplanten Partitionierungsart?


Vielen Dank im voraus für hilfreiche Antworten.
 
IMHO: Bei den heutigen Festplattengrössen macht eine Aufsplittung der Partitionen wie früher kaum noch Sinn, da man entweder die Partitionen viel zu gross oder viel zu klein wählt.
Ich persönlich würde nur noch / und swap fürs System und /data für Nutzdaten anlegen. Die nötige Grösse für / lässt sich relativ einfach berechnen und eine Sicherheit von etwa etwa 2-4GB reicht meist völlig. Für /data nimmt man dann den Rest und konfiguriert seine Dienste so, dass auch potentiell grosse Logs dort landen, fertig.

Viel wichtiger ist heute die Frage des Filesystems.
Bei FreeBSD würde ich bei / definitiv auf UFS2 setzen und für /data ZFS in Erwägung ziehen.
Bei Linux würde ich noch generell auf XFS setzen (ich traue der Ext-Familie nicht) und wenn irgendwann mal Btrfs mindestens so stabil ist wie ZFS unter FreeBSD heute, dann Btrfs für /data nehmen.

Alles IMHO und basierend auf eigener Erfahrung.

Da hier jeder andere Erfahrungen hat, sei mir verziehen, dass ich über diese nicht gross diskutieren werde.

Konkrete technische Fragen beantworte ich gerne wenn ich kann, ansonsten ist mir das Bash/Flame-Potential bei dem Thema zu hoch.
 
Vielen lieben Dank für Deine Antworten.

Ich würde sehr gerne bei den Standards bleiben wollen, weswegen dennoch die var und var/log Partitionen bleiben werden. Aber es bekräftigt mich darin, xfs für meine Große Platte zu nutzen.

Der ungenutzte Rest meiner sda wird als Backupspeicher herhalten.

Ext habe ich selbst auch nicht so vertraut; insbesondere bei dem Desaster was ext4 angerichtet hat; immerhin ist es immernoch nicht feature complete. Daher wird auch ext3 bei den Partitionen zum Einsatz kommen.

ReiserFS hatte ich zwar ebenfalls für gut befunden; insbesondere Reiser4, möge jedoch daher rühren, dass ich Hans persönlich kannte und Sympathien für ihn hatte.

Also bleibt es bei XFS :)

Die Frage ist nun, ob es, ungeachtet der Auslastung des Speichers, die Parallelisierung des FS im Source Auswirkungen auf die Plattenperformance hat, und ob man 1 oder mehrere Partitionen xfs formatiert hat.
 
cider23 said:
ReiserFS hatte ich zwar ebenfalls für gut befunden; insbesondere Reiser4, möge jedoch daher rühren, dass ich Hans persönlich kannte und Sympathien für ihn hatte.
Click to expand...
Bevor oder nachdem er seine Frau umgebracht hat?


Deine Frage ist mir nicht ganz klar. Geht es darum, ob mehrere Dateisysteme statt einem die Performance beeinträchtigen? Das würde ich stark bezweifeln, zumindest wäre mir das neu. Vielleicht kann Joe (oder wer auch immer) aber Genaueres zu sagen, denn belegen kann ich das nicht.
 
s24! said:
Geht es darum, ob mehrere Dateisysteme statt einem die Performance beeinträchtigen? Das würde ich stark bezweifeln, zumindest wäre mir das neu. Vielleicht kann Joe (oder wer auch immer) aber Genaueres zu sagen, denn belegen kann ich das nicht.
Click to expand...
Mehrere Partitionen können durchaus einen negativen Einfluss auf die Performance von mechanischen Festplatten haben. Nämlich dann, wenn sich zwei häufig beanspruchte Partitionen auf der gleichen Scheibe der Festplatte liegen. Wenn dann auf beide Partitionen gleichzeitig zugegriffen werden soll, mussen die nachfolgenden Zugriffe immer warten, bis sich der Kopf erst zum Start der jeweiligen Partition bewegt hat um dort dann die Partitionstabelle auszulesen und sich dann zur Lese/Schreibposition weiterbewegt um seinen Lese/Schreibvorgang erledigen zu können. Für jede dieser Bewegungen braucht der Kopf durchschnittlich die x Millisekunden welche die Hersteller als Zugriffszeit angeben. Soweit die Grundlagen.
Wenn wir jetzt eine heute übliche Scheibe von ~300GB nehmen und die erste Partition darauf 270GB und die zweite 30GB gross machen, aber in der ersten Partition nur 5GB und in der zweiten 20GB Daten ablegen, dann muss sich der Kopf bei einem Partitionswechsel immer über mindestens 90% der Scheibe bewegen und benötigt dafür auch (erheblich) länger als die Durchschnittsangabe des Herstellers. Logisch, oder?
Nehmen wir jetzt aber nur eine Partition von 300GB auf dieser Scheibe und legen dort unsere 25GB Daten gemeinsam ab, dann muss sich der Kopf plötzlich nur noch über maximal 10% der Scheibe bewegen und ist dabei auch noch (erheblich) schneller als die Durchschnittsangabe des Herstellers. Auch logisch, oder?

Soweit die Theorie. In der Praxis sprechen wir hier über einen Unterschied von 1-4 Millisekunden zwischen den Partitionswechseln. Wer diese Millisekunden woanders dringend braucht, der sollte sich genau überlegen, wieviele Partitionen er wirklich braucht und wie er sie auf die einzelnen Scheiben der Festplatte verteilt.

Bei SSDs besteht dieses "Problem" übrigens nicht.


Früher (vor den >250GB Platten) war es ein geringeres Problem, da die Festplatten nur eine Scheibe hatten und man auf Grund der geringeren Kapazität manche Verzeichnisse per Partitionierung vor dem Volllaufen schützen wollte. Heute spielt es aber keine Rolle mehr wenn ein Log mal das Gigabyte sprengt, weil noch hunderte Gigabyte Platz frei sind.

Die Aufspaltung in mehrere Patitionen stammt aber noch aus viel früherer Zeit, nämlich aus der Zeit als Festplattengrössen noch in Megabyte angegeben wurden. Manchmal verliert halt auch Best-Practise seine Gültigkeit...



So, das sorgt vermutlich wohl wieder für eine Endlos-Diskussion, daher schon vorab:
Bleibt sachlich! Ich hab keinen Bock auf Zickereien und Kindergartenniveau...
 
Vielen lieben Dank für die Erklärung, insbesondere der Punkt mit den Scheiben ergibt Sinn, ohne dass es mir in den Sinn gekommen wäre, darüber zu überhaupt nachzudenken.

Also werde ich sicherlich eine große / erzeugen und gut ist. Die Daten liegen dann auf der 2. Platte unter /srv.

Edit: Andererseits wäre dann wieder das Risiko von hardlink escalations gegeben. Mhh... grml.
 
You must log in or register to reply here.
Back
Top