Login
Newsletter
Werbung

Thema: Reiser4 betritt erste Kernel-Testphase

81 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von puck am Do, 19. August 2004 um 17:15 #
Ferner ist die neueste Version des Systems vollständig atomar aufgebaut, was in der Praxis bedeutet, dass Aktionen sofort und ohne Log-Vorgänge durchgeführt werden. Vor allem im Kernel stellt sich immer die Problematik dar, dass bestimmte Vorgänge nicht simultan durchgeführt werden dürfen und deshalb vor allem auf SMP-Systemen geloggt werden.

Sicher, daß hier nicht logging und locking vermischt wurden?

[
| Versenden | Drucken ]
  • 0
    Von Demon am Do, 19. August 2004 um 17:22 #
    Oder so... ;)
    Danke, es handelt sich natuerlich um locking im Sinne von *_lock_* und nicht logging.

    Cheers,
    demon

    [
    | Versenden | Drucken ]
    0
    Von Thomas am Do, 19. August 2004 um 17:24 #
    Das hab ich mir auch gerade beim Lesen gedacht... ReiserFS /loggt/ zwar als Journaling-Filesystem auch fleissig mit, in dem Kontext geht es aber definitiv um Locking.

    --Thomas

    [
    | Versenden | Drucken ]
    0
    Von Hans Meiser am Do, 19. August 2004 um 17:26 #
    Die Legende hält sich hartnäckig, aber Hans Reiser ist keineswegs Deutscher sondern US-Ami.
    [
    | Versenden | Drucken ]
    • 0
      Von Thomas am Do, 19. August 2004 um 18:06 #
      Ich hab zwar im Artikel auch nicht gesehen, daß er als Deutscher bezeichnet wurde, aber durchaus an anderen Stellen im Web.

      Hier mal ein paar Infos zu Hans:
      http://www.idiom.com/~beverly/hans_resume.html

      --Thomas

      [
      | Versenden | Drucken ]
      • 0
        Von Hans Meiser am Do, 19. August 2004 um 19:35 #
        > Ich hab zwar im Artikel auch nicht gesehen, daß er als Deutscher bezeichnet wurde,

        Wurde inzwischen korrigiert.

        > aber durchaus an anderen Stellen im Web.

        Hmmm, in dem von dir angegebenen Lebenslauf (es ist Reisers "offizieller" CV) steht allerdings nichts von Deutscher. Hingegen heisst es da: "U.S. Citizen"

        [
        | Versenden | Drucken ]
        • 0
          Von Thomas am Fr, 20. August 2004 um 15:37 #
          > Hmmm, in dem von dir angegebenen Lebenslauf (es ist Reisers "offizieller" CV) steht
          > allerdings nichts von Deutscher. Hingegen heisst es da: "U.S. Citizen"

          Ich habe mich vielleicht etwas ungünstig ausgedrückt, ich wollte Deine Aussage - dass Hans Reiser US-Amerikaner ist - nur bestätigen.

          --Thomas

          [
          | Versenden | Drucken ]
    0
    Von Jörg W Mittag am Do, 19. August 2004 um 21:21 #
    Ich habe da noch eine weitere Anmerkung zum Thema Atomizität.

    > Ferner ist die neueste Version des Systems vollständig atomar aufgebaut, was in der Praxis bedeutet, dass Aktionen sofort und ohne Lock-Vorgänge durchgeführt werden.

    Dass das Dateisystem vollständig atomar ist, bedeutet doch wohl vor allen Dingen, dass es ... ähm .. vollständig atomar ist, oder? Dass es dadurch auch lockfrei wird - was ich mir übrigens nicht so ganz vorstellen kann - ist dann lediglich ein interessanter Nebeneffekt. Viel genialer finde ich, dass man bei anderen Dateisystemen, wenn man Atomizität erreichen will, dazu mittels Funktionen à la fsync() oder open(O_SYNC) o.ä. innerhalb der Applikation arbeiten muss und dadurch das Dateisystem fürcherlich an Leistung verliert, während Reiser4 von vorneherein immer atomar ist und dabei trotzdem leistungsmäßig die meisten anderen Dateisysteme locker in die Tasche steckt oder zumindest mithalten kann. (Allerdings: siehe meinen Beitrag zu den Benchmarks.)

    Ich kann mir vorstellen, dass simple, dateibasierte Datenbanken, wozu man großzügig auch News- und Mailserver u.ä. zählen kann, dadurch einen immensen Leistungsschub erreichen könnten. Schließlich ist dabei Atomizität eminent wichtig und wenn diese schon direkt im Dateisystem implementiert ist, und das auch noch ziemlich performant, dann profitieren solche Anwendungen vermutlich. (Siehe auch meinen Beitrag zum Reiser4 System Call.)

    jwm

    [
    | Versenden | Drucken ]
0
Von troll am Do, 19. August 2004 um 17:23 #
2.7 now!

Es gibt sachen, die erste wirklich gut getestet werden sollten, dazu zähl ich auch, vorurteilbehaftet, Dateisystem von HR

[
| Versenden | Drucken ]
  • 0
    Von Demon am Do, 19. August 2004 um 17:27 #
    Kernel der *-mm*-Reihe sind keine stabilen Kernel-Versionen sondern reine Testkernel mit _vielen_ neuen und noch ungetesteten Aenderungen. Die Reihe ist mit dem frueheren ac-Baum von Alan Cox vergleichbar.


    Cheers,
    demon

    [
    | Versenden | Drucken ]
    0
    Von thomas001 am Do, 19. August 2004 um 17:49 #
    es wird auch ne ganze weile bestimmt als experimentell gekennzeichnet sein,wenn du das natuerlich trotzdem nutzt ist ja nicht das problem des kernels ;)
    [
    | Versenden | Drucken ]
    0
    Von mdnet am Fr, 20. August 2004 um 11:57 #
    Das ist wohl eher missverständlich im Artikel, Reiser4 ist im mm-Kernel und beim Announcement dessen ist noch ein langer Abschnitt dabei, was man beachten muss und wie stabil und getestet das FS ist. Bis zum Einzug in den stabilen Kern dauert es bestimmt noch eine ganze Weile und IMHO nicht mehr im 2.6 Kernel.

    Marcel

    [
    | Versenden | Drucken ]
0
Von waveshaper am Do, 19. August 2004 um 17:36 #
Bei Reiserfs bin ich vorsichtig. War mal ne zeitlang ziemlich Buggy und es sind nicht selten mal Daten verschwunden. Mit ext3 ist man vielleicht etwas schlechter in Sachen Performance, dafür ist es ausgereift und wirklich ohne Bedenken benutzbar.
[
| Versenden | Drucken ]
  • 0
    Von Fred am Do, 19. August 2004 um 17:44 #

    das EXT3 stabiler sein soll ist leider nicht wahr.

    Bevor EXT3 überhaupt das Licht der Welt erblickte war ReiserFS schon lang etabliert. Immerhin war es das erste Journaling-Filesystem auf Linux.

    Wenn ich die Foren lese sehe ich recht häufig über zum teil gravierende Probleme mit EXT3. Irgendwie gibt es Probleme mit dem 2.6'er Kernel. Produktiv daher nicht einsetzbar !!

    Gruß

    Fred

    [
    | Versenden | Drucken ]
    • 0
      Von energyman am Do, 19. August 2004 um 17:56 #
      Hi,

      du mußt nur mal lkml archive der letzten Monate durchgehen und vergleichen, wieviele bugs bei ext3 und wieviele bei reiserfs auftauchten. Und welche davon wirklich fs bugs sind und welche davon kernelbugs sind, die sich im FS zeigen.

      Da verliert ext3 derartig, daß es fast schon kriminell ist, es zu empfehlen.

      ext3 ist das jüngste aller journaling fs, ist das mit den meisten probs (noch vor xfs) und den meisten veränderungen. Sprich, im höchten grade unstable.

      Wer sagt 'aber es basiert doch auf ext2 und das ist ausgereift' sollte sich nochmal hinsetzten und nachdenken.

      ext3 eignet sich für redhat/fedora-Leute, die reiser aus Prinzip ignorieren. Diese Personen haben auch nichts anderes verdient. Alle anderen sollten sich nach besseren alternativen umschauen.

      [
      | Versenden | Drucken ]
      0
      Von boris am Do, 19. August 2004 um 17:57 #
      gut das endlich mal einer den Überblick hat.

      Reiserfs war das erste journaling filesystem auf Linux, aber ext3 ist schon fast so alt, wie Linux selbst, weil es immer noch ein ext2 System ist und zusätzlich noch einen Journal hat, den man aber jederzeit wieder ausschalten kann. Es ist nach so langer Entwicklung enorm robust - oder was glaubst du, warum Redhat dieses System als Standard verwendet ?
      Reiserfs ist ein feiner Ansatz gewesen, der anfangs sehr buggy war (es ist ja nicht einmal eine filesystemcheck vorgesehen gewesen) der aber seit einiger Zeit sehr erwachsen geworden ist. give it a try.

      [
      | Versenden | Drucken ]
      • 0
        Von energyman am Fr, 20. August 2004 um 00:04 #
        Falsch.

        ext3 ist eine Erweiterung von ext2, die nicht nur journaling-Fähigkeiten mit sich bringt. Es ist immer möglich zu ext2 zurück zu wechseln, daß ist der einzige Vorteil.

        Denn auch wenn der Unterbau bewährt ist, die Daten müssen erstmal durch den ext3-Teil, der neu, buggy und ständiger Veränderungen unterworfen ist.

        Wer sagt, daß ext3 fast so alt ist, wie der kernel, kann auch sagen, daß reiser fast so alt ist, wie der kernel. Oder die nvidia-Treiber fast so alt wie X.

        Schau dir die Archive an, seh massig ext3 Probleme... ich bleib da lieber bei reiserfs, das ist älter und erprobter.

        [
        | Versenden | Drucken ]
        • 0
          Von boris am Fr, 20. August 2004 um 02:11 #
          "ext3 ist eine Erweiterung von ext2, die nicht nur journaling-Fähigkeiten mit sich bringt. Es ist immer möglich zu ext2 zurück zu wechseln, daß ist der einzige Vorteil."
          Habe ich etwas anderes gesagt ?

          "Denn auch wenn der Unterbau bewährt ist, die Daten müssen erstmal durch den ext3-Teil, der neu, buggy und ständiger Veränderungen unterworfen ist."
          Sicher sicher, wo deine Daten nicht überall durchmüssen. Es wird einfach ein Journal geführt, der das System wieder konsistent macht. Sollte das mit dem Journal nicht klappen, dann steht immer noch das gute alte fsck zur Verfügung. Ich verfolge dutzende Foren und Mailinglisten von Fedora und Redhat. Ich habe noch nie von Datenverlust durch ext3 Bugs gelesen - und schon gar nicht selbst erfahren.

          "Wer sagt, daß ext3 fast so alt ist, wie der kernel, kann auch sagen, daß reiser fast so alt ist, wie der kernel. Oder die nvidia-Treiber fast so alt wie X."
          ext2 ist fast so alt wie der Kernel. ext3 ist "nur" eine Erweiterung. Du weißt, was ich meine.

          Ich richte mich nicht gegen Reiser, sondern verteidige nur das ext3. Ich selbst spiele mit dem Gedanken, wie ich am besten mal reiser4 ausprobieren kann. Wenn sich bei mir aber etwas bewährt hat, dann war das ext2/3 und das schon über rund 6 Jahre hinweg und nicht nur auf meinem Privatrechner, sondern auf diversen Servern, die die 24/7 seit Jahren laufen und zum Teil von mehreren hundert Benutzer beansprucht werden. Ich mache damit Gigabyteweise Backups über nfs, scp, samba, wir speichern millionen von atomar kleinen Dateien in Form von Windows-Benutzerprofilen von rund 500 Benutzern und und und. Reiserfs under reiser4fs mögen vielleicht performanter sein, aber ein Dateisystem, das solchen Anforderungen gewachsen ist, wie ich sie eben beschrieben habe, kann ich leider nicht als "buggy" oder "unstable" einstufen, sorry !

          Ein dickes Argument gegen reiserfs ist noch, dass man es nicht zur Durchsetzung von security policies von SELinux benutzen kann - ein sehr großer Nachteil, wenn man bedenkt, was für eine Sicherheit SELinux bringt.

          [
          | Versenden | Drucken ]
          • 0
            Von nixname am Fr, 20. August 2004 um 10:04 #
            Ich teste ReiserFS seit 2000, klar gab es da mal den einen oder anderen Fehler. Aber im Vergleich zu EXT3 waren diese Probleme harmlos. Ich bin immer erstaunt, wie sicher sich vieler ihrer Meinung sind, die nur auf Hörensagen beruht und nicht auf eigener Erfahrung. Aber am witzigsten finde ich, daß diese Leute vor allem denen die Welt erklären, deren Meinung auf eigenen Erfahrung beruht. Der Konstruktivismus ist einfach eine tolle Sache.
            [
            | Versenden | Drucken ]
            0
            Von energyman am Fr, 20. August 2004 um 17:18 #
            ...und vor ein paar Monaten tauchte ein bug auf, der verhinderte, daß man die glibc auf ext3 Systemen kompilieren konnte. War kein programmier- war ein design-bug.
            Sowas gibt es mit reiserfs nicht.
            [
            | Versenden | Drucken ]
      0
      Von jupiter am Do, 19. August 2004 um 18:09 #
      ext3 _ist_ äusserst stabil. woher hasst du die informationen das es gravierende probleme geben soll? reiserfs war sehr install und wurde nicht ohne grund deswegen bei vielen verbannt. mittlerweile sind doch fast alle auf ext3 umgestiegen.
      [
      | Versenden | Drucken ]
      • 0
        Von georg am Do, 19. August 2004 um 18:25 #
        hatte bisher weder mit reiser noch nie probleme, benutze es aber erst seitdem sich eine platte beharrlich geweigert hat auf ext3 formatiert zu werden.
        muss auch sagen dass filesystem checks mit reiser bei weitem seltener nötig sind.
        mfg georg
        [
        | Versenden | Drucken ]
        0
        Von Heiko am Do, 19. August 2004 um 21:23 #
        @Jupiter
        >reiserfs war sehr install und wurde nicht

        install ?
        Du benutzt wohl eine Distri, bei der oft ein 'make install' oder 'dpkg install' getippt werden muss ?

        :)

        [
        | Versenden | Drucken ]
        0
        Von energyman am Fr, 20. August 2004 um 00:07 #
        *gröhl*

        reiser hatte einige Probleme in der 2.4 Frühzeit, weil einige Veränderungen in anderen kernelteilen beim mergen der patches nicht immer berücksichtigt wurden.

        ext3 hat Probleme in späten 2.4 kerneln und in 2.6.

        ext3 ist ein Aufsatz, wenn der Aufsatz die Daten versaut, kann der Unterbau noch so gut sein. Schrott ist Schrott

        [
        | Versenden | Drucken ]
        0
        Von Mike am Sa, 21. August 2004 um 00:37 #
        "mittlerweile sind doch fast alle auf ext3 umgestiegen."

        Wer bitte sind "alle" ?

        Namen, Links ?

        [
        | Versenden | Drucken ]
        0
        Von Qlausp am Sa, 20. November 2004 um 03:08 #
        Das kann ich überhaupt nicht bestätigen. Aus eigener Erfahrung kann ich sagen, dass ReiserFS erheblich zuverlässiger funktioniert als ext3. Ext3 hat es schon mehrmals geschafft eine komplette Partition bei einem Systemcrash unbrauchbar zu machen. Inklusive komplettem Datenverlust. Daraus habe ich die Konsequenz gezogen statt ext3 ReiserFS zu verwenden. Seit dem habe ich keinen einzigen Datenverlust mehr gehabt und auch Filesystemchecks sind praktisch nie nötig.
        [
        | Versenden | Drucken ]
      0
      Von root_tux_linux am Do, 19. August 2004 um 19:26 #
      Du weisst aber schon das ext3 nur die Weiterentwicklung von ext2 und diese weiderum von extist?

      ext war stabil bevor es reiserfs überhaupt gab und Reiserfs ist erst ab Kernel 2.4.18 "stabil"!

      Bei vielen Foren kann man auch lesen das es viele viele probleme mit ReiserFS gibt!

      XFS ist meiner Meinung nach eh das beste FS ;)
      Sieht man ja schon daran das die Entwickler von Reiserfs4 einen Benchmark mit XFS scheuchen

      [
      | Versenden | Drucken ]
      • 0
        Von pab am Do, 19. August 2004 um 20:24 #
        >Sieht man ja schon daran das die Entwickler von Reiserfs4 einen Benchmark mit XFS scheuchen

        Was bist denn du für ein troll?

        http://www.namesys.com/benchmarks/v4marks.html

        Also ich seh da reiser4 und xfs
        (Sogar reiser3 schlägt xfs..)

        [
        | Versenden | Drucken ]
        • 0
          Von XFS-Fan am Do, 19. August 2004 um 20:32 #
          > Also ich seh da reiser4 und xfs
          > (Sogar reiser3 schlägt xfs..)

          Man kann jeden synthetischen Benchmark so aufbauen, dass ein bestimmtes Dateisystem als Sieger hervorgeht.
          Gibts da nicht irgendwas von Microsoft, das die Vorteile von FAT12 (ja richtig, "zwölf") hervorhebt? ;)

          Ich habe bisher schon ReiserFS, ext3, JFS und XFS als Journaling Dateisysteme ausprobiert. Dabei hatte ich mit ReiserFS und ext3 einen kompletten Datenverlust (Bad Superblock?), während XFS und JFS auch nach 100x Stromausfall (manche auch provoziert) liefen.

          [
          | Versenden | Drucken ]
          • 0
            Von Heiko am Do, 19. August 2004 um 21:25 #
            >auch nach 100x Stromausfall (manche auch provoziert)

            Du provozierst Stromausfälle ?
            Etwa indem Du die Straßenlaterne bei Dir ans Netz klemmst ?

            ;)

            [
            | Versenden | Drucken ]
          0
          Von root_tux_linux am Fr, 20. August 2004 um 07:34 #
          AUGEN AUF!

          Wo siehst du da einen richtigen Benchmark zwischen Reiserfs4 und XFS?

          Man sieht am Schluss Ergebnisse!
          Man kann weder sehen wie und mit was diese angeblichen Benchmarks zustande kamen!
          Hockte Mr. Reiser mit der Stoppuhr daneben als RM/CP/Sync liefen oder wie?

          99% Der Seite handeln von Benchmarks über reiserfs/4 vs ext2/3!
          Sowas kann man einen Benchmark nennen!

          Wenn jemand aber nur ein Ergebniss ohne Hand und Fuss hinschreibt ist das definitiv kein Benchmark sondern Microsoft like Marketing :)


          PS. Bezeichne wenn anders als Troll Kleinkind.

          [
          | Versenden | Drucken ]
        0
        Von husky am Do, 19. August 2004 um 21:52 #
        Moin :-)
        Also, zu ReiserFS kann ich - gleich welche Version - nix sagen, weil ich viel von den frühen Bugs gehört hatte und dann lieber auf andere FS gewechselt habe. Aber:

        > XFS ist meiner Meinung nach eh das beste FS

        Es hat sicher seine Vorteile. Der Grund, weswegen ich wieder ab bin davon, ist, daß ich bei Abstürzen (durch den nvidia-Treiber) häufig nur per hard-reset wieder einen ansprechbaren Rechner bekommen hatte. Und wie Eduard Bloch (u.a. Maintainer von XFS bei Debian) mir bestätigte, "verliert" XFS leider bei solchen Sachen gerne mal die zuletzt beschriebenen Dateien. Ist schon etwas nervig, wenn man alle drei Tage seine KDE-Einstellungen neu machen muß...

        > Sieht man ja schon daran das die Entwickler
        >von Reiserfs4 einen Benchmark mit XFS scheuchen

        Huch? Aber nicht, daß demnächst die Tierschützer vor Ihren Türen stehen. Arme, hilflose Benchmarks scheuchen, das grenzt ja an FS-Quälerei!

        ;-)

        husky

        [
        | Versenden | Drucken ]
        0
        Von energyman am Fr, 20. August 2004 um 00:08 #
        auch du hast nicht verstanden, daß das Alter von ext2 nichts mit der Stabilität von ext3 zu tun hat. Schade.
        [
        | Versenden | Drucken ]
        0
        Von El Pseudonymo am Fr, 20. August 2004 um 09:39 #
        Bei vielen Foren kann man auch lesen das es viele viele probleme mit ReiserFS gibt!

        Nur gibt das vermutlich kein authentisches Bild. Genauso wie du jetzt schreibst, in "vielen Foren" kann man das lesen, wird wahrscheinlich der Nächste kommen, bei dir abgucken und dann wieder in einem anderen Forum schreiben "Auf pro-linux hat jemand geschrieben, reiser ist instabil". Die selben alten Geschichten, 1000 mal zirkuliert.

        Ich will ehrlich sagen (das wird sich wohl sowieso jeder denken), das ich auch nicht weiß, welches Dateisystem denn nun das stabilste ist. Aber das immer wieder so unkritisch Hörensagen verbreitet wird, finde ich nicht schön.

        In diesem Fall ist das noch besonders problematisch, weil zu befürchten ist, das Benutzer aus Furcht dann nicht nur nicht Reiser nehmen, sondern überhaupt bei ext2 bleiben, und sich damit dann in der Praxis Probleme einhandeln, welche durch Einsatz eines moderneren (journaling-)Dateisystem nicht auftreten würden.

        [
        | Versenden | Drucken ]
        • 0
          Von root_tux_linux am Fr, 20. August 2004 um 12:35 #
          z.B. linuxforen.de das Forum hat tausende von User und da gibts eine Umfrage und der grösste Teil hatte mit ReiserFS Probleme wie auch ich und so einige die hier ihren kommentar abgegeben haben.
          [
          | Versenden | Drucken ]
          • 0
            Von El Pseudonymo am Fr, 20. August 2004 um 14:04 #
            Die Umfrage da, d.h. die Zahlen, sind ziemlich nutzlos.

            Man kann da alles mögliche hineininterpretieren, z.B. auch das ReiserFS das stabilste Dateisystem ist.

            ( Übrigens, wörtlich genommen ist deine Aussage anhand der dort angegebenen Zahlen falsch. Aber das ist wohl Pedanterie :-) )

            [
            | Versenden | Drucken ]
        0
        Von Andreas B. am Fr, 20. August 2004 um 16:44 #
        mh.. Reiserfs konnte man mit den namesys patches schon im 2.2.16 oder früher benutzen,

        dass die erst ab einer bestimmten Kernelversion direkt im Tree waren, lag eigentlich nur
        an der Antipathie von Herrn Torvalds gegen Herrn Reiser, naja Herr Reiser hat auch eine
        etwas gewöhnungsbedürftige Art sein Produkt anzupreisen, ein bisschen mehr Sachlichkeit u.
        Zurückhaltung würde Ihm besser stehen (aber wie sich an ReiserFS gezeigt hat, er ist ein fähiger
        Programmierer)


        und ich muss ganz ehrlich sagen, damals war ext3 auch nur über patches verfügbar und im 2.4.0 war
        ext3 auch nicht enthalten,

        und das ReiserFS erst ab "2.4.18" stabil "war" halte ich für eine etwas aus der Luft gegriffen,
        ich kann Dir als langjähriger (seitdem ich meine Slackware 7.0 kerneldisk mit einem Kernel mit Reisersupport ausgestattet habe und die reiser_fsck-utils in die slckCD eingebaut habe) sagen, dass ReiserFS

        mir seit diesem Zeitpunkt keine Datenkorruption, oder Datenverlust beschert hat, nun gut ich setze
        seit dem 2.4.0 vermehrt ibm's JFS ein, da es sich für meine Belange "subjektiv" performanter gezeigt hat wer aber viele kleine Dateien zu verwalten hat, für den ist ReiserFS die bessere wahl,
        und zum Glück ist es durch die Abstraktion schnurz ob man auf jfs o. ext2 o. ext3 o. xfs o. ReiserFS

        einsetzt, man kann ja auch für die mittleren bis grossen dateien eine Partition jfs fahren,
        und für die ganz kleinen bis mittleren Dateien ReiserFS, z.B. /usr/doc /usr/share/
        wäre als ReiserFS eingebunden wahrscheinlich vom Platzbedarf und von der Geschwindigkeit her besser
        verwaltet.

        [
        | Versenden | Drucken ]
        • 0
          Von root_tux_linux am Sa, 21. August 2004 um 18:29 #
          Also ehrlich gesagt weiss ich nicht wie IHR Threads lest!

          1. Schrieb ich das in vielen Foren von Problemen berichtet werden, WIE AUCH ICH SIE HATTE o.ä (Wer will kann ja nachlesen gehen). Das ist dann kein hörensagen sondern eigene Erfahrung!

          2. Wo ich das mit ReiserFS und 2.4.18 auf der Luft gegriffen habe?

          Zitier: "ReiserFS ist ein B*-tree basierendes Dateisystem mit einer guten Performance und überholt sowohl ext2 und ext3 im Umgang mit kleinen Dateien (Dateien kleiner als 4k) oftmals mit einem Faktor von 10x-15x. ReiserFS skaliert extrem gut und hat Metadata Journaling. Seit Kernel 2.4.18+ ist ReiserFS stabil und sowohl als Dateisystem für generelle Anwendungen, als auch für extreme Fälle wie große Dateisysteme, den Gebrauch mit vielen kleinen Dateien, den Gebrauch mit sehr großen Dateien und Verzeichnissen mit tausenden von Dateien brauchbar. "

          Quelle: http://www.gentoo.org/doc/de/handbook/handbook-x86.xml?part=1&chap=4

          Ich kann dir gerne noch X Quellen geben die dies bestätigen. Solltest du ja als langjähriger Benutzer von Linux wissen ;)

          PS: Meine erstes Linux war Redhat 5.1 Deluxe ;)

          [
          | Versenden | Drucken ]
        0
        Von Alex am Di, 24. August 2004 um 10:20 #
        Ich setze reiserfs schon seit 2 Jahren erfolgreich ein. Kein Datenverlust, Gute Performance und ich freue mich schon auf ein stable reiser4.

        Immerhin hatte reiserfs ein "noisy" Kabel entdeckt.

        [
        | Versenden | Drucken ]
0
Von root_tux_linux am Do, 19. August 2004 um 19:20 #
Schön und gut aber wieso gibts keine Benchmarks in denen ReiserFS4 gegen XFS antritt?

Man sieht nur ext-ext3 von denen man eh weiss das sie "langsam" sind im vergleich schon zu ReiserFS.

[
| Versenden | Drucken ]
  • 0
    Von Karsten am Do, 19. August 2004 um 20:16 #
    Da gab's mal einen Vergleich im Linux-Magazin(Ausgabe 03/2004) zwischen ext2, ext3,reiserfs,xfs,jfs. Dabei ist lediglich Ext3 gegenüber anderen Systemen teilweise erheblich langsamer gewesen (Über 3 mal langsamer beim schreiben einer 2 GB-Datei). Die anderen FS nehmen sich da oftmals nicht so viel in sachen Geschwindigkeit. Da geht's dann eher um die Features und Tools für die Dateisysteme.
    [
    | Versenden | Drucken ]
    • 0
      Von sirius am Do, 19. August 2004 um 21:17 #
      der test war auch sehr objektiv ...
      ext3 hatten die mit den langsamsten einstellungen laufen, wenn ich mich noch richtig erinnere.
      [
      | Versenden | Drucken ]
    0
    Von pab am Do, 19. August 2004 um 20:25 #
    Nochmal für den super troll:
    http://www.namesys.com/benchmarks/v4marks.html
    [
    | Versenden | Drucken ]
    • 0
      Von Blablabla am Do, 19. August 2004 um 20:33 #
      Und unter http://www.microsoft.com/germany/diefakten/default.mspx findest du einen unabhängigen Vergleich von Windows und Linux...


      *SCNR*

      [
      | Versenden | Drucken ]
      • 0
        Von tut nichts zur sache am Fr, 20. August 2004 um 01:12 #
        trottel, der vorwurf war, daß reiser bei seinen eigenen tests den vergleich mit xfs scheut.


        Geh zurück ins heise forum und troll dort weiter

        [
        | Versenden | Drucken ]
    0
    Von root_tux_linux am Fr, 20. August 2004 um 07:26 #
    Sorry ich bin kein Troll.

    Ich frag mich nur wieso auf http://www.namesys.com/benchmarks.html alle "richtigen" detailisierten Tests mit reiserfs, reiserfs4, ext2 und ext3 durchgeführt wurden.

    Bei JFS und XFS siehst man nur angebliche cp/rm/sync Ergebnisse.

    Aber keine detailisren Benchmarks wie die von reiserfs(4) vs ext2/3, geschweige wie es gemessen wurde o.ä.!

    Deswegen meine Frage wieso es keine Benchmarks gibt zwischen ReiserFS4 und XFS!

    Sowas eracht ich nicht als Benchmark wenn einer nur Ergebnisse presentiert ohne mitzuteilen was überhaupt getestet wurde und wie.

    Sowas ist Microsoft Niveau. Studien mit Ergebnisen presentieren ohne zu erklären wie sie auf diese kamen.

    Somit kein Benchmark!

    [
    | Versenden | Drucken ]
    • 0
      Von pab am Fr, 20. August 2004 um 08:13 #
      Sorry: Mach die augen auf: du kannst den source vom benchmark downloaden
      [
      | Versenden | Drucken ]
      • 0
        Von root_tux_linux am Fr, 20. August 2004 um 12:38 #
        Schau ich mir nachher nochmal an.

        Aber alleine der Satz:"Reiser4 ist das schnellste Dateisystem" find ich lächerlich. Hört sich so an wie die Distrubtion die behauptet das schnellste GNU/Linux gebastelt zu haben.

        [
        | Versenden | Drucken ]
      0
      Von maestro_alubia am Fr, 20. August 2004 um 11:27 #
      Es heißt jetzt Reiser4, nicht ReiserFS4.
      Ich nehme an, eine Näherung an ext2/ext3, die auch kein FS im Namen tragen.

      Weiß jemand genaueres?

      [
      | Versenden | Drucken ]
mehr SWP
0
Von Feynman am Do, 19. August 2004 um 19:32 #
Wisst Ihr was?

Ich halte es für beinahe unmöglich, dass im Jahr 2004 ein neues Dateisystem entwickelt wird, dass keinerlei Software-Patente verletzt.

Wie stellt sich der schöne Herr Reiser das eigentlich vor? Was soll eine Storage-Firma denn tun, wenn ihr gerichtlich der Zugriff auf ihre Daten untersagt wird, weil die zugrundeliegende Datenspeichertechnik Patente verletzt?


Ich finde, dafür, dass in den USA SWP seit 1981 existieren, gehen viele Leute reichlich blauäugig mit ihren Neuentwicklungen um. NX ist auch so ein Beispiel. Wenn in EU die SWP rückwirkend legalisiert werden, was meint Ihr wohl, welche Halbwertszeit NX dann noch hat? Vor allem, da Microsoft etwas erschreckend ähnliches in Windows XP eingebaut hat?

Ich würde bei Reiser4, aber auch bei NX nicht so laut schreien, sondern mir erstmal Sponsoren für die juristische Patentprüfung besorgen - und ein paar tüchtige Patentanwälte, die das mal durch die Mangel nehmen. Dann gibt es zwar immer noch die Unsicherheitsspanne zwischen Einreichung und Erteilung, aber besser als nix.

Gerade NX könnte schneller tot sein, als man Hello World angezeigt hat.


In diesem Sinne: TUT was dagegen!!! mZum Beispiel mit der Urlaubspostkarten-Idee an die EU-Abgeordneten. Wenn jeder mal 5€ in Briefmarken investieren würde, dann wäre schon was gewonnen. Die Adressen gibt's auf Webseiten.

Oder wollt Ihr in Zukunft *zwangsweise* mit Windows arbeiten?

[
| Versenden | Drucken ]
  • 0
    Von troll am Do, 19. August 2004 um 19:36 #

    Oder wollt Ihr in Zukunft *zwangsweise* mit Windows arbeiten?

    Solaris/sparc
    AIX/ppc
    HPUX/ia64
    existieren.
    [
    | Versenden | Drucken ]
    0
    Von thomas01 am Do, 19. August 2004 um 21:10 #
    Warum sollte die EU etwas tun, was ihrer wirtschaft schadet (_KEINE_ SWP zulassen)? In der Wirtschaft sitzt das geld, wen interessiert da noch das Volk? aufwachen!
    [
    | Versenden | Drucken ]
0
Von Nguyen am Do, 19. August 2004 um 20:47 #
im Hinblick auf Performance habe ich schon einiges im Internet gefunden.

Aber wie sieht es mit der Datensicherheit aus?

Beispiel: Ich schalte die Kiste im laufenden Betrieb aus.
Gibt es da eine Seite im Internet, die die Journaling FS vergleicht?

[
| Versenden | Drucken ]
  • 0
    Von Jörg W Mittag am Do, 19. August 2004 um 22:26 #
    > Aber wie sieht es mit der Datensicherheit aus?

    Atomizität - und Journalling ist ja letztlich lediglich eine Möglichkeit, Atomizität sicherzustellen - hat nichts mit Datensicherheit zu tun! Das ist ein weit verbreitetes Missverständnis.

    Wie der Name ja eigentlich schon sagt, stellt Atomizität lediglich die Datenkonsistenz sicher. Das heißt, es können zwar schon Daten verloren gehen, aber die Daten, die vorhanden sind, sind wenigstens "sinnvoll". Atomizität, bzw. atomare Operationen (vom griechischen Wort für "unteilbar"), bedeutet eben, dass Operationen entweder ganz oder gar nicht, aber auf keinen Fall teilweise ausgeführt werden. Das heißt, entweder eine Änderung wird durchgeführt oder eine Änderung wird nicht durchgeführt, aber sie wird niemals nur teilweise ausgeführt. Dadurch kann es zwar passieren, dass mal veraltete Daten vorhanden (mit anderen Worten: Änderungen verloren gegangen) sind - nämlich dann, wenn während einer Änderung ein Fehler auftritt und die Änderung deswegen "gar nicht" ausgeführt wird - aber es können eben niemals "kaputte" Daten vorhanden sein.

    Bei klassischen Journalling-Dateisystemen (das sind alle außer Reiser4, also ext3, JFS, XFS, Reiserfs, NTFS u.s.w.) wird die Atomizität dadurch erreicht, dass alle Daten zweimal geschrieben werden: einmal ins Journal, dann in den Datenbereich und dann werden sie im Journal als "geschrieben" gekennzeichnet. Indem man dann einfach das Journal durchgeht und alle Änderungen rückgängig macht, die nicht als "geschrieben" gekennzeichnet sind, kann man "halbe" Änderungen wieder rückgängig machen. Das bedeutet aber automatisch auch, dass sich die Leistung bei eingeschaltetem Journal praktisch halbiert.

    Aus diesem Grund verzichtet man darauf, alle Operationen atomar zu machen und macht nur noch Metadaten-Operationen atomar. Das heißt, dass zwar die Datenkonsistenz nicht mehr gewährleistet ist, aber wenigstens die Dateisystemkonsistenz. Dieses sogenannte Metadaten-Journalling wird von allen klassischen Journalling-Dateisystemen außer ext3 durchgeführt. Ext3 ist das einzige klassische Linux-Journalling-Dateisystem, was auch vollständiges Journalling der Daten beherrscht, aber die Standard-Einstellung ist lediglich Metadaten-Journalling. Reiser4 dagegen ist, wie schon im Artikel steht, vollständig atomar, steht hier also auf einer Stufe mit ext3.

    Beispiel: Ich schalte die Kiste im laufenden Betrieb aus.

    Datensicherheit kann dir in diesem Falle nur ein System bieten, bei dem sämtliche Caches und Puffer ausgeschaltet sind, angefangen vom Schreibcache der Platten über einen evtl. vorhandenen Cache des RAID-Controllers bis hin zum Buffercache des Betriebssystems (Mount-Option 'sync').

    Ein Journalling-Dateisystem kann dir dann zusätzlich noch Metadatenkonsistenz (alle) oder gar Datenkonsistenz (ext3 mit 'journal=ordered' und Reiser4) bieten.

    Gibt es da eine Seite im Internet, die die Journaling FS vergleicht?

    Keine Ahnung. Es scheint aber so, dass Reiserfs recht anfällig auf Hardware-Fehler reagiert, was wohl auch mit zu der Legende geführt hat, dass Reiserfs besonders instabil sei. Das ist allerdings, wie Microsoft so schön sagt, kein Bug sondern ein Feature. Hans Reiser ist der Meinung, dass ein Dateisystem dazu da ist, Dateisystemfehler zu verhindern und dass das Verhindern von Hardwarefehlern nicht Sache des Dateisystemschreibers sondern des Festplattenherstellers, Controllerherstellers, Systemintegrators und Systemadministrators ist. Ich stimme ihm dabei zu, aber das ist sicherlich Geschmackssache.

    jwm

    [
    | Versenden | Drucken ]
    • 0
      Von Ronny Buchmann am Fr, 20. August 2004 um 08:54 #
      > ... Das heißt, entweder eine Änderung wird durchgeführt oder eine Änderung wird nicht durchgeführt,
      > aber sie wird niemals nur teilweise ausgeführt. ...
      Eine Änderung ist z.B. ein einzelner write() Aufruf, das bedeutet, dass auch bei Dateisystemen mit atomaren Operationen keine Datenkonsistenz auf Anwendungsebene vorhanden ist. Dazu wäre Transaktionen vonnöten, diese Funktion ist AFAIK in Reiser4 zwar geplant aber noch nicht vorhanden. Außerdem wäre das auch nur für "vertrauenswürdige" Programme die als root laufen nutzbar, weil sonst ein DOS fast unausweichlich ist.

      > > Beispiel: Ich schalte die Kiste im laufenden Betrieb aus.

      > Datensicherheit kann dir in diesem Falle nur ein System bieten, bei dem sämtliche Caches und Puffer
      > ausgeschaltet sind, angefangen vom Schreibcache der Platten über einen evtl. vorhandenen Cache des
      > RAID-Controllers bis hin zum Buffercache des Betriebssystems (Mount-Option 'sync').

      Dazu sollte man ergänzen, dass man genau dieses Verhalten in der Praxis nicht findet, weil dann die Performance sehr schlecht wäre.
      Es ist auf jeden Fall davon abzuraten, den Rechner einfach auszuschalten ohne ihn runterzufahren.

      --
      http://linuxwiki.org/RonnyBuchmann

      [
      | Versenden | Drucken ]
0
Von Jörg W Mittag am Do, 19. August 2004 um 21:25 #
Hi,

Reiser4 ist zwar ein durchaus leistungsstarkes Dateisystem, erfordert dabei aber auch einen durchaus leistungsstarken Hauptprozessor. Das ist im Prinzip nicht schlecht, schließlich kriegt man Prozessorleistung derzeit praktisch hinterhergeschmissen, aber man sollte sich dessen bei der Dimensionierung seines Dateiservers bewusst sein.

E/A-Leistung ist heutzutage wesentlich teuerer als Rechenleistung, daher bin ich auch mal gespannt, ob Reiser4 mit dem für später geplanten Kompressions-Plugin hier noch einmal nachlegen kann.

jwm

[
| Versenden | Drucken ]
  • 0
    Von Heinrich am Fr, 20. August 2004 um 01:03 #
    > Reiser4 ist zwar ein durchaus leistungsstarkes Dateisystem,
    > erfordert dabei aber auch einen durchaus leistungsstarken Hauptprozessor.
    >
    Das mit der höheren CPU Last von Reiser4 hat auch schon die iX in Ihrem Dateisystem Review geschrieben.
    Nur was nie erwähnt wurde und wird: Wie hoch war denn die Last denn nun? Einfach nur "Reiser4 erzeugt u.a. durch seine Dancing-Trees eine höhere Last als andere Dateisysteme" ist eine Nullaussage. Wie hoch ist denn bei einer gegebenen Festplattenaktivität die CPU- und IO-Last bei Reiser3, Reiser4, XFS, JFS, Ext2/3, ... ? Ohne diese Informationen ist eine solche Aussage nix wert und für mich somit kein Kill-Kriterium für Reiser4.

    > E/A-Leistung ist heutzutage wesentlich teuerer als Rechenleistung, daher
    > bin ich auch mal gespannt, ob Reiser4 mit dem für später geplanten
    > Kompressions-Plugin hier noch einmal nachlegen kann.
    >
    Zumindest wer x86 Rechner für Fileserver einsetzt dürfte mit den bisherigen Dateisystemen eher an die IO-Grenze gelangt sein, bevor die CPU-Leistung ein Problem war. Letztere kann man zur Not gegen ein schneller getakteteres Modell austauschen, aber wie kriegt man eine mehr IO Bandbreite, wenn die Crossbars auf dem Mainboard die Bandbreite begrenzen?
    Ein Kompressions-Plugin dürfte zumindest die CPU Hersteller freuen.

    [
    | Versenden | Drucken ]
0
Von spinoza am Do, 19. August 2004 um 21:35 #
ext3 mag Vor- und Nachteile haben. Mit Kernel 2.4 lief es bei mir stabil. Einer der Vorteile ist, dass ext3 im Ggs zu anderen FS sowohl Metadaten als auch Daten checkt (im Modus data=ordered). Soweit ich weiss checken die anderen Journaling FS nur Metadaten. Das mag bei einem RAID System keine Rolle spielen, aber fuer die meisten Nutzer spielt glaube ich die Reliability eine groessere Rolle als die Performance. Was ReiserFS betrifft, so habe ich mal im SuSE Handbuch nachgeblaettert: "ReiserFS pays great care to metadata but not the data itself. Future generations of ReiserFS will include data journaling... as well as ordered writes"
weiss jemand ob das schon realisiert ist?
cheers
[
| Versenden | Drucken ]
0
Von Jörg W Mittag am Do, 19. August 2004 um 21:37 #
Hi,

ein weiterer interessanter Aspekt von Reiser4 ist der Reiser4-Systemaufruf. Applikationen, die Wissen über Reiser4 haben, können mittels des Reiser4-Systemaufrufes direkt mit dem Reiser4-Dateisystem kommunizieren, und so zum Beipsiel auch deutlich komplexere Dateioperationen atomar gestalten, so könnte zum Beispiel ein simples Datenbanksystem atomar Änderungen in vielen verschiedenen Dateien durchführen, ohne diese Atomizität z.B. mittels Locks o.ä. selber zu implementieren. Die Datenbank könnte, salopp gesagt, befehlen: "Bitte führe folgende Befehle in einer einzigen atomaren Transaktion aus: Öffne Datenbankindex, schreibe, schließe Index, lege neues Verzeichnis an, lege darin Dateien 1, 2 und 3 an, öffne 2, schreibe, schließe 2. Ende der Transaktion." Mittels des Reiser4-Systemaufrufes könnte man praktisch Datenbanktransaktionen direkt auf Dateisystemtransaktionen abbilden. Bisherige dateisystembasierte Datenbanken sind ja immer eher langsam, weshalb die meisten Datenbanken die Möglichkeit vorsehen, ihre Daten selber direkt auf einer rohen Partition ohne Dateisystem zu verwalten, oder zumindest innerhalb einer einzigen großen Binärdatei. Mit Reiser4 und einer darauf abgestimmten Datenbank würde ich gerne mal einen Benchmark gegen die arrivierten Platzhirsche MySQL, PostgreSQL, IBM DB2 UDB, Oracle und Co. sehen.

jwm

[
| Versenden | Drucken ]
  • 0
    Von Heinrich am Fr, 20. August 2004 um 01:09 #
    Und was ist daran jetzt so neu?
    Das ging ausch schon früher indem du direkt am VFS vorbei direkt per Systemaufruf mit dem Dateisystem interagiert hättest. Nur hast du (bzw. deine Applikation) dann halt das Problem, dass deine Applikation nur dann funktioniert wenn dein Anwender auch das von dir verwendete Dateisystem einsetzt.
    Würde z.B. Oracle für seine Datenbank die von dir beschriebenen "Features" verwenden, müsstest du zwingen ReiserFs verwenden um darauf deine Datenbank laufen zu lassen. Sinnvoll? Eher nicht.

    > ein weiterer interessanter Aspekt von ${DATEISYSTEM} ist der
    > ${DATEISYSTEM}-Systemaufruf [, der direkt am VFS vorbei die Kernel(-modul) Aufrufe verwendet].
    > Applikationen, die Wissen über ${DATEISYSTEM} haben, können mittels des
    > ${DATEISYSTEM}-Systemaufrufes direkt [und unter Umgehung des VFS Layer] mit
    > dem ${DATEISYSTEM}-Dateisystem kommunizieren.

    [
    | Versenden | Drucken ]
0
Von anonymous am Do, 19. August 2004 um 23:03 #
Die CPU-Last! Wahnsinn wie die hochgeht, egal ob 3 oder 4.

Ausserdem hatte ich zu Anfangszeiten (als die erste Suse-Distri mit Reiser rauskam) einen Totalausfall nachdem ich täglich meinen Reset-Knopf drückte. Das machte ich nämlich 3 Tage lang. Dann wars vorbei.

Also ext3 (weils die meisten Tools unterstützen und in RH/Fedora Standard ist) oder, nachdem ich lernte ne Fedora2-CD mit Parameter "linux xfs" zu booten, eben XFS.

JFS ist in der Mitte. Als die 1.0er rauskam, patchte ich den Vanilla-Kernel von Slackware und es lief ganz toll. Bis ich's mal wieder als
Default-FS einsetzte und ständig mit ISO-Codepages Probleme hatte. Ausserdem war ein Verzeichnis mal weg als ich mit dem 2.6er Kernel & S-ATA Probleme hatte. Ext3 (war vorher das FS) überlebte meine 2.6er/S-ATA Versuche. Nach dem Wechsel zu JFS war eben dieses eine Verz. futsch als ich wg. 2.6er/S-ATA öfter mal den Reset-Knopf drücken musste.

Also wieder zurück zu ext3, die nächste Neuinstallation wird (wie auf'm Laptop schon geschehen) eine mit XFS.

Reiser ist gestorben weils den Eindruck von "Frickel-Software" hinterlassen hat. So "möchtegerns" find ich sind die Leute. Ich vergleich die mal mit der Lindows-Crew im Distribereich ;-)

[
| Versenden | Drucken ]
  • 0
    Von Heinrich am Fr, 20. August 2004 um 00:53 #
    >
    > Die CPU-Last! Wahnsinn wie die hochgeht, egal ob 3 oder 4.
    >
    Rechnerbeschreibung? Durchgeführte Aktionen? Und wie hoch war die CPU-Last? Nur bei besagten Aktionen oder auch, wenn der Rechner "idle" war?
    Ohne genauere Beschreibung sind solche "dahingekotzten" Aussagen nichts wert.


    > Ausserdem hatte ich zu Anfangszeiten (als die erste Suse-Distri mit Reiser
    > rauskam) einen Totalausfall nachdem ich täglich meinen Reset-Knopf
    > drückte. Das machte ich nämlich 3 Tage lang. Dann wars vorbei.
    Aus der Beschreibung geht jetzt nicht hervor, ob du wegen Reiser den Reset-Knopf drücken musstest.
    Und überhaupt: Keines der Journalling Dateisysteme (weder Reiser, Ext3, JFS, XFS, VxFS, ...) schützt dich vor Datenverlust oder Totalausfall. Es stellt durch atomizität und Journal lediglich sicher, dass die Daten die geschrieben wurde in einem konsistenten Zustand sind.

    > Also ext3 (weils die meisten Tools unterstützen und in RH/Fedora Standard ist)
    Welche Tools brauchst du denn, die direkt am VFS vorbei aufs Dateisystem zugreifen?

    > Ausserdem war [mit JFS] ein Verzeichnis mal weg als ich mit dem
    > 2.6er Kernel & S-ATA Probleme hatte.
    Das kann dir mit jedem Dateisystem passieren, wenn der Treiber deines Festplattencontrollers sch*** baut.

    > Ext3 (war vorher das FS) überlebte meine 2.6er/S-ATA Versuche.
    Zufall.

    > Nach dem Wechsel zu JFS war eben dieses eine Verz. futsch als ich
    > wg. 2.6er/S-ATA öfter mal den Reset-Knopf drücken musste.
    Aha, also schon wieder selbst verschuldet. (siehe oben; Datensicherheit bei Journalling Fs)

    > Also wieder zurück zu ext3, die nächste Neuinstallation wird (wie auf'm Laptop
    > schon geschehen) eine mit XFS.
    ...bis du auch dort öfter mal den Reset-Schalter drücken musst oder dir mitten im Betrieb mal ein paar Mal der Akku versagt. Dann wird früher oder später (abhängig davon, wie viele Daten zu diesem Zeitpunkt noch nicht auf die Festplatte geschrieben waren) auch $DATEISYSTEM bei dir Probleme bereiten.

    > Reiser ist gestorben weils den Eindruck von "Frickel-Software" hinterlassen hat.
    > So "möchtegerns" find ich sind die Leute. Ich vergleich die mal mit der
    > Lindows-Crew im Distribereich
    Frickel-Software weil dein SATA-Controller Probleme bereitet?
    Frickel-Software weil du damals als SuSE vor allen anderen Distributoren vorgeprescht ist und ReiserFs als Default-Fs installiert hat, Probleme mit dem damaligen von SuSE gepatchen ReiserFs-Kernel hattest?

    [
    | Versenden | Drucken ]
    • 0
      Von fuffy am Fr, 20. August 2004 um 09:52 #
      ReiserFS 3.6 hat mir schon mehrere Dateisysteme bei Stromausfall oder nem Abbruch von VMware Workstation (durch X-Server Crash) geplättet.
      Nach dem notwendigen reiserfsck --rebuild-tree war das Dateisystem komplett leer. Ich hätte genauso gut mit mkreiserfs ein neues Dateisystem anlegen können. Das wäre sogar schneller gewesen. Die Daten waren sowieso alle weg. :-(

      Seitdem läuft bei mir auf den meisten Partitionen ext3. Das hat sogar meine Experimente mit dem 2.6.6 ohne Datenverlust überlebt, der mir auf meinem Board mit NVIDIA-Chipsatz ständig abgestürzt ist. :-)

      Wenn Reiser4 mal im 2.6.x angelangt ist, werde ich das natürlich auch testen. Laut Aussagen von Hans Reiser ist Reiser4 ja schon heute stabiler als ReiserFS 3.6. Das sagt über die Stabilität von ReiserFS 3.6 einiges aus. ;-)

      [
      | Versenden | Drucken ]
0
Von egal am Do, 19. August 2004 um 23:11 #
Ich habe mehr (!) als einmal live und
in farbe miterleben müssen, wie ein reiserfs jenseits der 200 GB versagt.
Aller performace zum trotz kann ich für mich persönlich sagen : ich liebe die alt-eingesessenen inode-basierten dateisysteme, seien es ext2/ext3 unter linux oder ffs/ufs unter bsd.
Ich will kein reiser, auch nicht in version 4.
Danke.
[
| Versenden | Drucken ]
  • 0
    Von Theile am Do, 19. August 2004 um 23:33 #
    *lol*

    Ja und? Zwingt Dich doch auch keiner es einzusetzen wenn Du es nicht willst.

    *Kopfschüttel*

    bis denne
    theile

    [
    | Versenden | Drucken ]
    0
    Von Heinrich am Fr, 20. August 2004 um 00:55 #
    > ich liebe die alt-eingesessenen inode-basierten dateisysteme,
    > seien es ext2/ext3 unter linux oder ffs/ufs unter bsd.
    > Ich will kein reiser, auch nicht in version 4.
    >
    Seit wann verwendet ReiserFs denn keine Inodes mehr? Bitte um Aufklärung, du scheinst mehr zu wissen als wir.
    [
    | Versenden | Drucken ]
0
Von Jörg W Mittag am Do, 19. August 2004 um 23:22 #
Hi,

ein - wie ich finde - ziemlich cooles Feature von Reiser4 sind die Plugins. Es ist ja nicht nur so, dass man Reiser4 mit Plugins erweitern kann, sondern sogar die Basisfunktionen des Dateisystems selbst sind "nur" Plugins, nämlich das 'unix_file'- und das 'unix_dir'-Plugin, welche die grundlegende Unix-Dateisystem-Semantik bereitstellen.

Überhaupt ist die Schichtenarchitektur recht interessant und erinnert mehr an den Aufbau eines Datenbanksystems als an ein klassisches Dateisystem: es gibt zwei völlig getrennte Schichten, die Speicherschicht und die Semantikschicht. Die Speicherschicht kümmert sich nur darum, wie Objekte auf der Festplatte abgelegt werden, während sich die Semantikschicht ausschließlich darum kümmert, wie die Objekte dem Benutzer präsentiert werden. Die beiden Schichten sind komplett voneinander getrennt. Und beide Schichten werden eigentlich komplett durch Plugins gebildet. Die Speicherplugins legen zum Beispiel fest, wie die Objekte auf der Festplatte angeordnet werden. So könnte man z.B. unterschiedliche Anordnungs-Plugins für /bin, /lib, oder /usr/src verwenden, die die Anordnung der Dateien jeweils für schnelles Starten oder schnelles Kompilieren optimieren.

Ein anderes interessantes Konzept klingt im vorigen Absatz schon durch, denn ich habe mit Absicht den Begriff "Objekt" statt "Datei" verwendet. Reiser4 ist komplett objektbasiert, tatsächlich hat Reiser4 überhaupt gar keine Ahnung, was eine "Datei", ein "Verzeichnis", ein "Zugriffsrecht", ein "Eigentümer", eine "Gruppe" o.ä. eigentlich ist. Alles ist ein Objekt. Diese Objekte haben übrigens auch keinen Namen sondern lediglich eine eindeutige ID. Diesen Objekten eine Semantik (Bedeutung) zu verleihen, ist Aufgabe der Semantik-Plugins. Das unix_file-Plugin ist dafür da, ein Objekt als Unix-Datei zu interpretieren, das unix_directory-Plugin dementsprechend für eine Interpretation als Unix-Verzeichnis und auch für die Zuordnung von Namen zu IDs.

Die Plugins spielen auch eine wichtige Rolle bei der Umsetzung des Konzeptes "Alles ist eine Datei". Dieses Konzept ist ja ein grundlegendes Konzept von Unix, aber in Wirklichkeit ist es mehr eine Illusion, denn es gibt vieles, was keine Datei ist. Dateimetadaten sind zum Beispiel keine Dateien. Verzeichnisse sind auch keine Dateien. Zumindest bisher, denn bei Reiser4 ist das anders. Jedes Verzeichnis ist auch eine Datei, und diese Datei kann man öffnen und sie enthält dann den Inhalt aller Dateien, die in dem Verzeichnis enthalten sind. Um die Benutzer nicht zu verwirren, tauchen diese Pseudo-Dateien allerdings bei einem readdir() und damit auch einem ls nicht auf, aber man kann sie öffnen. Umgekehrt ist jede Datei auch ein Verzeichnis. Diese Pseudo-Verzeichnisse tauchen ebenfalls nicht auf, aber man kann mittels cd in sie wechseln. Dieses Verzeichnis enthält dann wiederum ein Verzeichnis namens 'metas' (dieses Unterverzeichnis haben nicht nur Dateien sondern auch Verzeichnisse) und dieses Verzeichnis enthält dann wiederum andere Pseudo-Dateien und -Verzeichnisse mit Metadaten. Oben schrieb ich, dass in klassischen Unix-Dateisystemen z.B. Metadaten keine Dateien sind. Das kann man leicht sehen, wenn man bestimmte Metadaten, z.B. Zugriffsrechte verändern will - mit Dateioperationen geht das nicht, weil es eben keine Dateien sind, man benötigt Spezialwerkzeuge dafür: chmod. Nicht so bei Reiser4, ein simples 'echo 0644 > /etc/passwd/metas/rwx' reicht aus. Ähnlich funktioniert das auch mit dem Eigentümer oder der Gruppe. Bye, bye GNU coreutils! Hans Reiser ist ein großer Fan dieses Konzeptes, wie man auch an seiner fast schon fanatischen Weigerung, Reiserfs Erweiterte Attribute oder Access Control Lists zu verpassen, wie sie inzwischen alle anderen Dateisysteme haben - er ist sogar so stark dagegen, dass er beinahe seinen Status als Maintainer des Reiserfs im Linux-Kernel verloren hätte, weil er sich geweigert hatte, die schon seit vielen Jahren erfolgreich im Einsatz befindlichen und gut getesteten diesbezüglichen Patches von SuSE zu akzeptieren. Wenn man Reiser4 sieht, dann weiß man, dass er tatsächlich Recht hat: wozu braucht man ACLs oder Erweiterte Attribute (für die man dann wiederum Extra-Werkzeuge, wie {get,set}facl, {get,set}fattr braucht), wenn man das ganze auch einfach als Datei haben kann?

Man kann das aber noch weiter treiben. Es wäre zum Beispiel möglich, ein Semantik-Plugin zu schreiben, welches die innere Struktur einer Word-Datei versteht. Der ahnungslose OpenOffice-Anwender, der keine Ahnung von Reiser4 hat, öffnet die Datei /home/joerg/dokument.doc, um in den Dateieigenschaften nachzusehen, wie der Titel des Dokumentes lautet. Der schlaue Reiser4-Anwender gibt stattdessen einfach 'cat /home/joerg/dokument.doc/metas/plugins/word-doc/title' ein. In der Datei 'ascii' findet er eine ASCII-Repräsentation des Textes, in 'author' steht der Autor und die Dokumentenstruktur könnte man zum Beispiel in Verzeichnissen abbilden: dokument.doc/metas/plugins/word-doc/structure/page_3/paragraph_2/ascii würde dann den Text des zweiten Absatzes der dritten Seite enthalten. Anmerkung: ich spinne hier nur rum, ich kann mir nicht vorstellen, dass jemals jemand ein solches Plugin schreibt. Eine andere verrückte Idee wäre ein MySQL-Plugin, welches es ermöglicht, auf Tabellen, Spalten, Zeilen, Felder, Werte u.s.w. jeweils als Datei zugreifen zu können. Es gibt wohl tatsächlich Leute, die über die Implementierung eines Datenbank-Backends als Reiser4-Plugin nachdenken.

jwm

[
| Versenden | Drucken ]
  • 0
    Von JJ am Do, 19. August 2004 um 23:55 #
    > Bye, bye GNU coreutils!

    Wohl kaum. Eher ein ln -s auf einen Stapel Skripte, würde ich sagen, denn nicht alle Shells kennen ja Aliase.
    Was die acls angeht, war das Problem nicht deren Unterstützung, sondern die Umsetzung. Bei rsf4 werden sie halt als Metadaten gespeichert - mit der gleichen Schnittstelle, wie die normalen Attribute. Bei anderen fs gibt es dafür wieder ein extra Interface und das ist hr so sauer aufgestoßen, da alle Programme somit noch ein weiteres Interface unterstützen müssen.

    [
    | Versenden | Drucken ]
    • 0
      Von Jörg W Mittag am Fr, 20. August 2004 um 03:33 #
      Ich bin mir jetzt nicht sicher, ob wir das gleiche meinen oder aneinander vorbei reden, daher ein Versuch der Klärung:

      > Was die acls angeht, war das Problem nicht deren Unterstützung, sondern die Umsetzung. Bei rsf4 werden sie halt als Metadaten gespeichert

      Bei Reiser4 ist gerade das geniale, dass es keine Daten, Metadaten, Attribute, Erweiterte Attribute, ACLs oder was auch immer gibt, sondern nur Dateien. Sonst nichts.

      - mit der gleichen Schnittstelle, wie die normalen Attribute.

      Genau. Da alles sowieso nur Dateien sind, hat alles dieselbe Schnittstelle: die Daten, die Metadaten, die Attribute, Erweiterte Attribute, ACLs, Security Labels und was es sonst noch so alles gibt, und natürlich auch die Datei selbst und sogar Verzeichnisse: alles sind einfach nur Dateien, sonst nichts. Oder mit anderen Worten, wenn man das alte Unix-Motto "Alles ist eine Datei" wirklich ernst nimmt, dann müssten sich sämtliche Aktionen im System nur mit cat und echo erledigen lassen. (Das ist jetzt natürlich stark übertrieben, genauso wie mein Coreutils-Kommentar vorher, aber ich hoffe, es zeigt, was ich meine.) Reiser4 kommt diesem Ideal ziemlich nahe, näher jedenfalls als sämtliche Datei- und Betriebssysteme, die ich sonst so kenne - zumindest soweit Reiser4 da einen Einfluss drauf hat. Dass das Motto zum Beispiel für Netzwerk-Sockets ebenfalls nicht gilt, daran kann Reiser4 nichts ändern[1].

      > Bei anderen fs gibt es dafür wieder ein extra Interface und das ist hr so sauer aufgestoßen, da alle Programme somit noch ein weiteres Interface unterstützen müssen.

      Jepp. Bei Reiser4 gibt es grundsätzlich immer nur eine Schnittstelle: die Datei. Egal um was es geht, seien das ACLs, XATTRs oder irgendwas, was erst in ferner Zukunft erfunden wird.

      jwm

      [1] Off-Topic: Wohl aber kann daran die KSH etwas ändern, mit ihren /dev/{tcp,udp}/-Pseudoverzeichnissen, wo man z.B. einen simplen Web-Browser mittels 'exec 5<>/dev/tcp/`host -q www.pro-linux.de | cut -f 3`/80 && echo -e "GET / HTTP/1.0\n" >&5 && cat <&5 | sed 's/<.*>//g' | uniq | less' implementieren kann. Funktioniert neben der KSH unter allen Shells, die KSH-ähnliche Netzwerkfunktionen besitzen, z.B. Bash. (In der Bash geht's sogar noch einfacher, weil die außer IP-Adressen auch Hostnamen versteht.)

      [
      | Versenden | Drucken ]
    0
    Von Andre Homberg am Fr, 20. August 2004 um 09:36 #
    Hi,
    klasse beitrag, thnxs :)

    Andre

    [
    | Versenden | Drucken ]
    0
    Von thomas001 am Mo, 23. August 2004 um 00:25 #
    ein plugin fuer word docs haette ich aber bitte nicht im kernel sondern im userspace,auch wenn es langsamer ist, ist es doch entschieden sicherer.
    [
    | Versenden | Drucken ]
0
Von arni am Fr, 20. August 2004 um 11:36 #
Meine Erfahrungen mit Reiserfs waren leider auch nicht die Besten. Schön öfter mal passiert das Daten verschwunden waren, aber noch im Dateisystem als existent angezeigt wurden. Beim nächsten Reboot waren sie dann endgültig verschwunden *g*

Ne, Reiserfs werde ich nicht mehr auf meine Platten lassen egal ob es vielleicht 10% performanter als ext3 ist oder sonst irgendwelche Super-Duper Funktionen hat.

[
| Versenden | Drucken ]
  • 0
    Von Andre am Fr, 20. August 2004 um 12:04 #
    Hi,
    also ich hab noch keinerlei probleme mit datenverlusten auf reiserfs gehabt, und setze es seit kernel 2.4.1 auf mehreren maschienen ein. auch mehrere fileserver server laufen hier stabil auf reiserfs (kernel 2.4.x / reiserfs 3.6).

    gruss,
    Andre Homberg

    [
    | Versenden | Drucken ]
0
Von Andreas am Fr, 20. August 2004 um 12:48 #
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.8.1/2.6.8.1-mm2/

Welchen Patch soll man nehmen bzw wo sind die Unterschiede ?

[
| Versenden | Drucken ]
  • 0
    Von El Macho am Sa, 21. August 2004 um 01:53 #
    den hier: 2.6.8.1-mm2.bz2 bzw. 2.6.8.1-mm2.gz
    broken-out enthält dasselbe nur als viele Einzelpatche
    [
    | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung