On Tue, 04 Nov 2003 10:05:38 +0100 Ralf Corsepius wrote:

On Tue, 2003-11-04 at 09:38, Thomas Börkel wrote:

...

HI!

Newbie-Frage: Welches Filesystem nimmt man am besten?

ext3 --

Wirf bitte einen Blick ins Archiv - Das Thema wurde hier schon zu Tode diskutiert.

Gutes Stichwort ... wo wird denn jetzt archiviert? geocrawler/ ... /287 scheint nichts mehr mitzuschneiden. Nebenbei sollten Leute, die gerne Umlaute nehmen, mal da ein bischen rumlesen!!! -- mfg Hajo C Jeske, UNIX-Software-Entwickler, Unix-Administrator

On Tue, 04 Nov 2003 14:00:50 +0100 Thomas Hertweck wrote:

Hajo C Jeske schrieb:

...

Nebenbei sollten Leute, die gerne Umlaute nehmen, mal da ein bischen rumlesen!!!

Das war alles korrekt enkodiert als UTF-8. Das solltest Du halt beruecksichtigen (falls es Dein MUA nicht automatisch macht), dann klappt es auch mit den Umlauten.

Tach auch, also bisher habe ich das (alte) Listen-Archiv immer im Mozilla gelesen. und da beisst keine Maus den Faden ab, die Suse-Liste sieht dort durch die Umlaute wie geschlachtet aus. UNIX- Leute nehmen darauf Ruecksicht, und schreiben ae, oe, ue und kein sZ. Internet ist international. Bischen viel verlangt, alle Sonderzeichen von allen einzustellen. Das kann man lokal machen - gut, dass es klappt. Aber, was rede ich? Man schaue sich nur die Leute mit re: RE: AW: Antwort: an! - Ich denke, die lernen das hier nie. Und tschuess! -- mfg Hajo C Jeske, UNIX-Software-Entwickler, Unix-Administrator

Das hier ist die *deutschsprachige* Liste, und zur deutschen Sprache gehören eben einige Sonderzeichen. Man legt hier auch viel Wert auf Lesbarkeit ( ich errinnere an x Hinweise zur Zeilenlänge),und die deutsche Sprache ist mit Umlauten eben sehr viel besser lesbar ... Gruss Clemens

Am Mit, 05 Nov 2003, schrieb Thomas Hertweck:

Wo hast Du denn das her? Ich schreibe keine Umlaute, weil ich eine englische Tastatur habe - in meinem Beruf ist eben das Meiste auf englisch.

[...] Warum legst Du Dir die Umlaute nicht auf eine Tastenkombi? cu Hannes

Hajo C Jeske schrieb:

Tja - das ist vielleicht der Fehler : Alles, was dauernd kommt, wird sofort deleted.

Einmal die Woche nenne ich nicht dauernd. Wenn Du die Dir an- gebotenen Hilfsmittel nicht liest, kann niemand etwas dafuer.

Warum nicht 1x zu Anfang, wenn man sich anmeldet. Das haette ich abgespeichert.

Die Etikette wird nicht direkt verschickt, weil SuSE das wohl so nicht mochte. Schliesslich wurde die Etikette ja auch nicht von SuSE, sondern von den Teilnehmern der Liste erstellt. In- zwischen ist es aber AFAIK so, dass der Link auf die Etikette in der Bestaetigung der Anmeldung zu suse-linux enthalten ist. Habe mich aber schon lange nicht mehr hier angemeldet, deswe- gen kann ich Dir das nicht mit 100% Sicherheit sagen...

Und : als Link war das zu lang! (mehrere kB) Und : wer vermutet auch Archiv-Hinweis in einer Etikette?

Wer die Etikette liest, hat eben Vorteile... :-)

Sollte mensch vielleicht 1x/Woche einen _echten_ Link senden: etwa : Link : Listen-Archiv

Noe. Der wird dann genau so ignoriert werden wie Du die Etikette ignorierst. Was also sollte es bringen? Gruesse, Thomson PS: Wieso anederst Du das Subject, ohne es kenntlich zu machen? PPS: Du plenkst bei Doppelpunkten.

On Tue, 04 Nov 2003 14:00:50 +0100 Thomas Hertweck wrote:

Hajo C Jeske schrieb:

...

On Tue, 04 Nov 2003 10:05:38 +0100 Ralf Corsepius wrote:

...

On Tue, 2003-11-04 at 09:38, Thomas Börkel wrote:

...

Newbie-Frage: Welches Filesystem nimmt man am besten?

ext3

minix? ext2? xfs? reiserfs? reiser4? jfs? ... Ohne genau zu wissen, was er machen will, ist Dein Ratschlag ohne Begruen- dung etwas schwer nachzuvollziehen. Ext3 mag ein gutes All- round-FS sein, aber vielleicht gibt es ja etwas besseres...

Guten Tag, mir faellt nur auf, dass Suse-Leute wie wild mehrere FS auf einer Box mischen ... Nur Suse-Leute und die meisten davon ohne nachzudenken. Ich sehe das als Admin ganz einfach : Stellt euch vor, es kommt irgendein Admin zu Hilfe (gerufen, weil nix mehr geht) und der geht einfach davon aus, dass ext3 im Spiel ist. Wer denkt auch daran, dass der Herr Installer wild gemischt hat. Alles, was so im Angebot ist durcheinander!!! WOZU? - Selbst ext2 wird noch benutzt - Wozu? ext3 bootet - und fertig. will doch hoffentlich keiner bestreiten, dass ext3 Vorteile hat gegen ext2. Es gibt auch ausreichend Leute, die sagen, dass ext3 _jetzt_ besser ist als ReiserFs. Nach kolossalen Problemen mit Suse (ich war zahlender Kunde also mit Support) und der Support hat nicht geholfen (!!!) (viele sinnlose Ferngespraeche) halte ich es mit RedHat. Die nehmen ext3. Ausserdem gehe ich davon aus, dass RH alles vom System ausgiebig testet, ehe es auf eine Distribution kommt. Eine fehlgeschlagene Installation habe ich bei RedHat noch nicht erlebt. - Mit Suse schon. (mehrfach) RedHat-Support habe ich noch nie gebraucht. RedHat hatte schon automatische Hardware-Erkennung. als Suse damit anfing - und das funktionierte kaum. Bei RedHat schon und zwar zufriedenstellend. -- mfg Hajo C Jeske, UNIX-Software-Entwickler, Unix-Administrator

Hajo C Jeske schrieb:

[...] mir faellt nur auf, dass Suse-Leute wie wild mehrere FS auf einer Box mischen ...

Was verstehst Du unter "wie wild"? Was ist schlecht daran, wenn man zwei Dateisysteme auf einem PC einsetzt? Hatte auch unter Win zwei Dateisysteme, NTFS und VFAT. Wo ist das Problem?

Nur Suse-Leute und die meisten davon ohne nachzudenken.

Ich glaube, die Mails haben gezeigt, dass sehr wohl nachgedacht wird und eben nicht einfach ohne zu hinterfragen und ohne Be- gruendung zu einem gewissen Dateisystem geraten wird, sei es nun ext2/3 oder reiserfs oder xfs oder noch andere...

Ich sehe das als Admin ganz einfach :

Stellt euch vor, es kommt irgendein Admin zu Hilfe (gerufen, weil nix mehr geht) und der geht einfach davon aus, dass ext3 im Spiel ist.

Warum sollte er? Genau so kann er davon ausgehen, dass reiserfs im Spiel ist, denn das ist Default bei SuSE. Du gehst also schon mal von voellig falschen Voraussetzungen aus. Und wenn ich als Admin nicht mal in der Lage bin zu wissen, auf welchen Parti- tionen ich welches Filesystem habe, dann ist das alles wohl der falsche Job fuer mich. Und wenn der zu Hilfe gerufene Admin blind davon ausgeht, dass ein ganz bestimmtes Dateisystem ge- nutzt wird, dann hat wohl auch der einen falschen Job...

Wer denkt auch daran, dass der Herr Installer wild gemischt hat. Alles, was so im Angebot ist durcheinander!!! WOZU? - Selbst ext2 wird noch benutzt - Wozu?

Warum nicht? Wenn es Sinn macht, ist das doch gut.

ext3 bootet - und fertig.

Hmm, das tun andere Filesysteme auch.

will doch hoffentlich keiner bestreiten, dass ext3 Vorteile hat gegen ext2.

Das hat niemand bestritten, dass ext3 Vorteile gegenueber ext2 hat.

Es gibt auch ausreichend Leute, die sagen, dass ext3 _jetzt_ besser ist als ReiserFs.

Es gibt auch ausreichend Leute, die das Gegenteil behaupten. Oder xfs bevorzugen. Oder lieber doch ext2, weil es sich als stabil erwiesen hat. Fuer mich sieht es schlicht so aus, als haettest Du eine vorgefertigte feste Meinung, ext3 sei das ultimative Filesystem und alles andere kann nur schlechter sein. Dem ist aber mit Sicherheit nicht so. Ext3 mag ein guter Allrounder sein, aber fuer gewisse Aufgaben gibt es manchmal eben bessere Alterna- tiven.

Nach kolossalen Problemen mit Suse (ich war zahlender Kunde also mit Support) und der Support hat nicht geholfen (!!!) (viele sinnlose Ferngespraeche) halte ich es mit RedHat. Die nehmen ext3. Ausserdem gehe ich davon aus, dass RH alles vom System ausgiebig testet, ehe es auf eine Distribution kommt.

Ach, Du glaubst also, weil RedHat ext3 einsetzt, ist es das Allerbeste. SuSE setzt ReiserFS, hat das in Deinen Augen sicher nicht getestet - einfach mal halt so genommen. Sorry, aber sol- che Begruendungen finde ich echt erschreckend. Du solltest Dich mal ein wenig mit der Technik auseinandersetzen und mal einen Blick ueber den Tellerrand werden, dann wuerdest Du vielleicht auch besser verstehen, warum andere ext3 nicht als das ultima- tive Filesystem ansehen.

Eine fehlgeschlagene Installation habe ich bei RedHat noch nicht erlebt. - Mit Suse schon. (mehrfach)

RedHat-Support habe ich noch nie gebraucht.

RedHat hatte schon automatische Hardware-Erkennung. als Suse damit anfing - und das funktionierte kaum. Bei RedHat schon und zwar zufriedenstellend.

Warum benutzt Du SuSE dann ueberhaupt, wenn RedHat so toll ist und all das bietet, was Du brauchst. Das verstehe ich ja nun nicht... Versteh das nicht falsch: niemand hat etwas gegen ext3. Das ist bestimmt auch eine gute Wahl fuer jeden Durchschnitts-PC. Aber die Begruendungen, die Du fuer dessen Einsatz lieferst, sind schon reichlich an den Haaren herbei gezogen. Es gibt eben auch Alternativen zu ext3. Und IMHO bieten die eindeutig auch gewisse Vorteile gegenueber ext3. Gruesse, Th.

Thomas Börkel schrieb:

Thomas Hertweck wrote:

...

Alternativen zu ext3. Und IMHO bieten die eindeutig auch gewisse Vorteile gegenueber ext3.

Kannst Du ein bisschen ausführlicher erläutern, bitte?

Das wurde doch schon ausfuehrlich erlaeutert. Besser als Kristian kann man so einen Vergleich wohl kaum machen... Wie auch aus dem Vergleich hervorgeht: die unterschied- lichen Filesysteme haben unterschiedliche Staerken (und Schwaechen) bei unterschiedlichen Situationen - deswegen kann man ja das fuer seine Zwecke geeignete Filesystem verwenden; deswegen auch die Frage, was genau Du machen moechtest. Von der Theorie her ist ext3 (weil auf ext2 basierend) einfach kaum mehr weiter zu optimieren - bei linearen Adressierungen stoesst Du irgendwann auf Deine Grenzen. Es ist allerdings ein guter All-Rounder, so- lange man sich nicht im Grenzbereich bewegt (sehr viele Dateien, usw.). Bei anderen Filesystemen werden unter- schiedliche Arten von Trees verwendet, die sich weit besser optimieren lassen. Daraus ergeben sich gewisse Vorteile. ReiserFS (in v3.6) sollte im Prinzip eine gute Wahl sein - leider habe ich in der Vergangenheit damit schlechte Erfahrungen gemacht und mich dann davon abge- wendet. Reiser4 (ist aber etwas komplett anderes) werde ich mir dann mal wieder anschauen. Xfs laeuft hier auf saemtlichen SGI Workstations und Servern schon sehr lange, das ist das Standarddateisystem dort. Daher war ich daran interessiert, es auch mal unter Linux einzusetzen - und es gab bisher keine Probleme damit. Was ich besonders zu schaetzen weiss, sind die xfs-Tools, auch wenn ich sie bisher unter Linux kaum gebraucht habe und hpts. von den Workstations her kenne. Kleine Partitionen habe ich im- mer noch unter ext2 laufen (z.B. /boot Partition), da macht ein Journal keinen Sinn und verbraucht nur Platz. Ebenso macht IMHO ein ext3 auf einem USB-Stick o. ae. keinen Sinn. Mein Basissystem laeuft hier unter ext3, bis- her auch ohne Probleme. Bei manchen Rechnern, die wir hier so haben, gibt es ab und an Problemchen, egal welches Filesystem installiert ist - die lassen sich mit den ent- sprechenden Tools aber i.d.R. alle beheben. Wie ich schon schrieb: jeder hat so seine eigenen Erfah- rungen gemacht. Wenn alles glatt laeuft und Du einen ganz "normalen" Heim-PC hast, wirst Du zwischen ReiserFS und ext3 wohl kaum einen Unterschied merken. Beides kann man IMHO empfehlen. Allerdings ist _meinen_ Erfahrungen nach ReiserFS problematischer, wenn die darunterliegende Hard- ware kaputt geht. Xfs kannst Du auch nehmen, es ist halt speziell fuer grosse Partitionen und grosse Dateien op- timiert (von Beginn an). Informiere Dich, mache Dir ein eigenes Bild, und probiere einfach ein bisschen aus. Wenn Du genuegend Festplattenkapazitaet oder eine zweite ael- tere Festplatte hast, so kann man ja diese ja mal mit unterschiedlichen Dateisystemen belegen und als /data mounten. Dann kannst Du Dir selbst ein Bild machen... Cu, Th.

Hallo Hajo, Am Mittwoch, 5. November 2003 12:31 schrieb Hajo C Jeske:

Guten Tag,

mir faellt nur auf, dass Suse-Leute wie wild mehrere FS auf einer Box mischen ...

Ja und?

Nur Suse-Leute und die meisten davon ohne nachzudenken.

Wenn ich nicht nachdenke nehme ich doch die Voreinstellung von SuSE, oder? Und die ist ReiserFS.

Ich sehe das als Admin ganz einfach :

Stellt euch vor, es kommt irgendein Admin zu Hilfe (gerufen, weil nix mehr geht) und der geht einfach davon aus, dass ext3 im Spiel ist.

1. Wer soll auf meinem Privat-Server einen fremden Admin rufen? 2. Warum sollte ein Admin einfach davon ausgehen das ext3 benutzt wird? Wenn der Rechner ordentlich administriert ist, dann ist alles dokumentiert. 3. In einem voll administrierten System (keine SuSE-Standardkonf) kennt sich sowieso nur der Admin aus der das gemacht hat. Alle anderen müssen sowieso erstmal schauen und configs lesen.

Wer denkt auch daran, dass der Herr Installer wild gemischt hat. Alles, was so im Angebot ist durcheinander!!! WOZU? - Selbst ext2 wird noch benutzt - Wozu?

*g* hier sprichts du wohl mich an. Ernsthaft: nenne mir doch bitte den Vorteil von ext3 auf einer 10MB /boot-Partition.

ext3 bootet - und fertig. will doch hoffentlich keiner bestreiten, dass ext3 Vorteile hat gegen ext2.

nö. Klar!

Es gibt auch ausreichend Leute, die sagen, dass ext3 _jetzt_ besser ist als ReiserFs.

Subjektiv ist das bei mir auch so, denn ich hab bisher nur auf Reiser Daten verloren. Ob es objektiv schlechter als ext3 ist glaube ich nicht.

Nach kolossalen Problemen mit Suse (ich war zahlender Kunde also mit Support) und der Support hat nicht geholfen (!!!) (viele sinnlose Ferngespraeche) halte ich es mit RedHat. Die nehmen ext3.

"Die" bei SuSE nehmen Reiser!?

Ausserdem gehe ich davon aus, dass RH alles vom System ausgiebig testet, ehe es auf eine Distribution kommt.

SuSE macht das nicht?

RedHat-Support habe ich noch nie gebraucht.

Ich hab den SuSE Support auch noch nicht gebraucht.

RedHat hatte schon automatische Hardware-Erkennung. als Suse damit anfing - und das funktionierte kaum. Bei RedHat schon und zwar zufriedenstellend.

Windows hatte schon 19xx eine Gui, und?

mfg Hajo C Jeske, UNIX-Software-Entwickler, Unix-Administrator

Viele Grüße Andreas

Hi Hajo! Am Mittwoch, 5. November 2003 12:31 schrieb Hajo C Jeske:

Stellt euch vor, es kommt irgendein Admin zu Hilfe (gerufen, weil nix mehr geht) und der geht einfach davon aus, dass ext3 im Spiel ist.

Na der Admin wird sicher nicht noch einmal gerufen...

Wer denkt auch daran, dass der Herr Installer wild gemischt hat. Alles, was so im Angebot ist durcheinander!!!

Schreib das mal an Linus,- raus aus dem Kernel mit dem Zeug!

WOZU? - Selbst ext2 wird noch benutzt - Wozu?

ext3 bootet - und fertig. will doch hoffentlich keiner bestreiten, dass ext3 Vorteile hat gegen ext2.

Bei kleinen bzw sehr kleinen Partizipationen hat ext2 tatsächlich Vorteile...

Es gibt auch ausreichend Leute, die sagen, dass ext3 _jetzt_ besser ist als ReiserFs.

Du findest immer ausreichend Leute die irgend was sagen.... [RedHat ist toll...] (geschnippschnappt)

-- mfg Hajo C Jeske, UNIX-Software-Entwickler, Unix-Administrator

Gruß Harald (_Linux-Dau_)

HI! Thomas Hertweck wrote:

minix? ext2? xfs? reiserfs? reiser4? jfs? ... Ohne genau zu wissen, was er machen will, ist Dein Ratschlag ohne Begruen- dung etwas schwer nachzuvollziehen. Ext3 mag ein gutes All- round-FS sein, aber vielleicht gibt es ja etwas besseres...

Ich würde sagen, ich mache "normale" Anwendungen (Text, Mail, Internet). Zusätzlich gibt es einige größere Files (500-1000 MB) wegen Umrechnerei von Videokram. Thomas

Thomas Börkel wrote:

...

minix? ext2? xfs? reiserfs? reiser4? jfs? ... Ohne genau zu wissen, was er machen will, ist Dein Ratschlag ohne Begruen- dung etwas schwer nachzuvollziehen. Ext3 mag ein gutes All- round-FS sein, aber vielleicht gibt es ja etwas besseres...

Ich würde sagen, ich mache "normale" Anwendungen (Text, Mail, Internet). Zusätzlich gibt es einige größere Files (500-1000 MB) wegen Umrechnerei von Videokram.

In Suse Linux 8.2 und höher werden die folgenden "interessanten" Dateisysteme unterstützt: - reiserfs (Der Default bei der Installation) - ext2 - ext3 - xfs - jfs Transaktionen und Logs Bis auf ext2 sind dies alles transaktionsorientierte Dateisysteme. Das bedeutet, daß nach einem ungeordneten Systemstop (einem Crash) das Dateisystem oft mit Hilfe des Logs wieder geordnet werden kann. Die Zeit zur Systemwiederherstellung ist in diesem Fall also nicht davon abhängig, wie groß die Platte ist, sondern nur, wie viele Transaktionen im Log stehen (wie viele Dateioperationen zum Zeit des Absturzes offen waren). Transaktionsorientierte Dateisysteme bezahlen diesen Vorteil mit dem Nachteil des erhöhten Platzverbrauches (Das Log verkleinert ein Dateisystem um eine gewisse Größe, oft etwa 32MB). Für sehr kleine Dateisysteme, bei denen ein traditioneller fsck sehr schnell geht, ist es also vorteilhaft, ein Dateisystem ohne Log, etwa ext2 zu nehmen. Ab einer Größe von einem GB aufwärts lohnt sich ein transaktionsorientiertes Dateisystem, weil hier der Größenverlust durch das Log nicht ins Gewicht fällt und weil hier die Checkzeiten durch den fsck meßbar werden. Verzeichnisse als Bäume vs. Verzeichnisse als lineare Listen Von reiserfs und xfs weiß ich, daß sie Verzeichnisse als Baumstrukturen und nicht wie traditionelle Dateisysteme (ext2, ext3) als lineare Listen anlegen. Daher können reiserfs und xfs große Verzeichnisse (1000 und mehr Dateien in einem Verzeichnis) effizient bearbeiten. Traditionelle Dateisysteme werden in solchen Strukturen sehr langsam, weil sie beachtliche Zeit zum linearen Durchsuchen der Verzeichnisstrukturen aufbringen müssen. Anwendungen wie ein INN Newsserver mit Tradspool, ein Squid Webcache und sehr große Cyrus Mailfolder oder sehr große kmail Maildirs profizieren sehr stark von den verbesserten Datenstrukturen eines reiserfs oder xfs. Access Control Lists und Extended Attributes In der aktuellen c't findet sich auf Seite 218 ein Artikel von Azundris (ctartikel@azundris.com) zum Thema ACLs und EAs. In Suse Linux sind die notwendigen Patches für reiserfs, ext3 und ext2 enthalten, sodaß auch diese Dateisysteme mit ACLs und EAs umgehen können. xfs und jfs können dies wegen ihrer kommerziellen Herkunft schon seit je her. Umgang mit großen Dateien und großen UIDs Von reiserfs weiß ich durch selbst ausprobieren, daß (in reiserfs 3.6, nicht jedoch in 3.5) Dateien mit mehr als 4 GB Dateigröße angelegt und verwaltet werden können. Ich weiß auch, daß dieses Dateisystem mit UIDs > 16 Bit umgehen kann, also User- und Gruppennummern über 65536 korrekt verwalten kann. Von XFS weiß ich das auch, das war bei diesem Dateisystem ein Designkriterium ab Start. Voraussetzung für die Nutzung dieser Eigenschaften ist, daß die libc ausreichend neu ist und ebenfalls mit großen Dateien und mit großen UIDs umgehen kann. Dies ist bei Suse Linux 8.2 und 9.0 getestetermaßen der Fall. Stabilität Das älteste und am einfachsten strukturierte Dateisystem in der Distribution ist ext2. Es besteht im Kernel aus kaum 5000 Zeilen Code (plus ca. 50.000 Zeilen Userland-Supportcode in mkfs, fsck und anderen Hilfsutilities). Dieser Code ist recht gut untersucht, und mittlerweile auch von einigermaßen guter Qualität (Das war zu den Zeiten als ich meine Diplomarbeit über Invarianten in ext2 schrieb noch nicht der Fall). In Suse Linux ist reiserfs ebenfalls recht gut getestet: Suse Linux verwendet reiserfs schon seit Jahren als Default-Dateisystem, Suse finanziert die Weiterentwicklung von reiserfs substantiell mit und ich nehme an, daß Suse auch interne Supportcalls an das Reiser-Team weiterleitet, sodaß sowohl Suse als das Reiser-Team recht gute Vorstellungen davon haben sollten wie Reiser und Suse-Kernel zusammenspielen. Der Code in XFS und JFS ist ebenfalls recht alt (mehr als zehn Jahre) und in zahlreichen kommerziellen Deployments getestet. Speziell XFS ist dabei ab Start dafür designed worden, besonders in großen Dateisystemen sinnvoll zu skalieren - die XFS-Designer haben dabei schon 1994 in Multi-Terabyte Dateisystemen mit Dutzenden von konkurrenten Readern und Writern gedacht. Das merkt man dem internen Design von XFS auch an. Zum Vergleich: Der kernel-interne Code von XFS ist etwa 10-20 mal umfangreicher und komplexer als der Code von ext2. XFS und JFS sind beide nicht in Linux entstanden, sondern als Bestandteil von SGI Irix (xfs) und AIX (jfs). Sie sind danach nach Linux und die deutlich unterschiedlichen Kernel-Schnittstellen von Linux portiert worden. Ich habe keine Idee, wie stark man das dem Code noch anmerkt oder wie sehr das Stabilität und Effizient belastet. Persönliche Anekdoten über Stabilität Ich habe jahrelang ext2 als Default-Dateisystem verwendet und damit SCSI- und IDE-Platten bis in den zweistelligen GB-Bereich hinein benutzt. Darunter waren auch einige stark belastete Server mit sehr unterschiedlichen Dateigrößen und Benutzungsanforderungen (Newsserver, File+Print-Server, MP3-Server et al). ext2 ist simpel und hat auf diesen Kisten gut Dienst getan. Der fsck von ext2 ist primitiv, aber relativ komplett und zuverlässig. Ich hatte Gelegenheit, ihn im Rahmen meiner Diplomarbeit ausgiebig zu studieren und formal zu analysieren und auch dort hat er überwiegend einen guten Eindruck gemacht. Gegenüber reiserfs und xfs haben ext2 und ext3 beim fsck den Vorteil, daß sie schon beim Anlegen des Dateisystems festlegen (müssen), welche Blöcke Daten und welche Blöcke Metadaten enthalten. Der fsck von ext2 und ext3 kann also schon an der Blocknummer erkennen, ob es sich um eine Inode, Daten oder sonst einen Bestandteil des Dateisystems handelt. reiserfs und xfs können dies nicht. Ist die Datenstruktur des Dateisystems noch rettbar ("reiserfsck --fix-fixable"), macht das keinen Unterschied, weil der fsck dann aus dem Dateibaum ableiten kann, was Daten und was Metadaten sind. Ist der Metadatenbaum jedoch komplett im Eimer ("reiserfsck --rebuild"), dann muß der fsck hier das ganze Dateisystem durchscannen und kann dann auf der Grundlage von Magic Numbers in den Datenstrukturen vielleicht erkennen, ob es sich um Daten oder Metadaten handelt. Das führt zu interessanten Effekten, wenn sich auf dem zu untersuchenden Dateisystemen weitere Reiserfs-Datenstrukturen in loop-Dateien, vmware-vmdk-Dateien oder anderen Containern befinden. In meinem Fall hat so ein Scan ca. 800 MB Geisterfiles in die neue Root des geretteten reiserfs gebeamt (Nutzdaten sind jedoch nicht verloren gegangen, und der ursprüngliche Crash ging auf das Konto vom nvidia-Treiber, nicht von reiserfs). Entscheidungskriterien Suse Linux verwendet per Default reiserfs. Das ist eine gute und inzwischen extrem stabile Wahl. Neulinge und unerfahrene Benutzer sollten dies einfach so lassen und den Installer machen lassen. Performance-Junkies und Benutzer sehr großer Dateisysteme (wir reden hier von Terabytes im Plural) sollten sich einmal XFS ansehen. Es hat eine Reihe von Features, die diesen Anwendern sehr entgegen kommen. ext2 und ext3 sind sehr konserative Dateisysteme. Sie haben Performanceprobleme mit großen Dateisystemen, mit großen Verzeichnissen und mit großen Dateien mit vielen konkurrenten Writern (etwa großen Oracle DBF-Dateien). Sie sind andererseits sehr gut untersucht und verstanden und sie haben Datenstrukturen auf der Platte mit passiver Sicherheit. ext2 ist außerdem sehr klein. Benutzer leistungsschwacher PCs mit kleinen Platten sollten ext2 oder ext3 verwenden. Benutzer existierender Dateisysteme, die nicht neu formatieren wollen, sollten ihre ext2-Installation auf ext3 upgraden, wenn das existierende Dateisystem wenigstens ein GB groß ist, und so wenigstens die Vorteile des Loggings nutzen. Benutzer mit großen Directories (mehr als 1000 Files in einem Verzeichnis) sollten ein Dateisystem mit Baumstrukturen als Verzeichnisse verwenden, etwa reiserfs oder xfs. Dieser Text kann von Suse als Bestandteil der sdb verwendet werden. Er kann von FAQ-Projekten verwendet werden. Die Autorennennung ist zu erhalten. Kristian

David Haller schrieb:

Erstmal danke fuer deine recht gelungene Zusammenfassung :)

Ja, kann ich mich nur anschliessen. War sehr nett zu lesen.

Aber ein paar Anmerkugen kann ich machen (und Thomson wohl auch).

Oehm, ich habe in diesem Thread schon wieder viel zu viel gesagt :) Mein Eindruck ist, dass jeder eh selbst so seine Erfahrungen sammeln muss. Das ist manchmal hart, aber wenn man Backups hat, sollte das nicht unbedingt schlimm sein, wenn mal was daneben geht. Nach unserem letztem Filesystem-Thread habe ich mal ein paar Tests gemacht, aehnlich wie David es auch schon mal hier praesentiert hat. Allerdings neben vielen kleineren Dateien auch eher mit Dateigroessen im Gigabyte-Bereich, weil wir eben meist mit grossen Dateien zu tun haben, wenn es um 3D Seismik geht. Momentan habe ich leider nicht die Zeit, so etwas fuer alle Dateisysteme mal ordentlich durchzufuehren unter gleichen Bedingungen, aber interessant waere es schon. Die Dinge entwickeln sich ja auch weiter... Reiser4 wird ja dann auch mal dazu kommen. Vielleicht hat ja jemand Lust, das zu tun?

Am Wed, 05 Nov 2003, Kristian Koehntopp schrieb:

...

[...] Das führt zu interessanten Effekten,

So kann man das auch nennen[1].

Dazu faellt mir nur ein (etwas abgewandelter) Spruch ein: My filesystems never have bugs. They just develop random features. :-)

[..]

...

ext2 ist außerdem sehr klein. Benutzer leistungsschwacher PCs mit kleinen Platten sollten ext2 oder ext3 verwenden.

ACK.

Yep. Wenn es eine eigene /boot Partition gibt, dann ist das auch so ein Kandidat. Ist in der Regel ja selten groesser als 20 MB. Das reicht fuer ein paar Kernel :-)

[1] out of Context zu quoten macht Spass *scnr*

*g* Gruesse, Th.

Hallo, Am Wed, 05 Nov 2003, Kristian Köhntopp schrieb:

On Wednesday 05 November 2003 21:19, David Haller wrote:

...

Meiner Erfahrung nach (zumindest mit etwas aelteren reiserfsck Versionen) kann man das FS dann komplett wegwerfen.

Ich denke, Du solltest schon zwischen reiserfs 3.5 und 3.6 unterscheiden. Insbesondere beim reiserfsck liegen zwischen beiden Systemen Welten.

Ja, auch deswegen hab ich's extra erwaehnt. Naja, ich habe damals (gegen Ende von 3.5) reiserfs erstmal ad acta gelegt -- und bisher nix gefunden was mich wieder zu reiserfs bringen wuerde.

...

...

Benutzer mit großen Directories (mehr als 1000 Files in einem Verzeichnis)

Da hast du ne Potenz zu niedrig gegriffen, ext2/ext3 sind auch mit 10000 Dateien verwendbar, bei mehr wird's dann aber langsam nervig.

Sobald die Verzeichnisse in ext2 und ext3 eine Größe erreicht haben, daß indirect blocks verwendet werden müssen (bei 4KB Blockgröße als mehr als 72 KB Verzeichnisgröße, bei im Mittel 20 Zeichen pro Dateiname also ab ca. 3500 Dateien pro Verzeichnis) bricht die namei-Performance von ext2/ext3 ganz erheblich ein.

Koennte hinkommen ;) Aber bei "Userdaten" im ~ sind so grosse Verzeichnisse ja eh nix, fuer nen news-spool etc. ist das was anderes. Ich merke hier aber keinen Unterschied zwischen reiserfs und ext3 bei grossen Newsgruppen (in leafnode) -- da spielen eher die Festplatten-Zugriffszeiten bzw. der Newsreadeer die entscheidende Rolle. Oder die Ausgabe im Terminal: $ cd /var/spool/news/.... $ ls >/dev/null $ ls >/dev/null ## Plattencache fuellen $ time ls >/dev/null real 0m0.416s $ time ls | wc -l 31604 real 0m0.451s $ time ls [..] real 0m2.901s $ time ls -1 [..] real 0m16.472s Also, in der Praxis seh ich da keine praxisrelevanten Nachteile... In besonderen Anwendungs(!)-Faellen koennen natuerlich reiserfs oder xfs durchaus ihre Staerken ausspielen. An reiserfs fehlt mir einfach die Robustheit, xfs kenne ich nicht genug um das kritisch zu beurteilen.

...

Robustheit

ext2/ext3 haben Redundanzen, die einzelne "Sektorverluste" ausbuegeln koennen, reiserfs ist (AFAIR generell) nicht redundant. Wie es bei xfs und jfs aussieht weiss ich nicht.

ext2/ext3 hat keine Redundanzen, Informationen werden auch bei diesem Dateisystem nur einmal abgelegt. Der einzige Vorteil, den e2fsck nutzen kann, ist die implizite Kenntnis ob ein Block Daten oder Metadatenblock ist.

man -P'less +/\-b' e2fsck Siehe dazu auch die Meldungen beim mke2fs. Und natuerlich die Quellen von ext2/ext3 im Kernel ;) Und gerade der Superblock (warum heisst der gerade _super_block?) ist eben entscheidend. Wenn's denn z.B. beim reiserfs erwischt (das hatte hier ja die Tage einer), dann hat man verloren. Bei ext2/ext3 kann man auf einen der redundanten anderen Superblocks ausweichen... Und bei den anderen Metadaten ist dann die Redundanz schon wesentlich weniger wichtig.

reiserfsck löst ebenso wie e2fsck Dateien mit doppelt allozierten Blöcken ("Crosslinks") durch Duplizierung der betreffenden Blöcke auf. Die verwendeten Strategien sind genau spiegelbildlich, und sie funktionieren gut, wie ich leider vorgestern testen konnte.

*hehe* Was war denn? -dnh PS: e2fsck ist 1.28 und wird demnaechst wohl auch wieder aktualisiert. Als ich noch reiserfs verwendet habe habe ich auch reiserfschk (bzw. spaeter die reiserfstools etc.) aktuell gehalten. Nur die Umstellung auf reiserfs 3.6 kam fuer mich zu spaet. -- "I stopped at Land's End, because to go any further would have been Scilly." -- Robert Billing

HI! Vielen Dank für die ausführlichen Beschreibungen! Mich würde jetzt nur noch interessieren, was eigentlich der Nachteil von XFS ist. Thomas

On Thursday 06 November 2003 08:31, Falk Sauer wrote:

...

Mich würde jetzt nur noch interessieren, was eigentlich der Nachteil von XFS ist.

Wie Kristian schon schrieb, es ist nix für schwachbrüstige Rechner die eh schon auf dem letzten Loch pfeifen, wie jedes Journaling FS.

Im Übrigen hab ich oberhalb ~700GB noch kein ext2/reiser zum laufen bekommen, das hat nur xfs in den Griff gekriegt noch dazu mit ordentlicher Performance.

Dazu kommt ein Problem, das die gezeigten Benchmarks nicht beleuchten: XFS ist (zumindest das 1994er original XFS von SGI) ein Dateisystem, das seine größten Stärken besonders auf sehr großen Dateisystemen ausspielen kann, auf denen sehr viele konkurrente Zugriffe stattfinden (Ich vermute mal, daß die verwendeten Benchmarks eher sequentielle Struktur haben). Zum Beispiel: ext2 und auch ext3 verwenden eine Inode- und eine Block-Allocation Bitmap. Nur ein Prozeß zur Zeit kann diese Bitmap belegen. Um eine neue Datei anzulegen (Inode-Bitmap) oder eine existierende Datei zu vergrößern (Block Bitmap) legt der betreffende Prozeß ein Lock auf den In-Memory Superblock des Dateisystems und durchsucht dann die passende Bitmap nach Nullbits. Er markiert diese Blöcke als belegt, und entfernt das Lock. Hast Du viele konkurrente Writer im Dateisystem, die Dateien anlegen, löschen, Dateien vergrößern und ftruncaten, dann bekommst Du auf diesem Lock Contention, und die konkurrenten Prozesse müssen aufeinander warten. Nicht so in XFS: In XFS werden Extents von freien Blöcken (und anderen Strukturen) verwaltet. Ein Extent ist ein Paar (Startposition, Länge), und XFS organisiert diese Extents in Bäumen. Diese sind schneller durchsuchbar als eine Bitmap, sodaß die Lockzeiten kürzer sind. Außerdem unterteilt XFS das Dateisystem in Allocation Groups von einigen Gigabytes Größe, die jeweils eigene Locks haben. Arbeiten die konkurrenten Writer in unterschiedlichen Allocation Groups, können sie unabhängig voneinander an den zur jeweiligen Allocation Group gehörenden Bäumen rumschrauben. Dadurch wird Lock Contention vermieden. Zum Beispiel: ext2 und ext3 garantieren wie jedes UNIX-Dateisystem atomare Writes. Dazu wird zu Beginn jedes write-Systemaufrufs ein Lock auf die In-Memory Copy der Inode der Datei gelegt, die beschrieben werden soll. Dann werden die Buffer-Cache-Blöcke geändert und das Lock gelöst. Hast Du jetzt viele konkurrente Writer auf einer sehr großen Datei, etwa ein Oracle DBF-File mit einem Haufen Writer-Prozessen, dann blockieren sich diese Writer gegenseitig, weil Contention auf das Lock in der Inode der DBF-Datei stattfindet. Nicht so in XFS: In XFS werden an der Inode der Datei Extents für jeden Write hinterlegt, in denen Start und Länge des Writes vermerkt werden. Solange die Writes alle nichtüberlappend sind, können sie so durch XFS parallelisiert werden. Die betreffenden Writes schreiben dann ihre Daten, und können dann ihren Lock-Extent an der Inode wieder entnehmen. XFS kann dadurch massiv parallel beschreibbare Files realisieren, und dennoch UNIX-Write-Semantik garantieren. Nur überlappende Writes werden durch die Extent-Locks serialisiert. SGI hat ein paar sehr schöne (und mittlerweise fast 10 Jahre alte) Whitepapers zum Thema XFS als USENIX-Talks eingereicht, die sehr deutlich zeigen, wie weit XFS seiner Zeit voraus war. Kristian -- http://www.amazon.de/exec/obidos/wishlist/18E5SVQ5HJZXG

On Thursday 06 November 2003 08:18, Thomas Börkel wrote:

Mich würde jetzt nur noch interessieren, was eigentlich der Nachteil von XFS ist.

kris@valiant:~> lsmod | egrep "(reiser|xfs)" xfs 504220 1 (autoclean) reiserfs 200084 2 -- http://www.amazon.de/exec/obidos/wishlist/18E5SVQ5HJZXG

[...Nachteile von XFS...] Ralf Corsepius wrote:

Das Hauptproblem: Fehlende Erfahrungswerte und praktisch nicht vorhandende Unterstützung durch die grossen Linux-Distributoren (Weder SuSE noch RH).

Was verstehst Du unter "nicht vorhandene Unterstuetzung"? Meinst Du das finanzieller Art oder wie? Weil die Distri- bution kannst Du nicht meinen, die kann naemlich ohne Pro- bleme mit XFS umgehen, und im SuSE-Kernel ist XFS schon laenger fester Bestandteil. SuSE verwendet ReiserFS als Standarddateisystem, aber das kann jeder bei der Instal- lation aendern und dort auch XFS auswaehlen.

Weiterhin gilt: Auch wenn xfs im Prinzip schon relativ alt ist, ist die Integration in Linux noch relativ jung und erforderte recht massive Eingriffe in den Kernel (Ich weiss nicht ob xfs mitterweile vollständig in den Kernel integriert sind. Lange Zeit waren recht massive Patches erforderlich, die nicht unerhebliche Probleme hatten ihren Weg in den Kernel zu finden, da sie recht massiv in den Kernel eingriffen.)

ACK. Ein grosses Problem war vor allem, dass die XFS- Patches vieles redundant implementierten, was eigentlich im Kernel schon an anderer Stelle vorhanden war und auf das man haette zugreifen koennen. Zumindest hat das so A. Cox mal erklaert. Deswegen wird XFS im Vanilla-Kernel nach- wievor etwas stiefmuetterlich behandelt.

Es gibt xfs-User, die sich begeistert darüber äussern (Kristian gehört offensichtlich dazu ;) ).

Ich hatte bisher mit XFS auch keine Probleme, kenne es aber auch schon lange von unseren SGI Workstations.

Probiers aus und bilde Dir selbst ein Urteil, wenn's Dich interessiert, es sich bei Deiner Maschine nicht gerade um einen wichtigen Produktionsserver handelt und Du Backups machst.

ACK. Gruesse, Th.

Andreas Kyek schrieb:

[Auswahl des Filesystems]

Es ist einfach nur 'ne Geschmacksfrage, oder?

Fuer einen "normalen" Heimanwender duerfte es wirklich nicht sehr viele Unterschiede geben. Und da so ein Heimanwender dann auch nicht zwischen verschiedenen Filesystemen vergleicht, wird er es gar nicht merken, ob er nun "langsamer" oder "schneller" ist mit diesem und jenem Filesystem. Er wird sich darueber auch nicht so viele Gedanken machen und einfach auf seine Ausgabe warten... Wenn man natuerlich von vorne herein weiss, fuer was man eine Partition einsetzen moechte, kann man natuerlich entsprechende Ueberlegungen anstellen. Ich denke, bei Heiman- wendern spielt die groesste Rolle einfach, wie gut sie bisher mit ihrem verwendeten Filesystem zurecht gekommen sind und ob es da in der Vergangenheit Probleme gab (und z.B. eine Neuin- stallation notwendig war - so etwas vergisst man nicht). Allerdings gibt es eben doch ein paar Dinge (auch fuer Heiman- wender), die man bedenken sollte: So z.B. die Tools, die fuers Reparieren zur Verfuegung stehen. Oder aber die Tatsache, dass ein Journal Platz braucht und daher auf sehr kleinen Filesyste- men wenig Sinn macht. Oder eben die Frage, wie stabil sich das Filesystem verhaelt, auch wenn es mal Aerger gibt. Und nicht zuletzt spielen auch die eigenen Erfahrungen eine Rolle - wer mit ext3 noch nie Probleme hatte, wird sicher darauf schwoeren, wer mit ReiserFS zufrieden ist, wird auch nicht wechseln wollen. Da gibt es sicher auch noch weitere Faktoren, die eine Rolle spielen. Ich bin einfach froh, dass ich die Auswahl habe :-) Und, mit Verlaub, ich denke es ist gut, wenn man hier auf der Liste auch etwas ueber Vor- und Nachteile erfaehrt, selbst wenn man letzt- endlich davon nicht so betroffen ist, und wenn die Mehrheit die technischen Ausfuehrungen von Kristian nicht verstanden haben duerfte. Immerhin wissen die Mitglieder der Liste nun, wo sie mal so etwas nachlesen koennen, wenn sie es denn brauchen... Ich fand das jedenfalls mal wieder sehr informativ (auch wenn ich ebenfalls nicht alles 100% verstanden habe ;-) Gruesse, Th.

Ralf Corsepius schrieb am 07.11.2003 um 09:22:23 +0100: Hallo Ralf,

On Fri, 2003-11-07 at 08:20, Thomas Hertweck wrote:

...

[...Nachteile von XFS...]

Ralf Corsepius wrote:

...

Das Hauptproblem: Fehlende Erfahrungswerte und praktisch nicht vorhandende Unterstützung durch die grossen Linux-Distributoren (Weder SuSE noch RH).

Was verstehst Du unter "nicht vorhandene Unterstuetzung"? Aktives Engagement, inkl. Integration in die Installationstools, aktives Einpflegen von Patches/Bugfixes, aktives Testen usw.

...

Meinst Du das finanzieller Art oder wie? Weil die Distri- bution kannst Du nicht meinen, die kann naemlich ohne Pro- bleme mit XFS umgehen, und im SuSE-Kernel ist XFS schon laenger fester Bestandteil. SuSE verwendet ReiserFS als Standarddateisystem, aber das kann jeder bei der Instal- lation aendern und dort auch XFS auswaehlen. Aha, das scheint dann neu zu sein und scheint unter RH/Fedora anders zu sein. Ich weiss momentan nicht einmal, ob xfs überhaupt in den Kernel integriert ist ;)

ab 2.6 ist es AFAIK drin. Bis denne, Michael -- ---------------------------------------------------------- Michael Schulz, Institut f. Geophysik, Universität Münster Corrensstr. 24, 48149 Münster Tel.: 0251-8333938, e-mail: michael@earth.uni-muenster.de

On Friday 07 November 2003 08:07, Ralf Corsepius wrote:

Das Hauptproblem: Fehlende Erfahrungswerte und praktisch nicht vorhandende Unterstützung durch die grossen Linux-Distributoren (Weder SuSE noch RH).

In Suse Linux ist XFS seit geraumer Zeit als vollwertiges Dateisystem integriert, und wird auch bei der Installation angeboten. Es ist jedoch nicht Default (der ist reiserfs).

Weiterhin gilt: Auch wenn xfs im Prinzip schon relativ alt ist, ist die Integration in Linux noch relativ jung und erforderte recht massive Eingriffe in den Kernel (Ich weiss nicht ob xfs mitterweile vollständig in den Kernel integriert sind. Lange Zeit waren recht massive Patches erforderlich, die nicht unerhebliche Probleme hatten ihren Weg in den Kernel zu finden, da sie recht massiv in den Kernel eingriffen.)

Ich kenne den Quelltext von XFS nicht, sondern nur die Whitepapers. Denen zufolge setzt XFS ein Buffer Cache System voraus, das von traditionellen Unix-Buffercaches sehr verschieden ist. Ich könnte mir vorstellen, daß dies der Grund für die von Dir beobachtete Duplizierung ist. Ein traditioneller Buffercache speichert Plattenblöcke im RAM, und tut dies unter der physikalischen Blockadresse. An jedem Cacheblock klebt also ein Tripel (major device number, minor device number, blocknummer). Dadurch wird sichergestellt, daß von einem Plattenblock nicht zwei Kopien im Cache existieren können und der Cache also konsistent gehalten werden kann. Beim Schreiben von neuen Datenblöcken wird jedoch ein neuer Block erst einmal in den Cache gelegt, um dann irgendwann später (bis zu 30 Sekunden später) zusammen mit allen anderen geänderten Blöcken auf die Platte geschrieben zu werden. Das hat aber zur Folge, daß jeder neue Block sofort layoutet werden muß, d.h. daß für jeden Block sofort eine physikalische Blockadresse auf der Platte gefunden werden muß. Programme schreiben nun in den meisten Fällen (immer, wenn keine Datenbankanwendung genutzt wird) ganze Dateien von vorne nach hinten durch. Es wäre nützlich für den Layouter des Dateisystems, wenn er solche Dateien auch am Stück layouten könnte, also nicht Block für Block ohne Kenntnis der Vorgänger oder Nachfolger positionieren müßte. XFS auf SGI organisiert den Buffercache also nicht nach physikalischen Blockadressen, sondern nach (major device number, minor device number, inode-nummer, logische Blocknummer in der Datei). Statt also (3, 1, 4711) für Block 4711 auf /dev/hda1 zu speichern, speichert XFS (3, 1, 0815, 2) für den 2. Block der Datei mit der Inode 0815 auf /dev/hda1. Das erlaubt es XFS, den Cache dateiweise zu flushen (Schreibe alle Blöcke der Datei mit der Inode 0815 von /dev/hda1) und diese Blöcke dann am Stück zu layouten. Die Layout-Entscheidung wird außerdem verzögert von dem Moment, wo der Block im Cache belegt wird zu dem Moment wo der Block aus dem Cache geflushed wird. Zu diesem Zeitpunkt ist aber der Kontext des Blocks (seine Vorgänger und Nachfolger) bereits bekannt und der Layouter kann diese zusätzliche Information verwenden um die Gesamtgröße der Allocation zu bestimmen. Da XFS außerdem seine freien Blöcke nicht in Bitmaps verwaltet, sondern in Extents (Paare von Startblock, Länge), und diese Extents nach Startblock und nach Länge in Bäumen indiziert, kann der XFS Layouter sehr schnell Extents in der für den Cache-Flush der Datei benötigten Länge bestimmen und die Datei "best-fit" unfragmentiert layouten. Das ist nach meinen Informationen ein Alleinstellungsmerkmal von XFS und wie gesagt für die interne Struktur von Unix Buffercaches sehr fremdartig. Ich habe keine Ahnung, ob dies mit dem eigentlichen XFS zusammen von SGI nach Linux portiert worden ist. Ich befürchte fast, daß dies nicht passiert ist, denn es hätte die VFS Cache-Layer vom Kernel komplett auf den Kopf gestellt. Wie gesagt, XFS in SGI ist von ca. 1994 oder so. Es ist also nun knapp 10 Jahre alt, und es ist allen anderen Ansätzen im Bereich Dateisysteme noch immer weit voraus (Und ich habe noch nicht mal angefangen von Streaming IO und der Guaranteed Rate I/O Layer zu erzählen, die leider nicht mit XFS zusammen nach Linux portiert worden ist). Kristian, leider niemals SGI benutzt habend

Hi, 0n 03/11/05@14:54 Thomas Börkel told me:

HI!

Thomas Hertweck wrote:

...

minix? ext2? xfs? reiserfs? reiser4? jfs? ... Ohne genau zu wissen, was er machen will, ist Dein Ratschlag ohne Begruen- dung etwas schwer nachzuvollziehen. Ext3 mag ein gutes All- round-FS sein, aber vielleicht gibt es ja etwas besseres...

Ich würde sagen, ich mache "normale" Anwendungen (Text, Mail, Internet). Zusätzlich gibt es einige größere Files (500-1000 MB) wegen Umrechnerei von Videokram.

Ich bin vor ca. 2 Jahren fuer video zu xfs geweselt. Zunaechst nur meine /multimedia Partition (ca. 100 GB lvm). Mit reiser hatte ich schlechte Erfahrungen und in den meisten video Foren wird xfs empfohlen. Performance technisch wage ich aber zu bezweifeln, dass Du einen Unterschied _merken_ (nicht messen) wirst. Da xfs mir alles bietet, was ich brauche benutze ich es inzwischen ueberall ausser auf meinem Family server/router der bootet alle Jahr mal und hat ext2. -- bye maik

Hallo, Am Tue, 04 Nov 2003, Ralf Corsepius schrieb:

On Tue, 2003-11-04 at 13:06, Hajo C Jeske wrote:

...

On Tue, 04 Nov 2003 10:05:38 +0100 Ralf Corsepius wrote:

...

Wirf bitte einen Blick ins Archiv - Das Thema wurde hier schon zu Tode diskutiert. Gutes Stichwort ... wo wird denn jetzt archiviert? Bei www.suse.de, allerdings m.W. nicht suchbar ;)

...

geocrawler/ ... /287 scheint nichts mehr mitzuschneiden. Google ?

Mit 'site:lists.suse.com' allemal! 'marc.thaimsgroup.com' wurde ja schon genannt. -dnh -- Why use windows, when there's a door?