Login
Newsletter
Werbung

Thema: Reiser4 für Linux 3.15

53 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von schmidicom am Fr, 15. August 2014 um 14:30 #

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

0
Von DerZonk am Fr, 15. August 2014 um 16:25 #

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.

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

    • 0
      Von Snooopy am Fr, 15. August 2014 um 17:37 #

      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

      • 0
        Von brrrrr am Fr, 15. August 2014 um 21:32 #

        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.

        0
        Von Baldrian am Sa, 16. August 2014 um 08:57 #

        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.

        0
        Von brrrrr am Sa, 16. August 2014 um 11:14 #

        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"

      0
      Von sebas am Mo, 18. August 2014 um 14:28 #

      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.

      • 0
        Von Berniyh am Mo, 18. August 2014 um 17:46 #

        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.

    1
    Von Berniyh am Fr, 15. August 2014 um 20:14 #

    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.

    1
    Von ms123 am Sa, 16. August 2014 um 15:50 #

    Das ist noch mehr Zeitverschwendung,
    denn zfs kann das, was btrfs mal können will, schon lange.

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

  • 0
    Von brrrrr am Sa, 16. August 2014 um 12:59 #

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

    • 0
      Von brrr am Sa, 16. August 2014 um 13:04 #

      Mit Single-Prozessor-System meinte ich einen Prozessor mit einem Kern, also keinen Multicore-Chip.

      • 1
        Von 1ras am So, 17. August 2014 um 01:58 #

        Und die Beste Wahl, wenn man auf Datenverlust bei Systemabstürzen wert legt.

        • 0
          Von brrrrr am So, 17. August 2014 um 16:04 #

          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.

          • 0
            Von 1ras am So, 17. August 2014 um 16:53 #

            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.

            • 0
              Von Unerkannt am Mo, 18. August 2014 um 13:00 #

              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.

              • 0
                Von 1ras am Mo, 18. August 2014 um 16:19 #

                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.

              0
              Von brrrr am Mo, 18. August 2014 um 16:15 #

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

    1
    Von Markus B. am So, 17. August 2014 um 14:39 #

    +1, aber: XFS ausnahmslos hinter einer USV betreiben! Abrupte Stromausfälle können es ganz schnell zerschießen.

    • 0
      Von hjb am So, 17. August 2014 um 15:09 #

      Eigene Erfahrungen, die jünger als 20 Jahre ist? Das bezweifle ich. XFS ist außerordentlich robust und hat gute Check-Tools.

      • 0
        Von Markus B. am So, 17. August 2014 um 16:04 #

        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.

      0
      Von ms123 am So, 17. August 2014 um 15:34 #

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

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung