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.
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.