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