Welches Filesystem ist das beste?
Was ist denn so die landlaeufige Meinung bezueglich Filesystemen? Sollte man Ext2, Ext3, oder gar ReiserFS installieren? Ich denke hier an eine Stand-Alone-Maschine, kein Server. Wie gross sind die Geschwindingkeitsunterschiede, und sind Ext3 und ReiserFS schon 100%-ig stabil? Oder sollte man als Normalverbraucher, der sich nicht gerne mit kniffligen Konfigurationsfragen herumschlaegt, lieber erst mal bei Ext2 bleiben Gruesse Klaus __________________________________________________ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com
Am Mon, 19 Nov 2001 schrieb Klaus Voelker:
Was ist denn so die landlaeufige Meinung bezueglich Filesystemen? Sollte man Ext2, Ext3, oder gar ReiserFS installieren? Ich denke hier an eine Stand-Alone-Maschine, kein Server. Wie gross sind die Geschwindingkeitsunterschiede, und sind Ext3 und ReiserFS schon 100%-ig stabil? Oder sollte man als Normalverbraucher, der sich nicht gerne mit kniffligen Konfigurationsfragen herumschlaegt, lieber erst mal bei Ext2 bleiben
Ob es eine landlaeufige Meinung gibt, wage ich zu bezweifeln. Jedes System hat seine Vorteile. ReiserFS ist beim Handeln von kleinen Dateien z.B. deutlich schneller als ext2/3. Dafür habe ich schlechte Erfahrungen in Bezug auf NFS-Shares etc. mit Reiser gemacht. Persönlich würde ich ext3 empfehlen, das bei mir sehr stabil läuft! Gerade vor einigen Minuten habe ich einen Artikel über ext3 gelesen: http://www-106.ibm.com/developerworks/linux/library/l-fs7/ Gruß Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Hallo, Am Montag, 19. November 2001 um 16:09 schrieb Klaus Voelker,
Was ist denn so die landlaeufige Meinung bezueglich Filesystemen? Sollte man Ext2, Ext3, oder gar ReiserFS installieren? Ich denke hier
diese Threads gehen hier ja relativ häufig rum. Vorneweg: EINE Meinung gibt es nicht, jedoch zeichnet sich eine gewisse Tendenz ab: ReiserFS ist schnell, stabil, neigt zu Problemen bei NFS. Ext2 über jeden zweifel erhaben, aber eben die lange fsck dauer Ext3 baut ja auf ext2 auf und packt nur das Journal oben drauf. Hat den Vorteil, daß man sie sogar von ext2 systemen mounten kann. XFS ... wohl deutlich langsamer bei kleinen Dateien... Ich verwende ReiserFS auf einer 200GB LVM (2x100GB). Bin zufrieden, habe aber noch kein NFS. cu stonki
On Monday 19 November 2001 17:44, Stefan Onken wrote:
ReiserFS ist schnell, stabil, neigt zu Problemen bei NFS.
Das höre ich ja überall, allerdings erst nachdem ich ReiserFS schon eingesetzt hatte, und ich habe nie irgendwas mit NFS bemerkt. Kann jemand hier sagen WAS die angebliche Probleme sind, und wo sie beschrieben werden? -Chris Kuhi
Hi Chris On Tue, Nov 20, 2001 at 09:39:10AM +0100, Chris Kuhi wrote:
On Monday 19 November 2001 17:44, Stefan Onken wrote:
ReiserFS ist schnell, stabil, neigt zu Problemen bei NFS.
Das höre ich ja überall, allerdings erst nachdem ich ReiserFS schon eingesetzt hatte, und ich habe nie irgendwas mit NFS bemerkt. Kann jemand hier sagen WAS die angebliche Probleme sind, und wo sie beschrieben werden?
es sind keine angeblichen Probleme, es sind leider objektive und sie unterscheiden sich von Versionspaarung zu Versionspaarung bei Client/Server. Was mich abschreckt es vorerst nochmal zu testen ist insbesondere die grottenschlechte write Performance bei NFS auf einem Reiser Server und die damit einhergehende hohe Systemlast. -- MfG. Falk
On Tue, 20 Nov 2001, Falk Sauer wrote:
Hi Chris
On Tue, Nov 20, 2001 at 09:39:10AM +0100, Chris Kuhi wrote:
On Monday 19 November 2001 17:44, Stefan Onken wrote:
ReiserFS ist schnell, stabil, neigt zu Problemen bei NFS.
Das höre ich ja überall, allerdings erst nachdem ich ReiserFS schon eingesetzt hatte, und ich habe nie irgendwas mit NFS bemerkt. Kann jemand hier sagen WAS die angebliche Probleme sind, und wo sie beschrieben werden?
es sind keine angeblichen Probleme, es sind leider objektive und sie unterscheiden sich von Versionspaarung zu Versionspaarung bei Client/Server. Was mich abschreckt es vorerst nochmal zu testen ist insbesondere die grottenschlechte write Performance bei NFS auf einem Reiser Server und die damit einhergehende hohe Systemlast.
Hallo... die Schreib-Performance ist bei mir eigentlich ok, aber beim Auflisten von sehr grossen Verzeichnissen mit "ls -laR" vom (NFS-)Client aus kann es zu sehr hoher Last kommen. Ein nfsd-Prozess erreicht dann bis zu 100%, die System-Load geht locker bis auf 9.2... dann hab ich doch lieber ctrl-C gedrueckt ;-) Die Clients verlieren zeitweise den kontakt zum Server. Das aeussert sich dann mit einem "haengen" des Desktops (wenn $HOME ueber NFS gemountet ist) # dmesg nfs: server svrzb1 not responding, still trying nfs: server svrzb1 OK Witzig ist, dass auf 4 anderen Servern das Problem nicht auftritt. Das mag aber auch an den Daten liegen. Der betroffene Server hat ein Software-Archiv auf der Platte und wird auch als Install-Server eingesetzt. Ich habe das Problem fast wegbekommen, indem ich Kernel 2.2.19 installiert und die Anzahl der nfsd-Prozesse auf 8 erhoeht habe. Auch laesst sich in /usr/src/linux/fs/nfsd/ noch ein bischen tunen, z.B. reply-cache groesser machen usw. Aber man bastelt halt damit nur an den Symptomen rum... cu. peter -- | LEISTRITZ Aktiengesellschaft Tel.: +49 (0) 911 4306 559 | Peter Woelfel, EDV-Abteilung Fax: +49 (0) 911 4306 478 | Markgrafenstrasse 29-39 eMail: pwoelfel@leistritz.de | D-90459 Nuernberg Web: http://www.leistritz.de
Hi Peter On Tue, Nov 20, 2001 at 04:37:34PM +0100, Peter Woelfel wrote:
die Schreib-Performance ist bei mir eigentlich ok, aber beim Auflisten von sehr grossen Verzeichnissen mit "ls -laR" vom (NFS-)Client aus kann es zu sehr hoher Last kommen. Ein nfsd-Prozess erreicht dann bis zu 100%, die System-Load geht locker bis auf 9.2... dann hab ich doch lieber ctrl-C gedrueckt ;-)
kenn ich doch irgendwoher, bist du sicher das das nur bei nfs auftritt, ich hatte den eindruck sowas bei ftp/ssh auch beobachtet zu haben (rdist benutzt den gleichen Befehl), ich musste den Test dann leider abbrechen weil er überhaupt keinen Erfolg versprach.
Die Clients verlieren zeitweise den kontakt zum Server. Das aeussert sich dann mit einem "haengen" des Desktops (wenn $HOME ueber NFS gemountet ist)
oh nett, das kenn ich nicht
Witzig ist, dass auf 4 anderen Servern das Problem nicht auftritt. Das mag aber auch an den Daten liegen. Der betroffene Server hat ein Software-Archiv auf der Platte und wird auch als Install-Server eingesetzt.
bei meinem war es ein 0,55TB filesystem halb voll von dem jeden Tag ca. 15% ausgewechselt werden sollten, dafür hat die Nacht einfach nimmer gelangt.
Ich habe das Problem fast wegbekommen, indem ich Kernel 2.2.19 installiert und die Anzahl der nfsd-Prozesse auf 8 erhoeht habe. Auch laesst sich in /usr/src/linux/fs/nfsd/ noch ein bischen tunen, z.B. reply-cache groesser machen usw.
ich brauch nen 2.4er Kern an der Stelle :-/ falls es irgendwann Zeit regnet probier ich mal ein XFS auf der Kiste. -- MfG. Falk
Hi Peter, hi Liste, Peter Woelfel wrote:
Hallo...
die Schreib-Performance ist bei mir eigentlich ok, aber beim Auflisten von sehr grossen Verzeichnissen mit "ls -laR" vom (NFS-)Client aus kann es zu sehr hoher Last kommen. Ein nfsd-Prozess erreicht dann bis zu 100%, die System-Load geht locker bis auf 9.2... dann hab ich doch lieber ctrl-C gedrueckt ;-)
Kann es sein, daß das mit dem Journaling zusammen hängt? IMHO wird jeder Plattenzugriff protokolliert, ein ls -l öffnet doch zumidest die Inod um an die Recht/User/Group dranzukommen, dann muß auch noch User/Group aufgelößt werden (Plattenzugriff?). Gibt es schon tests mit anderen JFS und NFS, habe keine gefunden, bzw kann mich nicht dran erinnern.
Die Clients verlieren zeitweise den kontakt zum Server. Das aeussert sich dann mit einem "haengen" des Desktops (wenn $HOME ueber NFS gemountet ist)
# dmesg nfs: server svrzb1 not responding, still trying nfs: server svrzb1 OK
Witzig ist, dass auf 4 anderen Servern das Problem nicht auftritt. Das mag aber auch an den Daten liegen. Der betroffene Server hat ein Software-Archiv auf der Platte und wird auch als Install-Server eingesetzt.
Ich habe das Problem fast wegbekommen, indem ich Kernel 2.2.19 installiert und die Anzahl der nfsd-Prozesse auf 8 erhoeht habe. Auch laesst sich in /usr/src/linux/fs/nfsd/ noch ein bischen tunen, z.B. reply-cache groesser machen usw.
Wie siehts mit dem Userspace NFSd aus? Gleiches Problem? AFAIR lag der Vorteil von Kernel-NFS im lockd, der funktioniert aber mit ReiserFS nicht.
Aber man bastelt halt damit nur an den Symptomen rum...
NAC, es gibt keine Einstellung, die für alle Fälle optimal ist, die Vorgaben sind nur Erfahrungswerte mit dem die meisten System klarkommen, aber der große Vorteil von OSS ist ja das man selber die Mäglichkeit hat sein System zu optimieren, was man wenn es notwendig ist auch tun sollte/muß, und man nicht an die Vorgaben von irgendwelchen Programmierern gefesselt ist. Am System rumbasteln tust du nur, wenn du danach nicht ein patch anfertigst, das du beim nächsten Update wieder einspielen kannst. cu Gerald
Am Dienstag, 20. November 2001 09:39 schrieb Chris Kuhi
ReiserFS ist schnell, stabil, neigt zu Problemen bei NFS.
Das höre ich ja überall, allerdings erst nachdem ich ReiserFS schon eingesetzt hatte, und ich habe nie irgendwas mit NFS bemerkt. Kann jemand hier sagen WAS die angebliche Probleme sind, und wo sie beschrieben werden?
Bei mir gibt es Probleme mit NFS, so daß ich manchmal einpaar versuche brauche die Freigaben zu mounten, bzw. wenn ich versch. Shells am client zum Mounten verwende geht's meistens. Der NFS-client läuft dann immer in einen TimeOut. Aber ich habe leider keine Ahnung ob es am ReiserFS liegt. -- Gruß Alex
Am 19-Nov-2001 Stefan Onken schrieb:
Hallo,
Am Montag, 19. November 2001 um 16:09 schrieb Klaus Voelker,
Was ist denn so die landlaeufige Meinung bezueglich Filesystemen? Sollte man Ext2, Ext3, oder gar ReiserFS installieren? Ich denke hier
diese Threads gehen hier ja relativ häufig rum. Vorneweg: EINE Meinung gibt es nicht, jedoch zeichnet sich eine gewisse Tendenz ab:
ReiserFS ist schnell, stabil, neigt zu Problemen bei NFS.
Stimmt.
Ext2 über jeden zweifel erhaben, aber eben die lange fsck dauer
Das kann ich seit kurzem nicht mehr so ganz einfach unterschreiben. Wir sichern hier zwei Linux-Fileserver mit ARKEIA übers Netz. Sind etwa 2Millionen Files. Irgendwann im September fing die Zeit, die für das Backup bemnötigt wird, immer länger zu werden (von etwa 15 auf fast 30 Stunden). Das Arbeitsverzeichnis von ARKEIA lag auf einer ext2 Partition/Platte. Verschiedene Hinweise deuteten auf Probleme bei der Dateiverwaltung bei Arkeia hin. Darauf hin habe ich eine ander Platte genommen, ein reiserfs draufgespielt, das komplette Arkeiaverzweichnis rüberkopiert, umgemountet, gestartet und siehe da, es lief wieder in knapp 15 Stunden durch. Arkeia baut sich als Datenbank nochmal die komplette Verzeichnisstruktur von allem, was es sichern muß, in seinem Arbeitsverzeichnis mehr oder weniger leer nach. Das bedeutet mindestens 2Millionen dateien in diesem Verzeichnis. So wie es aussieht, kann es dann zu irgend welchen Problemen kommen, die es mit reiserfs nicht gibt. Mit NFS würde reiserfs auch nicht einsetzen.
Ext3 baut ja auf ext2 auf und packt nur das Journal oben drauf. Hat den Vorteil, daß man sie sogar von ext2 systemen mounten kann.
Stimmt. Ausserdem können die neuen Suse-Versionen damit umgehen. Ist beim nächsten Update oder der nächsten Neuinstallation ganz interessant. Meine Betriebssystempartitionen laufen also mit ext3.
XFS ... wohl deutlich langsamer bei kleinen Dateien...
Unter dem Strich scheint es allerdingsb das schnellste und stabilste zu sein. Meine Datenpartitionen auf Fileservern laufen also unter XFS (soweit möglich).
Ich verwende ReiserFS auf einer 200GB LVM (2x100GB). Bin zufrieden, habe aber noch kein NFS.
Da läuft es auch ganz gut. Bleibt noch JFS von IBM. War am Anfang recht unstabil, scheint aber jetzt behoben zu sein. Ist nicht ganz so schnell wie XFS. Im Internet gibbet darüber auch Vergleichstests. -- mfg Peter Küchler, Planungsverband Frankfurt Region Rhein Main
participants (9)
-
Alexander Sommer -
Chris Kuhi -
Christoph Maurer -
Falk Sauer -
Gerald Goebel -
Klaus Voelker -
Peter Kuechler -
Peter Woelfel -
Stefan Onken