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