Auch wenn sich der Erfinder als Verbrecher herausgestellt hat so war reiserfs eine wirklich gute Sache die ich damals um einiges lieber einsetzte als ext3. Und vermutlich wäre auch reiser4 ein gutes Dateisystem aber deswegen jeden Kernel zu patchen ist mir zu umständlich.
Wirklich schade das wegen sowas ein gutes Produkt von der Bildfläche verschwindet.
> Auch wenn sich der Erfinder als Verbrecher herausgestellt hat so war reiserfs eine wirklich gute Sache
Das eine hat mit dem anderen ja auch nichts zu tun. (Auch wenn Adolf Hitler der Erfinder wäre ... ) Ja, Reiser 3 habe ich auch sehr gern genutzt.
> Wirklich schade das wegen sowas ein gutes Produkt von der Bildfläche verschwindet.
Das ist ein großes Problem in der OS-Gemeinde: Viele Projekte sind One man shows oder haben zumindest einen unverzichtbaren Hauptentwickler. Etwas mehr Kooperationsfähigkeit wäre schon ein Segen.
Mit dem letzten Absatz vereinfachst du die lange Problemreihe, die schon lange vor der Gefängnisstrafe mit ReiserFS verbunden war. Zumindest wenn du andeuten willst, das andere nicht mit an ReiserFS arbeiten wollen (NIH und ähnliches).
Reine Zeitverschwendung, die Entwickler sollten sich lieber den BTRFS-Leuten anschließen .... Dann wird wenigstens für die Zukunft und nicht für die Tonne entwickwelt.
Von Varpor-BTRFS am Fr, 15. August 2014 um 16:40 #
Nur wird das nie fertig werden. BTRFS ist das Duke Nukem Forever unter den Dateisystemen, ewig im Alphastatus, da war selbst Reiser4 näher an der Produktiveinsatztauglichkeit als es BTRFS jemals sein wird. Wer darauf wartet wartet auf den Tod.
Ist BTRFS nicht sogar in machen Linux Distros schon Standard bei der Installation? Glaibe bei openSuse ist dies der Fall und Ubuntu hatte auch mal drüber nachgedacht BTRFS zum Stnadart zu machen. Laut Wiki befindet sich BTRGS im Beta Status.
Allgemeine Frage @all Worin liegen die Unterschiede zwischen BTRFS, ext4 und Reiser 4 und welches ist das schnellste Dateisystem im lesen, schreiben und öffnen von Dateien nach jetzigen aktuellen Stand
Suse wird BTRFS radikal in seine Distribution hineindrücken. Suse hat Ähnliches schon einmal mit ReiserFS in Suse 6.4 unternommen. BTRFS wird SLES- und openSUSE-Standard, koste es, was es wolle. Ext4 hat im SLES-Bereich bis heute kurioserweise keinerlei Bedeutung.
Weil die Suse-Nutzer damals mit ReiserFS schon zahlreich auf die Nase gefallen sind (ich spreche aus eigener Erfahrung). Aber dazulernen ist hald nicht jedermanns Sache.
Wenn du damals die ReiserFS-Probleme im Suse-Umfeld nicht mitbekommen hast (die berühmten mit 0-Byte-Einträgen gefüllten Dateien), dann muss dich wohl der Schlaf der Gerechten übermannt haben.
Ich hab davon gelesen, aber als SuSE und ReiserFS-Nutzer selber nichts davon mitbekommen.
Wenn man bei allen Bugs, die großartig irgendwo auftreten, gleich das Produkt meiden will, kann man wohl gar nichts mehr benutzen.
Bei ZFS, wohl eines der besten Dateisysteme heutzutage, konnte man schon Dinge erleben... und ext2/3/4, xfs und ntfs bekleckern sich da wohl auch nicht gerade mit Ruhm...
Von Ralph Miguel Fröhlich am Mi, 20. August 2014 um 13:48 #
Klar, "irgendwas ist immer". Ich habe dem reiserfs auf SuSE 6.4(?) den Systemtod durch Datenkorruption nicht weiter verübelt, das war ja noch Beta. Bugreport und gut ist. Aber ein paar Jahre später hat sich das Gespann Slackware/reiserfs auf meinem damals nicht gar so alten TP600 reproduzierbar ähnlich verhalten. Mir persönlich reicht das.
Nachdem es bei mir auf unterschiedlichen Systemen damals alle ReiserFS-Dateisysteme über kurz oder lang erwischt hatte, kann ich mir nur schwerlich vorstellen, dass es überhaupt Nutzer gab, die damals nicht betroffen waren.
Was es aber sicher zahlreich gab waren Nutzer, die es nicht bemerkt hatten. Selbst wenn beispielsweise eine systemrelevante Datei wie die /etc/passwd betroffen war, was nicht unbemerkt bleiben konnte da sich dadurch niemand mehr am System anmelden konnte, wird nur ein kleiner Teil der Nutzer das Problem überhaupt analysiert haben. Und von dieser Teilmenge wird ebenfalls nur ein kleiner Teil der Nutzer das Problem weiter über einen längeren Zeitraum beobachtet und auf das Filesystem zurückgeführt haben.
Was aber wenn es überhaupt keine systemrelevante Datei erwischt hatte? Die Wahrscheinlichkeit ist sehr groß, schließlich sind die wenigsten Dateien systemrelevant.
Zudem befinden sich auf einem Linuxsystem haufenweise Dateien die für den Betrieb nie benötigt werden. Korrumpieren diese Dateien bekommt es der Nutzer überhaupt nicht mit.
Bei dem einen oder anderen hat dann vielleicht mal eine mp3 nicht mehr gespielt, nur wer analysiert den Inhalt einer mp3 und führt dies durch Beobachtung über einen längeren Zeitraum auf einen Fehler des Dateisystems zurück?
Oder es hat sich z.B. eine Anwendung mal "irgendwie seltsam" verhalten. Auch hier werden die allerwenigsten Nutzer dem Problem tatsächlich auf den Grund gehen.
D.h. die Dunkelziffer an durch ReiserFS verstümmelten Dateien wird immens hoch gewesen sein.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 20. Aug 2014 um 14:03.
Da kann ich nicht viel zu sagen, LVM setze ich nicht ein da es nicht in meinem Interesse ist die Komplexität zusätzlich zu erhöhen und ext4 nutze ich erst seit weniger als 2 Jahren. Ich habe damals mit dem Suse ReiserFS-Debakel meine Lektion auf die harte Tour gelernt und werde kein Filesystem mehr anfassen, welches nicht bereits gut abgehangen ist.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 17. Aug 2014 um 14:12.
Du bist nicht "unter dem ach-so-stabilen Ext4" auf die Nase gefallen, sondern mit LVM. Wenn die LVM-Metadaten einmal beschädigt oder verloren sind, ist es ganz egal, welches Dateisystem du darin eingesetzt hast - die Rekonstruktion ist praktisch unmöglich. Das wissen leider nur die wenigen, die damit schon mal ein Problem hatten.
Und zu Hans Reiser, dem Hannibal Lecter der Dateisysteme, braucht man gar nicht mehr als das zu sagen.
Deine sicher nicht. Denn Reiser3 wurde im Lauf der Jahre verbessert und reiserfsck ebenfalls. Ich weiß noch, dass reiserfsck anfänglich nicht zu gebrauchen war.
Suse hatte ReiserFS bereits für den Produktiveinsatz ausgeliefert als es noch nicht stabil war. Offenbar wiederholen sie nun den selben Schritt mit dem nächsten Dateisystem. Jetzt meinen Spruch bezüglich dazulernen verstanden?
openSUSE ist das Testsystem für SuseEnterpriseLinux....da testet man Sachen - ja, auch auf Kosten der Nutzer, aber die bekommen dafür ein monetär-kostenfreies System.
Ich würde sagen, du hattest keine Backup-Strategie. Denn ich habe vielleicht mal aus Root-Dummheit oder Hardwarecrash (ja, auch ohne Backup) Daten verloren - aber nicht auf Grund eines Dateisystems. Und Suse nutze ich seit ca. 1998
Ich würde sagen, du hattest keine Backup-Strategie.
Du hast keinen blassen Schimmer welche Backupstrategie ich habe, also mach dich doch nicht lächerlich.
Denn ich habe vielleicht mal aus Root-Dummheit oder Hardwarecrash (ja, auch ohne Backup) Daten verloren - aber nicht auf Grund eines Dateisystems.
Na klar und was du nicht kennst das gab es nicht. Manche Leute habe schon ein sehr einfaches Weltbild. Sei froh, wenn du das SuSE-ReiserFS-Debakel nicht mitbekommen hast und schlafe weiter den Schlaf der Gerechten.
Und Suse nutze ich seit ca. 1998
Da du nicht einmal die Geschichte der Suse-Systeme kennst ist das besonders glaubwürdig.
Ich würde sagen, du hattest keine Backup-Strategie.
Nun ja, damals habe auch ich lediglich reine Nutz- und ein paar Konfigurationsdateien gesichert. - Speicher kostete schon ein wenig mehr, als heutzutage.
War schon blöd, wenn Reiser zuschlug.
Und ja, ich kaufte damals regelmäßig die Suse-Box. Ich hatte allerdings irgendwann keine Lust mehr, als reiner Testuser benutzt zu werden. (Das ReiserFS-Debakel war nur ein blödes Ding von vielen.)
Und so sparte ich mir irgendwann den Kauf der Suse-Boxen, wendete mich Debian zu und spende lieber denen regelmäßig.
Das ist doch eine Frage die man so nicht beantworten kann. Das hängt von dem Einsatzzweck, deinen Daten und der Hardware ab.
Und am Ende muss man sich natürlich fragen: Ist Geschwindigkeit alles? Merke ich den Unterschied überhaupt? Oder kommt der wirkliche Unterschied erst dann zum tragen, wenn man ordentlich Daten-Schiffbruch erlitten hat.
Ich schlage hierzu eine einfache Suchmaschinensuche vor.
Diese ergibt u.a. folgende Treffer:
http://www.phoronix.com/scan.php?page=article&item=reiser4_benchmarks&num=1 "Finally, Reiser4 Benchmarks Against EXT4 & Btrfs"
http://www.phoronix.com/scan.php?page=article&item=reiser4_linux35&num=1 "Reiser4 Benchmarked On Linux 3.5 Against EXT4, Btrfs, XFS, ReiserFS"
http://www.phoronix.com/scan.php?page=article&item=linux_310_reiser4&num=1 "Reiser4 File-System Shows Decent Performance On Linux 3.10"
Siehe auch Artikel wie z.B.: http://www.serverfocus.org/reiserfs-vs-ext4-vs-xfs-vs-zfs-vs-btrfs "ReiserFS vs ext4 vs XFS vs ZFS vs Btrfs – Linux filesystems compared"
Btrfs gibt's schon seit Längerem im produktiven Einsatz, einerseits wird's bei viele Linux Distros angeboten (wenn auch nicht als Standard), andererseits benutzt das Jolla Telefon btrfs als Standard.
Es als Vaporware zu bezeichnen ist definitiv Unsinn.
Ich persönlich benutze btrfs seit einiger Zeit produktiv, und muss sagen, dass es mir sehr gefällt. Abgesehen vom praktischen Umgang mit den Subvolumes macht sich die transparente Kompression deutlich bemerkbar, in einem Zuwachs des Throughputs von ca 30%. Der Platzverbrauch ist deutlich geringer, dank der Kompression, und dank des Copy-On-Write kann ich sogar grosse Dateistrukturen kopieren, ohne dass es extra Festplattenplatz kostet -- auf SSDs nicht ganz irrelevant. Dieses Featureset bietet kein anderes, im Vanillakernel verfügbares Dateisystem.
Btrfs gibt's schon seit Längerem im produktiven Einsatz, einerseits wird's bei viele Linux Distros angeboten (wenn auch nicht als Standard), andererseits benutzt das Jolla Telefon btrfs als Standard.
Netgear verwendet auch in den ReadyNAS btrfs als Standard. Machen sicher auch andere NAS Anbieter.
Zumindest fragt man sich, wozu man das brauchen soll.
Geht es darum ein stabiles und sicheres Dateisystem zu verwenden, dann gibt es andere Kandidaten (i.e. ext3, evtl. auch ext4). Features wie btrfs bietet reiser4 auch nicht, wobei btrfs ja wie erwähnt noch nicht vollständig ist, geschweige denn stabil.
Eigentlich gab es für reiser4 doch immer nur ein Argument (zumindest soweit ich mich erinnern kann): Performance Wenn man darauf Wert legt, dann gibt es heute effektivere Methoden, wie Raid0, SSD oder einfach verdammt viel RAM. Jedenfalls sehe ich wirklich nicht, wozu man reiser4 heute brauchen sollte.
Von Bleu_de_Gance am Sa, 16. August 2014 um 12:17 #
Hach ja, was habe ich innerlich gefeiert als bekanntgegeben wurde dass XFS bei RedHat wieder Standard-FS wird ... Das gute alte XFS, ein wenig betagt vielleicht aber bisher in Sachen Stabilität immer noch erste Klasse. Der Sinn und Zweck von ReiserFS hat sich mir nie wirklich erschlossen ....
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.
Ja, zB zuletzt im Nov. 2013. Werde zu Neukunden gerufen, die ihren Server lt. eigenem Bekunden jahrelang problemlos ohne USV betrieben haben (und einen ungeplanten Stromausfall hatten).
Beim Booten bzw. bei xfs_repair schrieb er für die Datenpartition:
bad primary superblock - bad magic number !!! attempting to find secondary superblock............................................................. Sorry, could not find valid secondary superblock Exiting now.
Zum Glück hatten sie immer aufs Backup geachtet, sodass die Sache mit Neuformatieren der Partition, Wiedereinspielen des Backups und einer neuen USV davor erledigt war.
Die anderen Partitionen (ext4) waren übrigens nach einem fsck wieder einsatzbereit.
Warum benutzt man so einen Krampf? Ich habe xfs mal vor Jahren probiert. Wenn das immer noch so ist, dann ist das "Zerschiessen" wahrscheinlich konzeptbedingt. Bei einem Journaling Filesystem darf es jedenfalls nicht passieren!!!
Auch wenn sich der Erfinder als Verbrecher herausgestellt hat so war reiserfs eine wirklich gute Sache die ich damals um einiges lieber einsetzte als ext3. Und vermutlich wäre auch reiser4 ein gutes Dateisystem aber deswegen jeden Kernel zu patchen ist mir zu umständlich.
Wirklich schade das wegen sowas ein gutes Produkt von der Bildfläche verschwindet.
> Auch wenn sich der Erfinder als Verbrecher herausgestellt hat so war reiserfs eine wirklich gute Sache
Das eine hat mit dem anderen ja auch nichts zu tun. (Auch wenn Adolf Hitler der Erfinder wäre ...
)
Ja, Reiser 3 habe ich auch sehr gern genutzt.
> Wirklich schade das wegen sowas ein gutes Produkt von der Bildfläche verschwindet.
Das ist ein großes Problem in der OS-Gemeinde: Viele Projekte sind One man shows oder haben zumindest einen unverzichtbaren Hauptentwickler. Etwas mehr Kooperationsfähigkeit wäre schon ein Segen.
Mit dem letzten Absatz vereinfachst du die lange Problemreihe, die schon lange vor der Gefängnisstrafe mit ReiserFS verbunden war.
Zumindest wenn du andeuten willst, das andere nicht mit an ReiserFS arbeiten wollen (NIH und ähnliches).
ReiserFS war ja zu jeder Zeit umstritten.
Bei Kerner wären Sie rausgeflogen.
Reine Zeitverschwendung, die Entwickler sollten sich lieber den BTRFS-Leuten anschließen .... Dann wird wenigstens für die Zukunft und nicht für die Tonne entwickwelt.
Nur wird das nie fertig werden. BTRFS ist das Duke Nukem Forever unter den Dateisystemen, ewig im Alphastatus, da war selbst Reiser4 näher an der Produktiveinsatztauglichkeit als es BTRFS jemals sein wird.
Wer darauf wartet wartet auf den Tod.
Ist BTRFS nicht sogar in machen Linux Distros schon Standard bei der Installation? Glaibe bei openSuse ist dies der Fall und Ubuntu hatte auch mal drüber nachgedacht BTRFS zum Stnadart zu machen.
Laut Wiki befindet sich BTRGS im Beta Status.
Allgemeine Frage @all
Worin liegen die Unterschiede zwischen BTRFS, ext4 und Reiser 4 und welches ist das schnellste Dateisystem im lesen, schreiben und öffnen von Dateien nach jetzigen aktuellen Stand
Suse wird BTRFS radikal in seine Distribution hineindrücken. Suse hat Ähnliches schon einmal mit ReiserFS in Suse 6.4 unternommen. BTRFS wird SLES- und openSUSE-Standard, koste es, was es wolle. Ext4 hat im SLES-Bereich bis heute kurioserweise keinerlei Bedeutung.
Na und? Wieso " kurioserweise"?
Weil die Suse-Nutzer damals mit ReiserFS schon zahlreich auf die Nase gefallen sind (ich spreche aus eigener Erfahrung). Aber dazulernen ist hald nicht jedermanns Sache.
Sind sie das? Also meine Erfahrung ist anders.
Wenn du damals die ReiserFS-Probleme im Suse-Umfeld nicht mitbekommen hast (die berühmten mit 0-Byte-Einträgen gefüllten Dateien), dann muss dich wohl der Schlaf der Gerechten übermannt haben.
Böse ReiserFS-Probleme hatte ich bei Slackware 9, kurioserweise nicht bei SuSE. Nutzen mag ich es seitdem nirgendwo mehr. Ext3/4 tun es für mich.
Ich hab davon gelesen, aber als SuSE und ReiserFS-Nutzer selber nichts davon mitbekommen.
Wenn man bei allen Bugs, die großartig irgendwo auftreten, gleich das Produkt meiden will, kann man wohl gar nichts mehr benutzen.
Bei ZFS, wohl eines der besten Dateisysteme heutzutage, konnte man schon Dinge erleben... und ext2/3/4, xfs und ntfs bekleckern sich da wohl auch nicht gerade mit Ruhm...
Klar, "irgendwas ist immer". Ich habe dem reiserfs auf SuSE 6.4(?) den Systemtod durch Datenkorruption nicht weiter verübelt, das war ja noch Beta. Bugreport und gut ist. Aber ein paar Jahre später hat sich das Gespann Slackware/reiserfs auf meinem damals nicht gar so alten TP600 reproduzierbar ähnlich verhalten. Mir persönlich reicht das.
Nachdem es bei mir auf unterschiedlichen Systemen damals alle ReiserFS-Dateisysteme über kurz oder lang erwischt hatte, kann ich mir nur schwerlich vorstellen, dass es überhaupt Nutzer gab, die damals nicht betroffen waren.
Was es aber sicher zahlreich gab waren Nutzer, die es nicht bemerkt hatten. Selbst wenn beispielsweise eine systemrelevante Datei wie die /etc/passwd betroffen war, was nicht unbemerkt bleiben konnte da sich dadurch niemand mehr am System anmelden konnte, wird nur ein kleiner Teil der Nutzer das Problem überhaupt analysiert haben. Und von dieser Teilmenge wird ebenfalls nur ein kleiner Teil der Nutzer das Problem weiter über einen längeren Zeitraum beobachtet und auf das Filesystem zurückgeführt haben.
Was aber wenn es überhaupt keine systemrelevante Datei erwischt hatte? Die Wahrscheinlichkeit ist sehr groß, schließlich sind die wenigsten Dateien systemrelevant.
Zudem befinden sich auf einem Linuxsystem haufenweise Dateien die für den Betrieb nie benötigt werden. Korrumpieren diese Dateien bekommt es der Nutzer überhaupt nicht mit.
Bei dem einen oder anderen hat dann vielleicht mal eine mp3 nicht mehr gespielt, nur wer analysiert den Inhalt einer mp3 und führt dies durch Beobachtung über einen längeren Zeitraum auf einen Fehler des Dateisystems zurück?
Oder es hat sich z.B. eine Anwendung mal "irgendwie seltsam" verhalten. Auch hier werden die allerwenigsten Nutzer dem Problem tatsächlich auf den Grund gehen.
D.h. die Dunkelziffer an durch ReiserFS verstümmelten Dateien wird immens hoch gewesen sein.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 20. Aug 2014 um 14:03.Also ich bin mit Reiser-FS noch nie auf die Nase gefallen, dafür aber mit LVM unter dem ach-so-stabilen Ext4?
Da kann ich nicht viel zu sagen, LVM setze ich nicht ein da es nicht in meinem Interesse ist die Komplexität zusätzlich zu erhöhen und ext4 nutze ich erst seit weniger als 2 Jahren. Ich habe damals mit dem Suse ReiserFS-Debakel meine Lektion auf die harte Tour gelernt und werde kein Filesystem mehr anfassen, welches nicht bereits gut abgehangen ist.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 17. Aug 2014 um 14:12.Du bist nicht "unter dem ach-so-stabilen Ext4" auf die Nase gefallen, sondern mit LVM. Wenn die LVM-Metadaten einmal beschädigt oder verloren sind, ist es ganz egal, welches Dateisystem du darin eingesetzt hast - die Rekonstruktion ist praktisch unmöglich. Das wissen leider nur die wenigen, die damit schon mal ein Problem hatten.
Und zu Hans Reiser, dem Hannibal Lecter der Dateisysteme, braucht man gar nicht mehr als das zu sagen.
Deine sicher nicht. Denn Reiser3 wurde im Lauf der Jahre verbessert und reiserfsck ebenfalls. Ich weiß noch, dass reiserfsck anfänglich nicht zu gebrauchen war.
Suse hatte ReiserFS bereits für den Produktiveinsatz ausgeliefert als es noch nicht stabil war. Offenbar wiederholen sie nun den selben Schritt mit dem nächsten Dateisystem. Jetzt meinen Spruch bezüglich dazulernen verstanden?
openSUSE ist das Testsystem für SuseEnterpriseLinux....da testet man Sachen - ja, auch auf Kosten der Nutzer, aber die bekommen dafür ein monetär-kostenfreies System.
Dann bist du noch nicht lange genug dabei, denn damals gab es weder OpenSUSE noch SLES sondern ausschließlich das käuflich zu erwerbende SuSE Linux.
Es gab aber selbst damals immer kostenlose Evaluations-Versionen (sehr oft als CD-Beilage in PC-Zeitschriften) und den FTP-"Poor Man's Install".
Um es nochmals deutlich zu sagen, ich habe wie so viele für das Suse ReiserFS-Debakel bezahlt - und das gleich in mehrfacher Hinsicht.
Ich würde sagen, du hattest keine Backup-Strategie. Denn ich habe vielleicht mal aus Root-Dummheit oder Hardwarecrash (ja, auch ohne Backup) Daten verloren - aber nicht auf Grund eines Dateisystems. Und Suse nutze ich seit ca. 1998
Du hast keinen blassen Schimmer welche Backupstrategie ich habe, also mach dich doch nicht lächerlich.
Na klar und was du nicht kennst das gab es nicht. Manche Leute habe schon ein sehr einfaches Weltbild. Sei froh, wenn du das SuSE-ReiserFS-Debakel nicht mitbekommen hast und schlafe weiter den Schlaf der Gerechten.
Da du nicht einmal die Geschichte der Suse-Systeme kennst ist das besonders glaubwürdig.
War schon blöd, wenn Reiser zuschlug.
Und ja, ich kaufte damals regelmäßig die Suse-Box.
Ich hatte allerdings irgendwann keine Lust mehr, als reiner Testuser benutzt zu werden. (Das ReiserFS-Debakel war nur ein blödes Ding von vielen.)
Und so sparte ich mir irgendwann den Kauf der Suse-Boxen, wendete mich Debian zu und spende lieber denen regelmäßig.
Das ist doch eine Frage die man so nicht beantworten kann.
Das hängt von dem Einsatzzweck, deinen Daten und der Hardware ab.
Und am Ende muss man sich natürlich fragen: Ist Geschwindigkeit alles? Merke ich den Unterschied überhaupt? Oder kommt der wirkliche Unterschied erst dann zum tragen, wenn man ordentlich Daten-Schiffbruch erlitten hat.
Ich schlage hierzu eine einfache Suchmaschinensuche vor.
Diese ergibt u.a. folgende Treffer:
http://www.phoronix.com/scan.php?page=article&item=reiser4_benchmarks&num=1
"Finally, Reiser4 Benchmarks Against EXT4 & Btrfs"
http://www.phoronix.com/scan.php?page=article&item=reiser4_linux35&num=1
"Reiser4 Benchmarked On Linux 3.5 Against EXT4, Btrfs, XFS, ReiserFS"
http://www.phoronix.com/scan.php?page=article&item=linux_310_reiser4&num=1
"Reiser4 File-System Shows Decent Performance On Linux 3.10"
Siehe auch Artikel wie z.B.:
http://www.serverfocus.org/reiserfs-vs-ext4-vs-xfs-vs-zfs-vs-btrfs
"ReiserFS vs ext4 vs XFS vs ZFS vs Btrfs – Linux filesystems compared"
Btrfs gibt's schon seit Längerem im produktiven Einsatz, einerseits wird's bei viele Linux Distros angeboten (wenn auch nicht als Standard), andererseits benutzt das Jolla Telefon btrfs als Standard.
Es als Vaporware zu bezeichnen ist definitiv Unsinn.
Ich persönlich benutze btrfs seit einiger Zeit produktiv, und muss sagen, dass es mir sehr gefällt. Abgesehen vom praktischen Umgang mit den Subvolumes macht sich die transparente Kompression deutlich bemerkbar, in einem Zuwachs des Throughputs von ca 30%. Der Platzverbrauch ist deutlich geringer, dank der Kompression, und dank des Copy-On-Write kann ich sogar grosse Dateistrukturen kopieren, ohne dass es extra Festplattenplatz kostet -- auf SSDs nicht ganz irrelevant. Dieses Featureset bietet kein anderes, im Vanillakernel verfügbares Dateisystem.
Zumindest fragt man sich, wozu man das brauchen soll.
Geht es darum ein stabiles und sicheres Dateisystem zu verwenden, dann gibt es andere Kandidaten (i.e. ext3, evtl. auch ext4). Features wie btrfs bietet reiser4 auch nicht, wobei btrfs ja wie erwähnt noch nicht vollständig ist, geschweige denn stabil.
Eigentlich gab es für reiser4 doch immer nur ein Argument (zumindest soweit ich mich erinnern kann): Performance
Wenn man darauf Wert legt, dann gibt es heute effektivere Methoden, wie Raid0, SSD oder einfach verdammt viel RAM.
Jedenfalls sehe ich wirklich nicht, wozu man reiser4 heute brauchen sollte.
Jedenfalls sehe ich wirklich nicht, wozu man reiser4 heute brauchen sollte.
Ah der Blinde spricht über Farben!
Na dann beleuchte uns doch...
Das ist noch mehr Zeitverschwendung,
denn zfs kann das, was btrfs mal können will, schon lange.
Hach ja, was habe ich innerlich gefeiert als bekanntgegeben wurde dass XFS bei RedHat wieder Standard-FS wird ... Das gute alte XFS, ein wenig betagt vielleicht aber bisher in Sachen Stabilität immer noch erste Klasse. Der Sinn und Zweck von ReiserFS hat sich mir nie wirklich erschlossen ....
"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.
+1, aber: XFS ausnahmslos hinter einer USV betreiben! Abrupte Stromausfälle können es ganz schnell zerschießen.
Eigene Erfahrungen, die jünger als 20 Jahre ist? Das bezweifle ich. XFS ist außerordentlich robust und hat gute Check-Tools.
Ja, zB zuletzt im Nov. 2013. Werde zu Neukunden gerufen, die ihren Server lt. eigenem Bekunden jahrelang problemlos ohne USV betrieben haben (und einen ungeplanten Stromausfall hatten).
Beim Booten bzw. bei xfs_repair schrieb er für die Datenpartition:
Zum Glück hatten sie immer aufs Backup geachtet, sodass die Sache mit Neuformatieren der Partition, Wiedereinspielen des Backups und einer neuen USV davor erledigt war.Die anderen Partitionen (ext4) waren übrigens nach einem fsck wieder einsatzbereit.
Warum benutzt man so einen Krampf?
Ich habe xfs mal vor Jahren probiert.
Wenn das immer noch so ist, dann ist das "Zerschiessen" wahrscheinlich konzeptbedingt.
Bei einem Journaling Filesystem darf es jedenfalls nicht passieren!!!