Die Serverprodukte von Red Hat und Novell setzen verschiedene Dateisysteme ein. Dieser Artikel zeigt, inwieweit die Distributoren damit die richtige Wahl treffen und welche Alternativen es gibt.
Die Installation eines neuen Fileservers ist mit vielen Nebenaufgaben verbunden. Eine Kernkomponente – die Wahl des passenden Dateisystems – kommt dabei oft zu kurz (siehe Kasten “Richtig partitionieren”). Eine falsche Entscheidung kostet hier aber täglich Zeit, trägt doch das Dateisystem wesentlich zur Performance eines Systems bei.
Das Linux-Magazin hat für diesen Artikel die Dateisysteme Ext 3, Reiser-FS und XFS der Enterprise-Distributionen Suse Linux Enterprise Server 9 von Novell und Red Hat Enterprise Linux 4 von Red Hat genauer unter die Lupe genommen und deren Performance mit den frei verfügbaren Distributionen Fedora Core 4 und Open Suse 10.0 Beta 2 verglichen.
Drei Benchmarks
Die Redaktion verzichtete diesmal auf die aufwändigen synthetischen Benchmarks Iozone [1] und Bonnie++ [2], ausführliche Tests inklusive diverser Mount-Optionen mit diesen Benchmarks nennt [3]. Stattdessen prüften drei einfache, praxisnahe Bash-Skripte die Dateisysteme. In einem ersten Test musste das Betriebssystem die Quellen des Kernels 2.6.12.5 (rund 230 MByte) von einer Partition auf eine andere kopieren.
Zu diesem Zweck formatierte das Testskript die Partitionen mit identischen Dateisystemen und maß die Zeit des Kopiervorgangs und des anschließenden »sync«-Befehls. Nach zwei Durchläufen formatierte das Testprogramm die Partitionen neu. Jedes Dateisystem durchlief acht Tests. Die Ergebnisse in Abbildung 1 zeigen den Durchschnitt der Testwerte nach dem Streichen des besten und des schlechtesten Resultats.
Ein zweiter Test maß die Performance mit Dateigrößen zwischen 3 und 10 MByte. Dazu kopierte ein Skript eine 2,1 GByte große Sammlung von MP3-Musikstücken. Der dritte Test prüfte die Performance mit großen Dateien. Hier kopierte das Shellskript ein 1 GByte großes Video auf den Testpartitionen. Unter RHEL 4 testete die Redaktion jeweils nur Ext 3, da dieses Betriebssystem für Reiser-FS und XFS keine Kernelmodule mitbringt.
Kernelquellen kopieren
Die Quellen des Kernels 2.6.12 bestehen aus 17360 Dateien und benötigen entpackt rund 230 MByte auf der Festplatte. Die durchschnittliche Dateigröße beträgt somit rund 13 KByte. Gut die Hälfte der Dateien ist über 4 KByte groß.
Wie bereits die früheren Benchmarks zeigten, arbeitet Reiser 4 bei diesen Dateigrößen mit Abstand am schnellsten (dazu später), gefolgt von Reiser-FS. Hier sorgten die Benchmarks also nicht für Überraschungen. Die zeigten sich erst im Vergleich von Reiser-FS des Suse Linux Enterprise Servers 9 mit Fedora Core 4: Hier bringt das Journaling-Filesystem beinahe 10 Prozent mehr Leistung als unter dem SLES 9.
XFS eignet sich für den Einsatz als Fileserver mit besonders kleinen Dateien schlecht. In dieser Hinsicht hat sich seit den letzten Benchmarks des Linux-Magazins nichts geändert.
MP3-Sammlung
Im zweiten Test mussten die Systeme 461 MP3-Dateien mit einer durchschnittlichen Größe von 4,6 MByte kopieren. XFS unter Fedora Core 4 erfüllte diese Aufgabe am schnellsten, gefolgt von XFS unter Open Suse (siehe Abbildung 2). Die negative Überraschung dieses Tests bringt Reiser-FS unter dem SLES 9: Es kommt nicht annähernd an die Performance der übrigen Dateisysteme oder von Reiser-FS unter Fedora Core 4 oder Open Suse 10.0 heran.
Von ähnlichen Problemen berichten auch einige Mailinglisten, zum Beispiel [5]. Systemadministratoren, die SLES 9 mit größeren Dateien benutzen, sollten deshalb die Tuning-Vorschläge unter [6] beherzigen.
|
Tabelle 1: |
|
|---|---|
|
Distribution |
Kernelversion |
|
SLES 9 |
2.6.5-7 |
|
RHEL 4 |
2.6.9-5 |
|
Fedora Core 4 |
2.6.11 |
|
Open Suse 10.0 Beta 2 |
2.6.13-rc6 |
Abbildung 1: Kernelquellen kopieren: Bei kleinen Dateien liefert Reiser-FS nach wie vor die beste Performance, gefolgt von Ext 3. Überraschenderweise arbeitet das Journaling-Filesystem unter Fedora Core 4 am schnellsten. Außer Konkurrenz: Reiser 4 mit einer Übertragungsrate von 49 MByte/s.
Abbildung 2: MP3-Sammlung kopieren: Bei Dateigrößen von 5 bis 10 MByte arbeitet XFS am schnellsten. Der Einbruch von Reiser-FS unter SLES 9 hängt damit zusammen, dass das Betriebssystem die Mount-Option »barrier=flush« benutzt. Ist diese Option nicht aktiv, bringt Reiser-FS einen Durchsatz von 20,7 MByte/s.
Als Bremsklotz entpuppte sich die Mount-Option »barrier=flush«, die bei SLES 9 per Default aktiv ist. Die Option »barrier=none« verhalf anschließend dem System zu einem weit besseren Durchsatz von 20,7 MByte/s. In der Abbildung sind trotzdem die schlechteren Zeiten zu sehen, da sie die Werte der Grundeinstellung widerspiegeln.
Das Problem betrifft allerdings nur Reiser-FS, obwohl SLES 9 auch Ext 3 mit der Option »barrier=flush« mountet. Abgesehen vom schlechten Abschneiden von Reiser-FS unter SLES 9 zeigt sich das Feld ausgeglichen, mit leichten Vorteilen für XFS und Reiser-FS unter Fedora Core 4 und Open Suse 10.0.
|
So haben wir |
|---|
|
Für die Dateisystem-Benchmarks benutzte das Linux-Magazin einen handelsüblichen PC. Der 64-Bit-Rechner verfügt über einen mit 2,2 GHz getakteten Prozessor vom Typ AMD Athlon 3200+, über 1 GByte DDR-Hauptspeicher, eine 120-GByte-SATA-Festplatte und eine 120 GByte große ATA-Festplatte, beide von Samsung. Als Mainboard dient dem PC ein ASUS K8V-X-EAYZ mit dem Chipsatz VIA VT8237. Der Suse Linux Enterprise Server 9 hatte zuerst enorme Probleme mit der SATA-Platte. Schon bei der Installation blieb Yast beim Mounten der Reiser-FS-Partitionen hängen. Erst SLES 9 mit Service Pack 2 ließ sich problemlos installieren. Hier schaltete der Enterprise Server allerdings den DMA-Modus der Festplatte nicht ein, sodass sie zunächst mit 3 MByte/s arbeitete. Der Befehl »hdparm -d1 -Xudma7« versetzte die Platte dann in den gewünschten DMA-Modus. Auch die Installation von Red Hat Enterprise Linux bereitete Probleme. Hier verweigerte die Netzwerkkarte den Dienst, trotz des geladenen Kernelmoduls. Die Installation der neueren Distributionen Fedora Core 4 und Open Suse 10.0 Beta 2 verlief reibungslos. Alle vier Systeme luden für die SATA-Festplatte automatisch das Kernelmodul »sata_via.ko«. SLES 9 band die SATA-Festplatte und »/dev/hda« ein, die übrigen Systeme erkannten das Gerät als »/dev/sda«. Laut »hdparm« schaffen diese einen Durchsatz von rund 55 MByte/s. Für beide Festplatten lieferte »hdparm« Werte um 55 MByte pro Sekunde. Da die Benchmarks unter der 64-Bit-Variante des Suse Linux Enterprise Servers keine nennenswerten Abweichungen zu dessen 32-Bit-Version erkennen ließen, fanden sämtliche Tests mit der 32-Bit-Variante des jeweiligen Betriebssystems statt. |
MPEG-Video kopieren
Auch beim Kopieren des MPEG-Videos hat XFS die Nase vorn, knapp vor Reiser-FS unter Fedora Core 4 (Abbildung 3). Ext 3 ist auf allen getesteten Systemen etwa gleich schnell. Im Vergleich zu den Benchmarks vom September können Reiser-FS und Ext 3 gegenüber XFS viel an Boden gutmachen.
Auch in diesem Test schneidet Reiser-FS unter dem Suse Linux Enterprise Server aufgrund der Option »barrier=flush« schlecht ab. Ohne die Option kommt es auf 22,5 MByte/s. Beim Vergleich nach Dateigröße (Abbildung 4) fällt auf, dass Reiser-FS und Ext 3 bei Dateigrößen um 5 MByte die schlechteste Performance aufweisen. Bei XFS jedoch steigt die Geschwindigkeit mit wachsender Dateigröße.
Abbildung 3: XFS unter Fedora Core 4 kopierte die 1 GByte große MPEG-Datei am schnellsten, knapp gefolgt von Reiser-FS. Platz 3 holte sich in diesem Test Ext 3 unter RHEL 4. Das schlechte Abschneiden von Reiser-FS unter SLES 9 hängt wieder mit der Mount-Option »barrier=flush« zusammen.
Reiser 4
Obwohl der Test als Vergleich von Ext 3, Reiser-FS und XFS gedacht war, startete der Autor in letzter Minute noch einige Benchmarks mit Reiser 4 auf der Beta 2 von Open Suse. Sie bestätigen die Resultate der Tests vom September 2004: Beim Kopieren kleiner Dateien ist Reiser 4 deutlich schneller als die Konkurrenz. Mit 49 MByte/s absolvierte das Dateisystem den Kernelquellen-Benchmark doppelt so schnell wie Ext 3 und dreimal schneller als XFS. Auch die MP3-Sammlung und die MPEG-Datei kopiert Reiser 4 mit 21,5 MByte/s und 23,4 MByte/s flott. Diese Last-Minute Ergebnisse fehlen allerdings in den Diagrammen.
Abbildung 4: Ext 3 und Reiser-FS weisen bei Dateien um 5 MByte einen deutlichen Einbruch auf. XFS steigert seine Performance mit steigender Dateigröße.
Fazit
Bei der Wahl der Dateisysteme sollte sich der Admin nach Möglichkeit nicht von der Empfehlung der Installationsroutine leiten lassen, sondern von Benchmarks wie diesem. So eignet sich für die Arbeit mit kleinen Dateien Reiser-FS deutlich besser als Ext 3 oder XFS. Bei größeren Dateien weisen hingegen XFS und Ext 3 eine leicht bessere Performance auf. Red Hat Enterprise Linux 4 bringt somit für kleine Dateien kein passendes Dateisystem mit und nimmt hier Performance-Einbußen in Kauf.
Auf der anderen Seite zeigt Ext 3 unter RHEL 4 eine gute Leistung und übertrifft auch die Zeiten von XFS unter SLES 9. Mit den Benchmark-Ergebnissen von XFS unter Fedora Core 4 sowie unter Open Suse 10.0 kann Ext 3 hingegen nicht mehr mithalten. Auch Reiser-FS kopiert unter den neueren Kerneln schneller als Ext 3. Gewinner der Benchmarks für Dateigrößen über 1 MByte ist wieder XFS. Umso unverständlicher ist es, dass Red Hat ausgerechnet dieses Dateisystem nicht offiziell unterstützt.
|
Richtig |
|---|
|
Der innerste und damit erste Sektor jeder Festplatte beherbergt die Partitionstabelle. Sie speichert die physische Adresse (Kopf, Zylinder, Sektor) des Anfangs und des Endes jeder Partition. Damit bekommt jede Partition ihre Position und Größe auf der Festplatte fest zugewiesen. Außerdem enthält die Partitionstabelle für jede Partition eine Kennung (ID), an der jedes Betriebssystem feststellen kann, ob es mit dieser Partition etwas anfangen kann. Mit Fdisk ist Root in der Lage, diese ID zu verändern, ohne dabei die Partitionsgröße oder -lage anzutasten. Eine der Partitionen bekommt ein Bootflag verpasst. Das Rechner-Bios wird diese Partition auf der ersten Festplatte beim Booten blind anspringen. Das passiert allerdings nicht, wenn der Master Boot Record (MBR) ein Urlader-Programm, meist einen Bootmanager, enthält, der Gegenteiliges vorsieht. Früher war bei vier Partitionen SchlussDie Partition Table verweist nur auf maximal vier Primärpartitionen. Dieses historisch bedingte Limit ist Betriebssystem-unabhängig und lockert sich, sobald eine dieser Primärpartitionen zur erweiterten Partition erklärt ist. Sie verweist dann auf eine Kette zusätzlicher Partitionen, den so genannten logischen. Die meisten Betriebssysteme verlangen zwar, dass sie von einer primären Partition gebootet werden, aber Linux zum Glück nicht. Für das Partitionieren eines Fileservers gibt es – wie für viele andere Administrationsaufgaben auch – keine allgemein gültige Kochanleitung. Aus Gründen der Übersichtlichkeit lassen sich die Aufteilungsarbeiten der Festplatte(n) am besten mit dem von Hersteller der Distribution empfohlenen Tool erledigen. Hier kann der Bediener auch darauf vertrauen, dass die angezeigten Wege, Soft-Raids und/oder ein LVM einzurichten, auch tatsächlich mit der installierten Kernelversion und den vorhandenen Tools im Hintergrund harmonieren. Ein gangbarer Weg ist es, das erste, leere Medium des Fileservers mit der Swap-Partition zu bestücken. Den vielfach zu lesenden Ratschlag, sie genauso oder doppelt so groß auszulegen wie den vorhandenen Hauptspeicher, kann man getrost ignorieren. Wer viele zeitgleich eingeloggte User auf seinem Server erwartet oder neben dem reinen Fileserving auch Applikationen laufen lassen will, sollte bei der Swap-Größe keinesfalls geizen. Als zweite folgt die Boot-Partition, die sehr klein ausfallen darf, falls sie als »/boot« von der Root-Partition abgeteilt ist. Sie als erste zu platzieren umschifft auch (zugegebenermaßen selten gewordene) Probleme oberhalb der 1024-Zylindergrenze, die manch älteres Bios bereitet. Bei der Wahl des richtigen Dateisystems hilft der umstehende Artikel. Das weitere Vorgehen richtet sich danach, ob die Partitionen klassisch-nativ auf den Datenträger sollen oder ob ein LVM sie verwalten soll. Letzteres einrichten ergibt die flexiblere Lösung – das richtige Dateisystem vorausgesetzt, wie der Artikel ab Seite 48 nahe legt. Für die Menge gibt’s kein PatentrezeptÜber Anzahl und Größe der anzulegenden Partitionen beziehungsweise logischen Volumes lässt sich trefflich streiten. In erster Linie hängt die Entscheidung vom angepeilten Einsatzszenario und in zweiter Linie vom geplanten Backup-Konzept ab. Als Hitliste von wichtig zu weniger wichtig lassen sich nennen: »/« (wenn nicht schon als Bootpartition angelegt), »/var«, »/usr« und »/tmp«. »/home« gehört bei einem Fileserver in jedem Fall auf eine eigene Partition oder ein logisches Volume, am besten auf das zuletzt angelegte. Denn hier ergibt sich erfahrungsgemäß später der größte Nachbesserungsbedarf. Den Bootmanager, Lilo oder Grub, lässt man der Einfachheit halber in den MBR installieren, was durch das Fehlen von Windows & Co. kein Problem ist. So spielt Linux zudem seinen Vorteil aus, dass es ihm funktional gleichgültig ist, ob Partitionen primär oder logisch sind. (jk) |
|
Infos |
|---|
|
[1] Bonnie++: [http://www.coker.com.au/bonnie++/] [2] Iozone: [http://www.iozone.org] [3] Marcel Hilzinger, “Qual der Wahl”: Linux-Magazin 09/04, S. 28 [4] Slow.c-Benchmark: [http://www.jburgess.uklinux.net/slow.c] [5] Langsames Reiser-FS unter SLES 9: [http://linux.derkeiler.com/Newsgroups/alt.os.linux.suse/2005-01/2842.html] [6] SLES-9-Tuning: [http://portal.suse.com/sdb/de/2004/08/pohletz_tuning_parameter.html] |
