Ich hatte Reiser3FS in der stabilen Version 3.6 letztmals vor einer gefühlten Ewigkeit unter Suse 9.0 benutzt, und ich kann mich nicht erinnern, dass bei den wenigen unbeabsichtigten Resets Suse 9.0 nicht wieder "hochgekommen" wäre.
Reiserfs habe ich hingegen heute noch auf einer uralten Suse 7.3-Partition manchmal im Einsatz, allerdings in der älteren Version 3.5. Die Pio4-2GB-Festplatte des alten 200MHz-PentiumI-Notebooks hat sich darüber bis heute nicht bei mir beschwert.
Neben Suse hat vor allem Slackware sehr lange auf Reiser3FS als Standarddateisystem vertraut. So instabil kann es also gar nicht sein und gerade zu Kernel 2.4-Zeiten war Reiser3FS eine valide und meist bessere Alternative zu Ext3, da der Hauptanwendungsfall von Reiserfs (beste Performance bei der Anwesenheit sehr vieler und kleiner Dateien auf einem Single-Core-Prozessor-System) damals auf fast jedem Privatrechner vorzufinden war.
Heutzutage dürfte Reiser3FS kaum noch eingesetzt werden. Ext3 ist hierbei für konservative Privatnutzer ein gutes Allround-Filesystem mit solider, stabiler und durchschnittlicher Leistung für alle Anwendungsbereiche. Ansonsten wird mittlerweile wohl überwiegend Ext4 auf Privat-Desktops im Einsatz sein, einfach deshalb, weil die meisten Distros standardmäßig bei der Installation Ext4-Dateisysteme einrichten.
Die Diskussion um ReiserFS ist IMO eher eine historische Diskussion um Reiser3FS, Reiser4FS hat aufgrund seiner wohl dauerhaften In-Kernel-Abstinenz wohl keine Chance und auch keine Bedeutung mehr.
Heute abzustreiten, dass es nach der Einführung von ReiserFS bei Suse zu zahlreichen Problemen gekommen war wirkt schon lächerlich. Aber ich vergönne natürlich auch dir den Schlaf der Gerechten.
Ich werde mich jedenfalls nicht mehr durch Performancevorteile zum Einsatz eines viel zu frischen Dateisystems überreden lassen, diesen Fehler begehe ich nur einmal in meinem Leben. Auch war der Performancevorteil von ReiserFS zum Großteil durch hohe CPU-Auslastung erkauft.
Auch war der Performancevorteil von ReiserFS zum Großteil durch hohe CPU-Auslastung erkauft.
Bei dir klingt dies als wäre es etwas negatives. In den Zeiten als E/A ein noch viel größerer Flaschenhals war als heute, kann das eigentlich nur ein Vorteil sein.
Dummerweise war damals auch CPU-Leistung sehr dünn gesät und es war die Zeit der Single-Cores. Deshalb war es schon wichtig zu wissen, wodurch man sich das etwas schnellere I/O erkauft hat.
Nur wer alle Fakten kennt kann für den jeweiligen Einsatzzweck die Vor- und Nachteile gegeneinander aufwiegen.
Hohe CPU-Auslastung? Zu Suse 6.4-Zeiten funktionierte ja noch nicht einmal IDE-DMA vernünftig. Da rauschten die Daten noch im Pio4-Modus durch die IDE-Kanäle, allein schon das war Schwerstarbeit für die CPU.
Das war vom Chipsatz abhängig. Wer schon lange genug dabei war und sein System auf Linux anstelle von Windows ausgerichtet hatte, konnte auch von DMA profitieren.
"Der Sinn und Zweck von ReiserFS hat sich mir nie wirklich erschlossen ...."
Reiser3FS z.B. ist die beste Wahl im Hinblick auf ein Dateisystem mit vielen kleinen Dateien auf einem Single-Prozessor-System.
Mit Single-Prozessor-System meinte ich einen Prozessor mit einem Kern, also keinen Multicore-Chip.
Und die Beste Wahl, wenn man auf Datenverlust bei Systemabstürzen wert legt.
Ich hatte Reiser3FS in der stabilen Version 3.6 letztmals vor einer gefühlten Ewigkeit unter Suse 9.0 benutzt, und ich kann mich nicht erinnern, dass bei den wenigen unbeabsichtigten Resets Suse 9.0 nicht wieder "hochgekommen" wäre.
Reiserfs habe ich hingegen heute noch auf einer uralten Suse 7.3-Partition manchmal im Einsatz, allerdings in der älteren Version 3.5. Die Pio4-2GB-Festplatte des alten 200MHz-PentiumI-Notebooks hat sich darüber bis heute nicht bei mir beschwert.
Neben Suse hat vor allem Slackware sehr lange auf Reiser3FS als Standarddateisystem vertraut. So instabil kann es also gar nicht sein und gerade zu Kernel 2.4-Zeiten war Reiser3FS eine valide und meist bessere Alternative zu Ext3, da der Hauptanwendungsfall von Reiserfs (beste Performance bei der Anwesenheit sehr vieler und kleiner Dateien auf einem Single-Core-Prozessor-System) damals auf fast jedem Privatrechner vorzufinden war.
Heutzutage dürfte Reiser3FS kaum noch eingesetzt werden. Ext3 ist hierbei für konservative Privatnutzer ein gutes Allround-Filesystem mit solider, stabiler und durchschnittlicher Leistung für alle Anwendungsbereiche. Ansonsten wird mittlerweile wohl überwiegend Ext4 auf Privat-Desktops im Einsatz sein, einfach deshalb, weil die meisten Distros standardmäßig bei der Installation Ext4-Dateisysteme einrichten.
Die Diskussion um ReiserFS ist IMO eher eine historische Diskussion um Reiser3FS, Reiser4FS hat aufgrund seiner wohl dauerhaften In-Kernel-Abstinenz wohl keine Chance und auch keine Bedeutung mehr.
Heute abzustreiten, dass es nach der Einführung von ReiserFS bei Suse zu zahlreichen Problemen gekommen war wirkt schon lächerlich. Aber ich vergönne natürlich auch dir den Schlaf der Gerechten.
Ich werde mich jedenfalls nicht mehr durch Performancevorteile zum Einsatz eines viel zu frischen Dateisystems überreden lassen, diesen Fehler begehe ich nur einmal in meinem Leben. Auch war der Performancevorteil von ReiserFS zum Großteil durch hohe CPU-Auslastung erkauft.
Dummerweise war damals auch CPU-Leistung sehr dünn gesät und es war die Zeit der Single-Cores. Deshalb war es schon wichtig zu wissen, wodurch man sich das etwas schnellere I/O erkauft hat.
Nur wer alle Fakten kennt kann für den jeweiligen Einsatzzweck die Vor- und Nachteile gegeneinander aufwiegen.
Hohe CPU-Auslastung? Zu Suse 6.4-Zeiten funktionierte ja noch nicht einmal IDE-DMA vernünftig. Da rauschten die Daten noch im Pio4-Modus durch die IDE-Kanäle, allein schon das war Schwerstarbeit für die CPU.
Das war vom Chipsatz abhängig. Wer schon lange genug dabei war und sein System auf Linux anstelle von Windows ausgerichtet hatte, konnte auch von DMA profitieren.