Hallo! Welches Dateisystem ist für einen Proxy (Squid) besser, reiserfs oder ext3? Gruss, Jürgen
Hallo Jürgen, bei der Disp. SuSE 7.2 hat reiser Probleme mit dem Squid. In der 7.3er sollte es eigendlich behoben sein. Da kannst Du eigendlich die Vorteile von Reiser nutzen. Bye Stefan Jürgen Fahnenschreiber wrote:
Hallo!
Welches Dateisystem ist für einen Proxy (Squid) besser, reiserfs oder ext3? Gruss,
Jürgen
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Moin,
* Jürgen Fahnenschreiber
Welches Dateisystem ist für einen Proxy (Squid) besser, reiserfs oder ext3? Nach allem, was ich so gehört habe, ist ext3 deutlich zuverlässiger als Reiser. Das bedeutet aber nicht, daß Du nicht Glück haben kannst.
Thorsten -- [ ] War [x] Peace
* Jürgen Fahnenschreiber schrieb am 25.02.02 um 07:05 Uhr:
Hallo!
Welches Dateisystem ist für einen Proxy (Squid) besser, reiserfs oder ext3? Gruss,
ReiserFS -Marc -- BUGS My programs never have bugs. They just develop random features. If you discover such a feature and you want it to be removed: please send an email to bug@links2linux.de
Hallo, * On Mon, Feb 25, 2002 at 07:53 AM (+0100), Marc Schiffbauer wrote:
* Jürgen Fahnenschreiber schrieb am 25.02.02 um 07:05 Uhr:
Welches Dateisystem ist für einen Proxy (Squid) besser, reiserfs oder ext3?
ReiserFS
Da ich auch gerade dabei bin, für meine ehemalige Schule einen neuen Proxy-Server (SQUID) aufzustellen, stellt sich für mich auch die Frage nach dem File-System. Auf von mir betreuten File-Servern habe ich mit "ext3" keine schlechten Erfahrungen gemacht und hatte jetzt in Erwägung gezogen, dieses File- System auch für die Cache-Partition des neuen SQUID-Proxy-Servers zu verwenden (als ich die File-Server aufsetzte, gab es in Bezug auf "ReiserFS" nämlich Schwierigkeiten in Bezug auf "Disk-Quota", was ich ja auf den Servern brauchte, daher damals die Entscheidung für "ext3"). Mich würde nun natürlich interessieren, wo genau die Vorteile von "ReiserFS" für Caching-Proxy-Partitionen liegen? Ist das "ReiserFS" für die Proxy-typischen Zugriffe entsprechend optimiert? Gruß, Steffen
Steffen Moser
Mich würde nun natürlich interessieren, wo genau die Vorteile von "ReiserFS" für Caching-Proxy-Partitionen liegen? Ist das "ReiserFS" für die Proxy-typischen Zugriffe entsprechend optimiert?
Ich würde sagen, dass ReiserFS die richtige Wahl ist, weil: - es schnell ist (Das ist bei dem Squid wohl recht wichtig und das ist etwas, dass total gegen ext3 spricht (ext3 ist ext2 + irgendwas, das auch Zeit kostet!) - die Probleme mit dem Filesystem, die wohl auftreten können (Ich hatte diese noch nicht, obwohl ich sehr rabiat bin und meinen Laptop z.B. immer so ausschalte!) nicht interessieren. Wenn Du Probleme mit dem Cache hast, dann formatierst Du die Platten neu - ist da gut zu verantworten!) Da in verschiedenen Listen hin und wieder von Problemen mit ReiserFS berichtet wird, könnte es natürlich sehr wohl interessant sein, z.B. Logs und ähnliches auf ext3 liegen zu haben! Just my 2 Cent. Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53
Hallo, * On Mon, Feb 25, 2002 at 10:17 AM (+0200), Konrad Neitzel wrote:
Ich würde sagen, dass ReiserFS die richtige Wahl ist, weil: - es schnell ist (Das ist bei dem Squid wohl recht wichtig und das ist etwas, dass total gegen ext3 spricht (ext3 ist ext2 + irgendwas, das auch Zeit kostet!)
Das ist natürlich einleuchtend - da werde ich dann für die SQUID-Cache- Partition auf "ReiserFS" setzen. Muss ich beim Erstellen des "ReiserFS" noch irgend etwas beachten, um es auf den Verwendungszweck hin zu optimieren, d.h. muss ich irgendwelche Optionen beim Erzeugen verwenden (vermutlich nicht, aber ich habe noch nicht viel mit "ReiserFS" gemacht)?
- die Probleme mit dem Filesystem, die wohl auftreten können (Ich hatte diese noch nicht, obwohl ich sehr rabiat bin und meinen Laptop z.B. immer so ausschalte!) nicht interessieren. Wenn Du Probleme mit dem Cache hast, dann formatierst Du die Platten neu - ist da gut zu verantworten!)
Stimmt. Da wären solche Probleme nicht tragisch.
Da in verschiedenen Listen hin und wieder von Problemen mit ReiserFS berichtet wird, könnte es natürlich sehr wohl interessant sein, z.B. Logs und ähnliches auf ext3 liegen zu haben!
Das werde ich dann auch so machen. Gruß, Steffen
Steffen Moser
Muss ich beim Erstellen des "ReiserFS" noch irgend etwas beachten, um es auf den Verwendungszweck hin zu optimieren, d.h. muss ich irgendwelche Optionen beim Erzeugen verwenden (vermutlich nicht, aber ich habe noch nicht viel mit "ReiserFS" gemacht)?
Ich denke nicht! IMHO gibt es da nicht die Problematik mit vielen kleinen Dateien (ausgehende INodes!). Aber Du kannst da ja mal in die entsprechenden Man-Pages schauen, ob Du da irgendwelche Optionen findest. Ich würde auch bei der "alten" Version bleiben, also nix mit grossen Dateien über 2GB! (Ich hatte mit der 3.5 nie Probleme trotz heftiger behandlung des Laptops!) Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53
Hallo, * On Mon, Feb 25, 2002 at 11:36 AM (+0200), Konrad Neitzel wrote:
Ich denke nicht! IMHO gibt es da nicht die Problematik mit vielen kleinen Dateien (ausgehende INodes!).
Ok, an die dachte ich nämlich bei meiner Nachfrage.
Aber Du kannst da ja mal in die entsprechenden Man-Pages schauen, ob Du da irgendwelche Optionen findest.
Werde ich tun.
Ich würde auch bei der "alten" Version bleiben, also nix mit grossen Dateien über 2GB!
Ja, so große Files sollte der SQUID nicht anlegen... ;-) Gruß, Steffen
Steffen Moser wrote:
Hallo,
* On Mon, Feb 25, 2002 at 10:17 AM (+0200), Konrad Neitzel wrote:
Ich würde sagen, dass ReiserFS die richtige Wahl ist, weil: - es schnell ist (Das ist bei dem Squid wohl recht wichtig und das ist etwas, dass total gegen ext3 spricht (ext3 ist ext2 + irgendwas, das auch Zeit kostet!)
Das ist natürlich einleuchtend - da werde ich dann für die SQUID-Cache- Partition auf "ReiserFS" setzen.
Das klingt immer so, also ob ext3 gegenüber Reiser sooo langsam ist - kann ich nicht nachvollziehen! Beide FS haben Vor- und Nachteile, die hier und anderswo (ich erinnere mich an einen Artikel in einem der letzten Linux-Magazine) schon häufig diskutiert wurden. Von daher würde ich eher zu einem kleinen, auf die lokalen Bedinnungen abgestimmten Test raten, und mal etwas Benchmarking betreiben (wobei die Ergebnisse dann aber eben NICHT übertragbar auf andere Systeme sind!). Ich habe, auch auf Squid-Proxys, gute Erfahrungen mit ext3 gemacht und würde es von daher nicht pauschal ausschließen. Gruß hebi -- Dirk Hebenstreit Tel : +49-0170-2461522 Eschenweg 3 +49-033200-85997 14558 Bergholz-Rehbruecke Dirk.Hebenstreit@epost.de PingoS - LINUX-User helfen Schulen: http://www.pingos.schulnetz.org
Am Mon, 2002-02-25 um 14.24 schrieb Dirk Hebenstreit:
Steffen Moser wrote:
Hallo,
* On Mon, Feb 25, 2002 at 10:17 AM (+0200), Konrad Neitzel wrote:
Ich würde sagen, dass ReiserFS die richtige Wahl ist, weil: - es schnell ist (Das ist bei dem Squid wohl recht wichtig und das ist etwas, dass total gegen ext3 spricht (ext3 ist ext2 + irgendwas, das auch Zeit kostet!)
Das ist natürlich einleuchtend - da werde ich dann für die SQUID-Cache- Partition auf "ReiserFS" setzen.
Das klingt immer so, also ob ext3 gegenüber Reiser sooo langsam ist - kann ich nicht nachvollziehen!
Kann man auch so pauschal nicht sagen. Tatsache ist, das reiserfs mit sehr vielen kleinen Dateien viel schneller ist. Wir hatten als Installationspartition für unser Backupsystem (ARKEIA) ursprünglich ext2 genommen. Anfangs lief die Datensicherung in 14-15 Stunden durch. Irgendwann wurde sie immer langsamer, lief bis zu 30 Stunden, bei fast gleicher Datenmenge, Ursache zu erst unbekannt. Wärend der Fehlersuche wurde das komplette Backupsystem auf eine andere ext2 Partition umkopiert, ohne Erfolg. danach wurde auf die ursprüngliche Partition reiserfs aufgespielt und die daten wieder zurückkopiert. Und siehe da, die Datensicherung lief wieder mit 15-16 Stunden. Die Datenbank bei ARKEIA besteht aus einem Unterverzeichnis mit bei uns weit über einer Million fast leeren Dateien, die sich in weiteren Unterverzeichnissen befinden. Bei solchen Geschichten scheint sich ext2 nicht so wohl zu fühlen.
Beide FS haben Vor- und Nachteile, die hier und anderswo (ich erinnere
Genau so ist es. Mit NGS zusammen würde ich es z.B. nicht mehr einsetzen, da ist mein Dateisystem der Wahl bis jetzt XFS. Läuft wirklich gut bis jetzt.
mich an einen Artikel in einem der letzten Linux-Magazine) schon häufig diskutiert wurden. Von daher würde ich eher zu einem kleinen, auf die lokalen Bedinnungen abgestimmten Test raten, und mal etwas Benchmarking betreiben (wobei die Ergebnisse dann aber eben NICHT übertragbar auf andere Systeme sind!).
Ich habe, auch auf Squid-Proxys, gute Erfahrungen mit ext3 gemacht und würde es von daher nicht pauschal ausschließen.
Da werde ich reiserfs als nächstes einsetzen, so wie es aussieht. -- mfg Peter Küchler, Planungsverband Frankfurt Region Rhein Main
Am Die, 2002-02-26 um 09.11 schrieb Peter Kuechler:
Am Mon, 2002-02-25 um 14.24 schrieb Dirk Hebenstreit:
Steffen Moser wrote:
Hallo,
* On Mon, Feb 25, 2002 at 10:17 AM (+0200), Konrad Neitzel wrote:
Ich würde sagen, dass ReiserFS die richtige Wahl ist, weil: - es schnell ist (Das ist bei dem Squid wohl recht wichtig und das ist etwas, dass total gegen ext3 spricht (ext3 ist ext2 + irgendwas, das auch Zeit kostet!)
Das ist natürlich einleuchtend - da werde ich dann für die SQUID-Cache- Partition auf "ReiserFS" setzen.
Das klingt immer so, also ob ext3 gegenüber Reiser sooo langsam ist - kann ich nicht nachvollziehen!
Kann man auch so pauschal nicht sagen. Tatsache ist, das reiserfs mit sehr vielen kleinen Dateien viel schneller ist. Im Vergleich zu ext2! Wie sieht der Vergleich zu ext3 aus?
Wir hatten als Installationspartition für unser Backupsystem (ARKEIA) ursprünglich ext2 genommen. Anfangs lief die Datensicherung in 14-15 Stunden durch. Irgendwann wurde sie immer langsamer, lief bis zu 30 Stunden, bei fast gleicher Datenmenge, Ursache zu erst unbekannt. Vgl. /usr/src/linux/Documentation/filesystems/ext2.txt (Abschnitt Limitations).
Wärend der Fehlersuche wurde das komplette Backupsystem auf eine andere ext2 Partition umkopiert, ohne Erfolg. danach wurde auf die ursprüngliche Partition reiserfs aufgespielt und die daten wieder zurückkopiert. Und siehe da, die Datensicherung lief wieder mit 15-16 Stunden. Nun wäre es interessant zu wissen, welche Zahl bei ext3 herauskommt. Ich vermute mal, dass sie in der gleichen Grössenordnung liegt, da der beschränkende Faktor mit ext3/reiserfs wohl eher an anderer Stelle zu suchen ist als im Filesystem (Bus, Netzwerk, IO-Performance des Backup-Devices).
Die Datenbank bei ARKEIA besteht aus einem Unterverzeichnis mit bei uns weit über einer Million fast leeren Dateien, die sich in weiteren Unterverzeichnissen befinden. Bei solchen Geschichten scheint sich ext2 nicht so wohl zu fühlen. Eben, siehe ext2.txt
Ralf
Am Die, 2002-02-26 um 11.06 schrieb Ralf Corsepius:
Am Die, 2002-02-26 um 09.11 schrieb Peter Kuechler:
Am Mon, 2002-02-25 um 14.24 schrieb Dirk Hebenstreit:
Steffen Moser wrote:
Hallo,
* On Mon, Feb 25, 2002 at 10:17 AM (+0200), Konrad Neitzel wrote:
Ich würde sagen, dass ReiserFS die richtige Wahl ist, weil: - es schnell ist (Das ist bei dem Squid wohl recht wichtig und das ist etwas, dass total gegen ext3 spricht (ext3 ist ext2 + irgendwas, das auch Zeit kostet!)
Das ist natürlich einleuchtend - da werde ich dann für die SQUID-Cache- Partition auf "ReiserFS" setzen.
Das klingt immer so, also ob ext3 gegenüber Reiser sooo langsam ist - kann ich nicht nachvollziehen!
Kann man auch so pauschal nicht sagen. Tatsache ist, das reiserfs mit sehr vielen kleinen Dateien viel schneller ist. Im Vergleich zu ext2! Wie sieht der Vergleich zu ext3 aus?
Wir hatten als Installationspartition für unser Backupsystem (ARKEIA) ursprünglich ext2 genommen. Anfangs lief die Datensicherung in 14-15 Stunden durch. Irgendwann wurde sie immer langsamer, lief bis zu 30 Stunden, bei fast gleicher Datenmenge, Ursache zu erst unbekannt. Vgl. /usr/src/linux/Documentation/filesystems/ext2.txt (Abschnitt Kann ich leider nicht sagen, wurde nicht getestet. das hatte aber einen Grund:-) (s.u.)
Wir hatten als Installationspartition für unser Backupsystem (ARKEIA) ursprünglich ext2 genommen. Anfangs lief die Datensicherung in 14-15 Stunden durch. Irgendwann wurde sie immer langsamer, lief bis zu 30 Stunden, bei fast gleicher Datenmenge, Ursache zu erst unbekannt. Vgl. /usr/src/linux/Documentation/filesystems/ext2.txt (Abschnitt Limitations).
Stimmt, da steht tatsächlich sowas;-)
Wärend der Fehlersuche wurde das komplette Backupsystem auf eine andere ext2 Partition umkopiert, ohne Erfolg. danach wurde auf die ursprüngliche Partition reiserfs aufgespielt und die daten wieder zurückkopiert. Und siehe da, die Datensicherung lief wieder mit 15-16 Stunden. Nun wäre es interessant zu wissen, welche Zahl bei ext3 herauskommt. Ich
Das glaube ich nicht. Laut Doku die ich irgendwann mal gelesen habe bleibt die Technik von ext2 unangetastet. ext3 ist lediglich eine Erweiterung. Zumindest im Moment kann ich da keinen Grund für eine Beschleunigung sehen. Der Geschwinigkeitsvorteil von reiserfs bei kleinen Dateien besteht ja scheinbar darin, das die geringen Datenmengen in den Verwaltungsstrukturen mit gespeichert wird.
vermute mal, dass sie in der gleichen Grössenordnung liegt, da der beschränkende Faktor mit ext3/reiserfs wohl eher an anderer Stelle zu suchen ist als im Filesystem (Bus, Netzwerk, IO-Performance des Backup-Devices).
In diesem Fall mit Sicherheit nicht, die Verlangsamung kam tatsächlich durch das Dateisystem. -- mfg Peter Küchler, Planungsverband Frankfurt Region Rhein Main
Hallo, On Mon, 25 Feb 2002, Steffen Moser wrote:
Muss ich beim Erstellen des "ReiserFS" noch irgend etwas beachten, um es auf den Verwendungszweck hin zu optimieren, d.h. muss ich irgendwelche Optionen beim Erzeugen verwenden (vermutlich nicht, aber ich habe noch nicht viel mit "ReiserFS" gemacht)?
Ja. Die unterschiedlichen Hashes, die bei reiserfs verwendet werden koennen haben doch relativ unterschiedliche Verhalten... (siehe /usr/src/linux/fs/reiserfs/hashes.c)... Das kommt aber natuerlich auch sehr auf den verwendeten Kernel/reiserfs-Version an. AFAIR ist tea_hash recht robust, aber relativ langsam, r5_hash ein recht guter Kompromiss (ist seit der Integration in den Kernel mit 2.4.1 AFAIR der Default, bei 2.2.x war's noch tea_hash), und dann gibt's noch yura_hash... Und ein paar Freaks haben dann noch eigene hashes eingebaut (die z.B. sehr schnell sind, aber dafuer viele "Kollisionen" produzieren)... Leider findet sich AFAIR keine Doku zu dem Thema, ausser auf der reiserfs-Mailingliste... (ist aber immerhin durchsuchbar archiviert siehe http://www.reiserfs.org). Zur Not kann ich in den (alten) Teilen der ML graben, in denen ich was zu diesem Thema gelesen habe. IIRC war das Subject "New hash" oder so aehnlich... (google.com mit einschraenkung auf reiserfs.org koennte ebenfalls helfen). -dnh, seit 2.2.12 (oder .10 oder .14) nur gute Erfahrungen mit reiserfs 3.5 gemacht habend (davon am laengsten mit 2.4.0-test4, inzwischen Kernel 2.4.16 (vanilla, natuerlich). Nur neulich als eine HD Sektoren verlor wurden diese nicht als defekt markiert (oder so). Einen Datenverlust gab's aber (dank journal) nicht, die HD hat aber uebel "rumgejault" wenn ich die Dateien lesen wollte ("*schniiiirkss* - *schniiiirkss* - *schniiiirkss* - *schniiirklaack*", dann gab's ne Meldung im syslog und das gleiche Spiel mit dem naechsten defekten Sektor... die HD hat seitdem aber keine weiteren Sektoren verloren, glaube ich, die betroffene Partition verwende ich allerdings nicht mehr -- war zum Glueck sowieso nur /var ;). Allerdings setze ich weder NFS noch Quota ein. Achso, '/' und '/home' waren und sind und bleiben ext2 (/home schon allein wg. der Moeglichkeit zur Not Dateien zu "entloeschen" ;) PS: Nein, ich denke weder reiserfs, noch ext3 noch XFS (auf Linux!) noch JFS noch ... sind "stabil". Wichtiges wuerde ich auf ext2 Partitionen (wenn moeglich read-only, dann ist auch der fsck im Falle eines Falles kein Thema) lassen. Caches usw., die ggfs. auch mal hops gehen duerfen, wo ein schneller fsck wichtiger ist, als die Datensicherheit (also eben ein Squid-cache, je nach Anwendung ein Newsspool, ne htdig/glimpse DB etc. pp.) sind reiserfs/ext3 praedestitinert... Hm... Eingentlich eine 3stufige Strategie: /, /etc, /usr, /usr/local usw: ext2, read-only (->fsck-Dauer ist irrelevant) /var (u.ae.): ext3/reiserfs, read-write, "kann auch mal hops gehen" /home: ext2, rw, staendiges backup, fsck-Dauer wird "in Kauf" genommen, evtl. aber ext3... -- ... just what are we going to say to an alien race if we make contact? "Do you have Napster?" "Can we borrow one of your rainforests?" "Stop making crop circles!" -- Scott Barber, in rasfw
* Konrad Neitzel schrieb am 25.02.02 um 09:17 Uhr:
Steffen Moser
schrieb: Mich würde nun natürlich interessieren, wo genau die Vorteile von "ReiserFS" für Caching-Proxy-Partitionen liegen? Ist das "ReiserFS" für die Proxy-typischen Zugriffe entsprechend optimiert?
Ich würde sagen, dass ReiserFS die richtige Wahl ist, weil: - es schnell ist (Das ist bei dem Squid wohl recht wichtig und das ist etwas, dass total gegen ext3 spricht (ext3 ist ext2 + irgendwas, das auch Zeit kostet!)
ACK. ReiserFS ist gerade bei vielen kleinen Dateien turboschnell. Es gibt sogar irgendwo einen Squid-Patch, mit dem dann der Squid direkt auf die Reiser-Interna zugreifen kann --> noch mehr Speed. Ich weiss auch nicht, was gegen das neuere und aktuellere 3.6er Format von ReiserFS sprechen soll. 3.5 ist im prinzip alt und wird nicht mehr weiterentwickelt (AFAIK). Ext3 hat auch seine Vorteile: - Ich kann einfach von ext2 migrieren, da selbes ondisk-Format wie ext2. Man kann sogar ein ext3 später wieder als ext2 mounten... - Ich kann badblocks "ausklammern" - Externes journal (soll bei Reiser IIRC in Version 4 kommen) - ... Gruss -Marc -- +-O . . . o . . . O . . . o . . . O . . . ___ . . . O . . . o .-+ | Ein neuer Service von Links2Linux.de: / o\ RPMs for SuSE | | --> PackMan! <-- naeheres unter | __| and others | | http://packman.links2linux.de/ . . . O \__\ . . . O . . . O . |
Marc Schiffbauer
* Konrad Neitzel schrieb am 25.02.02 um 09:17 Uhr:
Ich würde sagen, dass ReiserFS die richtige Wahl ist, weil: - es schnell ist (Das ist bei dem Squid wohl recht wichtig und das ist etwas, dass total gegen ext3 spricht (ext3 ist ext2 + irgendwas, das auch Zeit kostet!)
ACK. ReiserFS ist gerade bei vielen kleinen Dateien turboschnell. Es gibt sogar irgendwo einen Squid-Patch, mit dem dann der Squid direkt auf die Reiser-Interna zugreifen kann --> noch mehr Speed.
Hmmm - wie stabil ist das? Ich selbst bin eigentlich gegen solche "Pfuscherei".
Ich weiss auch nicht, was gegen das neuere und aktuellere 3.6er Format von ReiserFS sprechen soll. 3.5 ist im prinzip alt und wird nicht mehr weiterentwickelt (AFAIK).
Das ist klar! Immer nur die aktuelle Version wird weiter entwickelt, aber da man ja vereinzelnt etwas von problemen hört, habe ich bei mir weiterhin 3.5 drauf. War ja auch der Standard bei der SuSE Installation. Und wie gesagt: Ich habe es bei mir noch nicht kaputt gekriegt! Einzelne Dateien schon - klar! Aber das Filesystem selbst noch nie! Und ich gönne mir den "Luxus", meinen Laptop mal eben so auszuschalten. Ist halt eine Form der Stabilitätsprüfung von meiner Seite aus!
Ext3 hat auch seine Vorteile: - Ich kann einfach von ext2 migrieren, da selbes ondisk-Format wie ext2. Man kann sogar ein ext3 später wieder als ext2 mounten... - Ich kann badblocks "ausklammern" - Externes journal (soll bei Reiser IIRC in Version 4 kommen)
ja - das sind sehr gute Punkte. Aber bei einem reinen Spool Verzeichnis ist das mit dem ext2 <> ext3 nicht so wild, da ich mal eben so die Filesysteme neu bauen kann! Badblocks ausklammern: Wenn neue Bad Blocks auftreten, dann ist das in meinen Augen ein Zeichen für eine Platte, die den Geist aufgibt. Und die bei der Produktion vorhandenen "Ungereimtheiten" sind ja im "Low Level Format" ausgeklammert. Und wenn ich die Platte unbedingt weiter nehmen will, dann kann ich ehh eine neue Low-Level-Formatierung durchführen. Externes Journal ist Gold wert! Denn sonst muss er immer mindestens drei Schreibvorgänge mit einem Umpositionieren des Kopfes tätigen! (Eintrag Journal, dass er Ändern will, Änderung, Eintrag Journal Änderung ok!) Zwei Platten bringen hier deutliche Performance-Verbesserung (zumindest nach meinem Verständnis, denn ich habe es noch nicht austesten können!). Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53
Am Mon, 2002-02-25 um 18.46 schrieb Konrad Neitzel:
Marc Schiffbauer
schrieb: * Konrad Neitzel schrieb am 25.02.02 um 09:17 Uhr:
Ich würde sagen, dass ReiserFS die richtige Wahl ist, weil: - es schnell ist (Das ist bei dem Squid wohl recht wichtig und das ist etwas, dass total gegen ext3 spricht (ext3 ist ext2 + irgendwas, das auch Zeit kostet!)
Ich weiss auch nicht, was gegen das neuere und aktuellere 3.6er Format von ReiserFS sprechen soll. 3.5 ist im prinzip alt und wird nicht mehr weiterentwickelt (AFAIK).
Das ist klar! Immer nur die aktuelle Version wird weiter entwickelt, aber da man ja vereinzelnt etwas von problemen hört, habe ich bei mir weiterhin 3.5 drauf. War ja auch der Standard bei der SuSE Installation.
Und wie gesagt: Ich habe es bei mir noch nicht kaputt gekriegt! Hmm, scheint mir ganz zu sein: Zerstöre den Anfang einer ReiserFS-Partition.
Um Linux-2.4.7-2.4.10 herum gab es einen allgemeinen (von ReiserFS unabhängig) Kernelbug, der dazu geführt hat, dass in bestimmten Konfigurationen (Plattenpartionierung) der Anfang von Partitionen nicht richtig erkannt wurde. Während es ext3 gelang, in diesen Fällen seine Daten zu restaurieren, hatte ReiserFS Probleme damit (Ich vermute, dass ReiserFS genau dort das Journal liegen hat, während Ext3 mittels e2fsck/ext2-Methoden seine Daten restaurieren kann).
Einzelne Dateien schon - klar! Aber das Filesystem selbst noch nie! Nun ja, ich fast (Heisst: nach ReiserFS-Problemen waren nicht nur einzelne wenige Dateien verloren)
Hauptgrund waren aber nicht das obige Problem, sondern Probleme im Zusammenspiel zwischen ReiserFS und knfs sowie cvs mit Linux-2.4.0-2.4.10. Ob es sich seither nachhaltig gebessert hat, kann ich nicht beurteilen, da ich jetzt komplett auf ext3 umgestellt habe und seither keinerlei FS-bezogene Probleme mehr habe :)
Und ich gönne mir den "Luxus", meinen Laptop mal eben so auszuschalten. Ist halt eine Form der Stabilitätsprüfung von meiner Seite aus!
Ich gehe mal davon aus, dass Du Backups hast:) [Pst, nicht weitersagen, mache ich auf meinen Notebook mit ext3 auch nicht anders ;)}
Ext3 hat auch seine Vorteile: - Ich kann einfach von ext2 migrieren, da selbes ondisk-Format wie ext2. Man kann sogar ein ext3 später wieder als ext2 mounten... - Ich kann badblocks "ausklammern" - Externes journal (soll bei Reiser IIRC in Version 4 kommen)
+ Variable Block-Grössen (IIRC, kann ReiserFS nur 4k-Blöcke) + ext2 als Fallback im Fehlerfall (dump, e2fsck)
ja - das sind sehr gute Punkte. Aber bei einem reinen Spool Verzeichnis ist das mit dem ext2 <> ext3 nicht so wild, da ich mal eben so die Filesysteme neu bauen kann! Aber nur, wenn das spool-Verzeichnis auf einer eigenen Partition liegt. Wird in professioneller Umgebung meist der Fall sein, in Home-Netzen wohl aber nur selten.
Ralf
* Ralf Corsepius schrieb am 26.02.02 um 06:22 Uhr:
Am Mon, 2002-02-25 um 18.46 schrieb Konrad Neitzel:
Marc Schiffbauer
schrieb: Ext3 hat auch seine Vorteile: - Ich kann einfach von ext2 migrieren, da selbes ondisk-Format wie ext2. Man kann sogar ein ext3 später wieder als ext2 mounten... - Ich kann badblocks "ausklammern" - Externes journal (soll bei Reiser IIRC in Version 4 kommen)
+ Variable Block-Grössen (IIRC, kann ReiserFS nur 4k-Blöcke)
IIRC war es bei Reiser doch so, dass der das ganz anders macht... Reiser füllt "Reste" in einem Block, die nicht belegt wurden, mit anderen dateien wieder auf, Sprich: Hier fällt dieses Blockgrössenproblem sogar weg (IIRC)
+ ext2 als Fallback im Fehlerfall (dump, e2fsck)
ACK. Aber das hatte ich ja schon so ähnlich geschrieben ;) Gruss -Marc -- +------------------------------------------------------------------+ | --> http://www.links2linux.de <-- Jetzt mit neuen Features! | | wie z.B. [EasyLink] | +---Registered-Linux-User-#136487------------http://counter.li.org +
participants (10)
-
David Haller
-
Dirk Hebenstreit
-
Jürgen Fahnenschreiber
-
Konrad Neitzel
-
Marc Schiffbauer
-
Peter Kuechler
-
Ralf Corsepius
-
Stefan Eggert
-
Steffen Moser
-
Thorsten Haude