Archiv verlassen und diese Seite im Standarddesign anzeigen : Vorteile von ReiserFS
puntarenas
2008-07-08, 21:47:28
Vorteile im Vergleich wozu?
Wenn du ernsthaft Hilfe bei der Auswahl deines Dateisystems erhalten möchtest, dann speise uns bitte nicht mit einem Einzeiler ab. :smile:
http://en.wikipedia.org/wiki/ReiserFS
Benedikt
2008-07-08, 22:09:02
Wahrscheinlich hat er halt News über Hans Reiser gelesen.
ReiserFS stirbt zunehmend.
puntarenas
2008-07-08, 22:11:59
Stimmt schon, seine besten Zeiten hatte es wohl, als es bei Suse noch das Standarddateisystem war. Allerdings ändert dies ja nichts daran, dass zumindest ReiserFS 3 mittlerweile recht ausgereift ist, im Standardkernel enthalten ist und gerade bei vielen kleinen Dateien immer noch gute Leistungen erbringt.
Benedikt
2008-07-08, 23:37:58
Stimmt schon, seine besten Zeiten hatte es wohl, als es bei Suse noch das Standarddateisystem war. Allerdings ändert dies ja nichts daran, dass zumindest ReiserFS 3 mittlerweile recht ausgereift ist, im Standardkernel enthalten ist und gerade bei vielen kleinen Dateien immer noch gute Leistungen erbringt.
Es wird aber trotzdem, so habe ich gelesen, nicht mehr in dem Maß gepflegt wie die anderen Linux-Dateisysteme.
Es wird aber trotzdem, so habe ich gelesen, nicht mehr in dem Maß gepflegt wie die anderen Linux-Dateisysteme.Es kommt doch nur drauf an welche Bugs es hat, welche Features und welchen Speed im Vergleich mit anderen Dateisystemen.
Die Pflege ist erstmal zweitranging. Leistung und Zuverlässigkeit sind ausschalggebend.
Jemand eine Seite die sich genau damit beschäftigt? :)
Wenn das allerbester Dateisystem aus den achtziogen stammen würde, ich würde es trotzdem und immernoch benutzen ;)
BH
Es kommt doch nur drauf an welche Bugs es hat, welche Features und welchen Speed im Vergleich mit anderen Dateisystemen.
Die Pflege ist erstmal zweitranging. Leistung und Zuverlässigkeit sind ausschalggebend.
Jemand eine Seite die sich genau damit beschäftigt? :)
Ich hab absichtlich den englischen Wiki Artikel verlinkt und ned den deutschen weils dort nicht so genau steht
im englischen stehen die Features und auch etwas zur Performance
Das Hauptfeature von ReiserFS ist halt das Tail Packing also das zusammenfassen von mehreren kleinen Dateien in einen Cluster
Ansonsten gibts neben ext2/ext3 ja auch noch XFS
Crazy_Chris
2008-07-09, 14:27:56
Reiser FS ist ein Mords Filesystem. :wink:
BoRaaS
2008-07-09, 15:02:36
Reiser FS ist ein Mords Filesystem. :wink:
*gähn* selten so gelacht.
Nimm ext3, bald ext4.
Begründung?
Warum kein XFS oder ReiserFS 3 oder Reiser4?
XFS hat zB. wie ext4 haben wird extents, delayed allocation und pre allocation
und im gegensatz zu ext4 wo es nur geplant ist hat XFS einen Online Defragmentierer xfs_fsr
Bei Reiser4 war/ist? das ja auch geplant aber bis heute gibts das nicht soweit ich weiß
Die englischen Wiki Artikel zu den Filesystem sind ausführlicher wie die deutschen.
Lokadamus
2008-07-09, 16:26:11
Begründung?
Warum kein XFS oder ReiserFS 3 oder Reiser4?mmm...
Bei XFS sind alle Daten weg, die während eines Stromausfalls offen sind.
ReiserFS3 hat Bugs (treten selten auf) und wird nicht mehr weiterentwickelt.
Reiser4 wird nur im kleinen Kreis weiterentwickelt.
Ein Hauptgrund, warum Reiserfs3 nicht im Kernel drinne sein sollte, war der dreckige Sourcecode, den man nicht leicht lesen und damit auch nicht leicht verstehen kann.
Als FS würde ich wohl auch eher Ext3 bzw. 4 vorschlagen, obwohl das ein langsames FS ist. Dafür ist es stabil und wird auch weiterentwickelt.
ZFS gibt es nicht unter Linux, wäre ansonsten interessant.
mmm...
Bei XFS sind alle Daten weg, die während eines Stromausfalls offen sind.
Delayed Allocation ist bei ext4 standardtmäßig an
Bei nem crash ist sowieso nicht immer garantiert das alle Daten gesichert werden die kurz vorher geschrieben werden sollten, außer man ruft fsync() bzw. fdatansync() auf und dann spielt es überhaupt keine Rolle was für ein Dateisystem man nutzt und ob es Delayed Allocation hat oder nicht.
Delayed Allocation machts halt nicht besser aber eigentlich auch nicht soviel schlimmer
Lokadamus
2008-07-09, 22:40:20
Delayed Allocation ist bei ext4 standardtmäßig anmmm...
Das ist nicht das Problem bei XFS, sondern dass es viele der offenen Dateien gerne nullt.
Auf die schnelle hab ich bei Google dazu nur diesen Kommentar (http://de.nntp2http.com/sci/electronics/2008/05/2bfcb5e7a264397c26834a4a2ffda165.html) gefunden, im Heiseforum wurde das aber auch schon mal erwähnt.
(del)
2008-07-09, 22:51:25
"(nullt gerne Dateien die per Journal nicht mehr widerhergestellt werden koennen)"
:|
bluey
2008-07-09, 23:01:38
Gibt ja nichtmal eine Möglichkeit um gelöschte Daten wiederherzustellen.
Gibt ja nichtmal eine Möglichkeit um gelöschte Daten wiederherzustellen.
Nunja, braucht man ja nicht unbedingt für wichtige Dateien sollte man immer Backups machen ...
"(nullt gerne Dateien die per Journal nicht mehr widerhergestellt werden koennen)"
:|
Also bei Wiki steht
Eine an einen Fehlerfall anschließende Überprüfung des Dateisystems wird jedoch zumindest eine Konsistenz wiederherstellen und Datenbereiche, die nicht geschrieben werden konnten, durch Nullen auffüllen. Dadurch sind mögliche Fehler durch „Datenreste“ ausgeschlossen.
Klingt für mich doch eher Sinnvoll?
mmm...
Das ist nicht das Problem bei XFS, sondern dass es viele der offenen Dateien gerne nullt.
Hab jetzt XFS bisher nicht so viel im Einsatz gehabt, aber warum sollten offene Dateien genullt werden?
Zumindest versteh ich dich so, das zB. auch eine Datei die nur readonly geöffnet wurde und somit überhaupt nicht geändert worden ist nach einem Crash plötzlich leer ist bzw. eben nur aus nullen besteht
oder hab ich dich da jetzt falsch verstanden?
So wie das bei Wiki verstehe, heißt das doch wenn kurz vor einem Crash eine Datei vergrößert wurde das es dann sein kann dass das was in die Datei NEU hinzugekommen ist genullt sein kann, aber nicht die komplette Datei.
Lokadamus - nixBock
2008-07-10, 08:38:46
Eine an einen Fehlerfall anschließende Überprüfung des Dateisystems wird jedoch zumindest eine Konsistenz wiederherstellen und Datenbereiche, die nicht geschrieben werden konnten, durch Nullen auffüllen. Dadurch sind mögliche Fehler durch „Datenreste“ ausgeschlossen.
Klingt für mich doch eher Sinnvoll?mmm...
Nein, einfaches Beispiel: Fat32 und chkdsk. Mit chkdsk konnte man Dateifragmente wieder zusammenfassen lassen. Sie hatten war keinen brauchbaren Namen und waren meistens auch unnütz, aber falls man was wichtiges gesucht hat, konnte man sie wenigstens versuchen wieder zu finden.
Der Lost+Found- Ordner von Ext2 ist so ähnlich ;).
Durch das Nullen "vernichtest" du aufjedenfall den Inhalt.Hab jetzt XFS bisher nicht so viel im Einsatz gehabt, aber warum sollten offene Dateien genullt werden?
Zumindest versteh ich dich so, das zB. auch eine Datei die nur readonly geöffnet wurde und somit überhaupt nicht geändert worden ist nach einem Crash plötzlich leer ist bzw. eben nur aus nullen besteht
oder hab ich dich da jetzt falsch verstanden?
So wie das bei Wiki verstehe, heißt das doch wenn kurz vor einem Crash eine Datei vergrößert wurde das es dann sein kann dass das was in die Datei NEU hinzugekommen ist genullt sein kann, aber nicht die komplette Datei.Ja, so hab ich das Problem verstanden. Selbst die Dateien, nur zum Lesen geöffnet sind, können nach einem Stromausfall genullt werden, weil das Journal sich nicht sicher ist, was Sache ist.
Den Wikipedia- Text hab ich jetzt nicht gelesen (und momentan auch gar keine Zeit dafür). Vielleicht hat jemand eine Testkiste da, wo man mal den Stromstecker ziehen kann und XFS so testen. Ein Bekannter hat es mal getestet und Endresultat war, dass ein Stromausfall für XFS tödlich ist, sprich, vieles war genullt. Durch ein Skript, was alle paar Sekunden für den Datenabgleich sorgt, soll es gut sein, aber naja ;) ...
Was ich eigentlich nur posten wollte, war dieser kleine Link, ein kurzer Überblick über ein paar FS: http://arstechnica.com/articles/paedia/past-present-future-file-systems.ars ...
Ja, so hab ich das Problem verstanden. Selbst die Dateien, nur zum Lesen geöffnet sind, können nach einem Stromausfall genullt werden, weil das Journal sich nicht sicher ist, was Sache ist.
Den Wikipedia- Text hab ich jetzt nicht gelesen (und momentan auch gar keine Zeit dafür). Vielleicht hat jemand eine Testkiste da, wo man mal den Stromstecker ziehen kann und XFS so testen. Ein Bekannter hat es mal getestet und Endresultat war, dass ein Stromausfall für XFS tödlich ist, sprich, vieles war genullt. Durch ein Skript, was alle paar Sekunden für den Datenabgleich sorgt, soll es gut sein, aber naja ;) ...
Das dürfte dann aber ein ziemlicher Bug im Linuxcode sein, den wohl scheinbar niemand reported hat oder wohl nicht so ganz leicht zu beheben
Da XFS ja von IRIX stammt, wurde es ja mehr im professionellen Umfeld verwendet als im normalen Homebereich
Ich kann mir nicht vor stellen das XFS so designed worden ist das selbst readonly geöffnete Dateien genullt werden
Kann natürlich auch gut bei den IRIX Nutzern sein das die XFS ned soviel verwedet haben und wenn se den Bug bemerkt haben einfach ein anderes Dateisystem verwendet haben anstatt das zu reporten
Da es XFS ja schon seit 94 gibt, sollte der Code eigentlich ja ausgereift sein, nur im Linuxkernel ist es halt noch ned so lang drin.
da.phreak
2008-07-10, 09:09:51
Das hört sich komisch an. Ich habe XFS auf allen Systemen im Einsatz, und es macht auf mich einen ziemlich robusten Eindruck. Genullte Dateien hatte ich bisher nicht. ReiserFS habe ich vorher lange benutzt. Es ist in vielen Fällen schneller, macht aber einen weniger robusten Eindruck.
Trotzdem gilt für Dateisysteme mit Journal: Es wird nur die Integrität des Dateisystems garantiert, nicht daß alle Daten hinterher noch da sind.
Warum alle Welt ext2/ext3 benutzt ist mir unklar. Bei ext3 hat man ein Journal irgendwie drangebastelt. Mir ist ein Dateisystem lieber, wo das von vornherein geplant war. Für Datenaustausch mit Windows-Systemen ist es allerdings ideal.
mmm...
Nein, einfaches Beispiel: Fat32 und chkdsk. Mit chkdsk konnte man Dateifragmente wieder zusammenfassen lassen. Sie hatten war keinen brauchbaren Namen und waren meistens auch unnütz, aber falls man was wichtiges gesucht hat, konnte man sie wenigstens versuchen wieder zu finden.
Der Lost+Found- Ordner von Ext2 ist so ähnlich ;).
Durch das Nullen "vernichtest" du aufjedenfall den Inhalt
Ja gut wenn einem die Daten wirklich wichtig sind und man Wert auf ein robustes FS legt und Performance unwichtig ist, dann ist wohl ext3 (und wenn ext4 stable genug is dann das, da es Checksummen beim Journal verwendet) mit data=journal gemounted das Sicherste
Exxtreme
2008-07-10, 12:23:45
Also mit ReiserFS hatte ich schonmal das Problem, daß Teile des Dateisystems nicht mehr lesbar waren. Von daher beutze ich es nie mehr.
Also mit ReiserFS hatte ich schonmal das Problem, daß Teile des Dateisystems nicht mehr lesbar waren. Von daher beutze ich es nie mehr.
Hat danach ein fsck.reiserfs --rebuild-tree geholen oder hast du es garnicht erst versucht?
ich glaub je nach zweck, sollen es viele kleine datein sein > reiserfs > solls sicher sein ext ... usw...
puntarenas
2008-07-12, 14:55:14
Comparison of file systems (http://en.wikipedia.org/wiki/Comparison_of_file_systems)
Der Wikiartikel war hier vorher auch schon mal verlinkt, allerdings in einer eigenwilligen Fassung, die Opfer von Vandalismus geworden ist.
http://oss.sgi.com/archives/xfs/
Einfach die [Threads] durchgehen. Ich hab es mit den vorletzten Buntus maltrietiert und XFS lief hier absolut perfekt. Man muß sich mal entsprechende Archive zu anderen Dateisystemen angucken :D
Die Kerneltruppe sollte sich nur bisschen mehr drum kümmern und nicht immernoch so vorzugsweise bei der Ext-Truppe schleimen :mad:
BH
p.s.:
Was steht denn da als Fixed für März 2007?? :tongue:
http://oss.sgi.com/projects/xfs/
So ist das in den Foren. Es wird viel geschlabbert und nachgeplappert, aber die Mühe etwas selbst herauszufinden machen sich die wenigsten :mad:
Ah also wurde doch der Bug offiziell anerkannt und vor über einem Jahr bereits behoben.
Hätt mich jetzt auch schon gewundert, wenn der Bug heute noch auftreten würde.
Dann spricht ja garnicht soviel gegen XFS :)
(del)
2008-07-12, 17:44:24
Dann spricht ja garnicht soviel gegen XFS :)XFS ist (imho) mittlerweile das beste Dateisystem für ein HomeLinux. Egal was man damit anstellt bzw. in der Lage ist damit daheim anzustellen.
Bis es einen 100%-port von ZFS gibt (falls), gibt es für mich keine Alternativen. Es ist sehr schnell, robust und das "features set" ist mehr als ansehlich. Früher war für mich JFS die erste Wahl. XFS ist aber mittlerweile auch wesentlich leistungsfähiger.
Reiser ist teilweise nochmals schneller und mit vielen sehr interessanten Features, aber es fehlte schon immer das letzte Quäntchen von Robustheit. Wenn man schon die Wahl unter mehreren Dateisystemen hat bedeutet das leider für gewöhnlich ein NoGo.
Ext war für mich schon früher immer nur das notwendige Übel. Zum Glück hat sich XFS zwar langsam aber sehr schön entwickelt.
Mit den Altixs die SGI mit Linux betreibt ging es zwangsweise auch mit XFS aufwärts. Schöne Sache sowas ;)
edit:
Warum sich wirklich alles schnell und großartig weiterntwickeln muß ist mir meist ein Rätsel. Bei Dateisystemen verstehe ich es garnicht. Durchdachte, bedacht vorsichtige, beständige Entwicklung sollte bei einem Dateisystem imho die absolute Priorität haben. Das versteht selbst Mickeysoft...
bluey
2008-07-12, 17:46:56
Bis es einen 100%-port von ZFS gibt (falls), gibt es für mich keine Alternativen. Es ist sehr schnell, robust und das "features set" ist mehr als ansehlich. Früher war für mich JFS die erste Wahl. XFS ist aber mittlerweile auch wesentlich leistungsfähiger.
eod
Auf ZFS kann man lange warten. Meine Hoffnung liegt da eher an BTRFS von Oracle.
(del)
2008-07-12, 17:55:59
Auf ZFS kann man lange warten. Meine Hoffnung liegt da eher an BTRFS von Oracle.v0.15 Released (May 29, 2008) ;) Auf BTRFS kannst du lange warten :tongue: Bis dahin kann man daheim mit XFS wunderbar leben.
v0.15 Released (May 29, 2008) ;) Auf BTRFS kannst du lange warten :tongue: Bis dahin kann man daheim mit XFS wunderbar leben.
v 0.15 von was?
Beim englischen Wiki ZFS Artikel ist ZFS on FUSE verlinkt und das hat Version 0.4.0 beta1
https://developer.berlios.de/project/showfiles.php?group_id=6836
Benedikt
2008-07-12, 19:06:37
Funktioniert XFS mittlerweile bei aktuellen Distributionen auch problemlos, wenn /boot auf XFS liegt? Ich glaube, GRUB hatte da mal Problemchen damit. Klappt das ohne Schwierigkeiten?
(del)
2008-07-12, 19:13:27
v 0.15 von was?
Beim englischen Wiki ZFS Artikel ist ZFS:| Von BTRFS.
@Benedikt
Meinst du sowas?
https://bugs.launchpad.net/ubuntu/+source/partman/+bug/16073
http://ubuntuforums.org/showthread.php?t=735974
http://ubuntuforums.org/showthread.php?t=329701
edit:
Nicht immer, aber öfters sieht man, daß es Sachen sind für welche XFS selbst garnichts kann. Weil meist immernoch bei Ext rumgeschleimt wird. Wegen sowas könnte man sich manchmal echt aufregen... ;)
:| Von BTRFS.
Achso, dachte das wär auf ZFS bezogen :)
Funktioniert XFS mittlerweile bei aktuellen Distributionen auch problemlos, wenn /boot auf XFS liegt? Ich glaube, GRUB hatte da mal Problemchen damit. Klappt das ohne Schwierigkeiten?
Sowohl der alte 0.9x GRUB Legacy als auch der neuere GRUB 2 (Versionsnummer aktuell 1.96) hat XFS unterstützung.
Ich hab damit auch keine Probleme gehabt
Benedikt
2008-07-12, 19:30:38
Sowohl der alte 0.9x GRUB Legacy als auch der neuere GRUB 2 (Versionsnummer aktuell 1.96) hat XFS unterstützung.
Ich hab damit auch keine Probleme gehabt
Ja, scheint mittlerweile problemlos zu klappen. Schön. :wink:
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.