Journaling Softupdates für FreeBSD

Yamagi

Yamagi

Possessed With Psi Powers
Teammitglied
Wie sicher bekannt ist, setzen moderne Dateisysteme fast ausschließlich auf zwei Mechanismen, um die Konsistenz des Dateisystem auch über Abstürze und Stromausfälle hinweg sicherzustellen. Der eine Weg ist Journaling. Bildlich gesprochen merkt man sich, was man machen wollte, tritt die Katastrophe ein, ein kann man aus diesem Wissen und dem aktuellen Zustand des Dateisystems einen konsistenten Zustand ermitteln. Das Problem bei diesem Ansatz ist, dass man die Katastrophe akzeptieren muss und lediglich versuchen kann, ihre Folgen wieder aufzuräumen, was nicht zwingend möglich sein muss. FreeBSD bietet zwar seit einiger Zeit ein Journaling an, setzt aber dennoch hauptsächlich auf Softupdates. Dieser Mechnismus hält die Daten auf der Platte atomar konsistent, man muss also nie Fehler beheben. Es bleibt jedoch ein Problem, es kann nicht garantiert werden, dass aller freigegebener Speicher auch als solcher markiert ist. Dies verlangt unter dem Strich wieder ein fcsk, welches im Hintergrund ausgeführt werden kann.

Obwohl Softupdates im Allgemeinen sicherer als Journaling gelten, wurde dies zunehmend zu einem starken Argument gegen sie. Dauert so ein fsck, selbst wenn es im Hintergrund läuft, bei modernen Mediengrößen sehr schnell mehrere Stunden und kostet extrem viel Systemleistung. Aus diesem Grund haben sich Jeff Robertson (SCHED_ULE) und Kirk McKusick (FFS, UFS, Softupdates) Gedanken gemacht, wie man dies Problem lösen kann. Gesponsert durch eine Reihe Firmen (iXsystems, Yahoo, Juniper) entstand so Journaling Softupdates. Hierbei funktionieren die Softupdates wie bisher, all ihre Vorteile bleiben erhalten. Jedoch wird die Freigabe von Speicher in einem Journal vermerkt, dieses ist deutlich kleiner und effizienter als bei echten Journalingdateisystemen, welches beim Neustart nach der Katastrophe genutzt wird, um den fälschlich als belegt markierten Speicher wieder freizugeben. Damit entfällt das fsck, das System ist sofort einsatzbereit.

Diese Arbeit wird in den nächsten Wochen für FreeBSD 9-CURRENT Nutzer freigegeben werden, ob in Form eines Patch oder gar eines Commit ist nicht bekannt. Später soll auf der BSDCan im Frühjahr eine genaue Vorstellung des Mechanismus erfolgen.

Quelle: http://jeffr-tech.livejournal.com/22716.html
 
Aber zur Rettung von Softupdates muß man auch eines bemerken, Linux und seine Journaling-FS kommen auch nicht ohne langwierige Überprüfung aus und sollte man tatsächlich so wagemutig sein diese abzustellen, zahlt man recht schnell die Zeche.
 
mücke schrieb:
Aber zur Rettung von Softupdates muß man auch eines bemerken, Linux und seine Journaling-FS kommen auch nicht ohne langwierige Überprüfung aus und sollte man tatsächlich so wagemutig sein diese abzustellen, zahlt man recht schnell die Zeche.
Zum Vergrößern anklicken....
Hängt IMO stark vom FS und den eingesetzten Anwendungen ab. XFS ist beim fsck z. B. sehr flott, während ext3 je nach Journal Mode mittellang bis ewig braucht. Darüber hinaus verhalten sich die Dateisysteme auch noch sehr unterschiedlich: XFS und JFS z. B. erzwingen nicht wie ext[234] alle n mounts einen check. Die Entwickler gingen wohl aber auch von batteriegepufferten Controllern aus, denn auch ein Journaling FS kann's einem ziemlich leicht in die nächste Galaxie blasen. Die ext-Dateisysteme lassen sich relativ leicht flicken, aber die komplexeren Exemplare sind ziemlich schwer wieder zu fixen, wenn sie erst mal kaputt sind.

Wie man's auch dreht und wendet, am Ende sind Konstrukte wie Softupdates oder Journale nur eine Kompensation für eine miese Architektur, die einfach kein zustandssicheres Abschalten von Festspeichern vorsieht.
 
sniket schrieb:
Ein exzellenter Artikel über Soft updates: http://lwn.net/Articles/339337/
Zum Vergrößern anklicken....

Danke für den Link! Man beachte insbesondere die Schlussfolgerung.

Overall, soft updates is a sophisticated, insightful, clever idea - and an evolutionary dead end. Journaling and copy-on-write systems are easier to implement, require less special-purpose code, and demand far less of the programmer writing to the interface.
Zum Vergrößern anklicken....


Da waren übrigens auch die Knackpunkte, warum die NetBSD-Entwickler letzlich aufgaben - es war zu hart das softupdates-Konzept einwandfrei zu implementieren.
 
@sniket

sniket schrieb:
Ein exzellenter Artikel über Soft updates: http://lwn.net/Articles/339337/
Zum Vergrößern anklicken....

Es existieren immer zwei Seiten der Medallie:

http://www.usenix.org/publications/...l/full_papers/seltzer/seltzer_html/index.html

Ich bin ohnehin der Ansicht, daß nirgendswo wirklich das Gras grüner ist, aber gemeinhin wird in Linux-Gefilden alles irgendwie "schlechtgeredet", was nicht per se "selbst erfunden" wurde. Siehe ZFS Vs brtfs usw. Und XFS wie oben erwähnt ist auch irgendwie das ungeliebte Stiefkind innerhalb des Kernels. Last not least wiederspricht die Praxis (Softupdates/FreeBSD) obiger Theorie, Linux kann als einzig wirklich gehegt und gepflegtes Filesystem die ext-Reihe aufbieten und bei diesen mußte man auch fortwährend die Unzulänglichkeiten zurechtrücken. Nun soll brtfs alles richten ... nun ja einer gewissen Komik entbehrt das nicht.


@mawei

>Da waren übrigens auch die Knackpunkte, warum die NetBSD-Entwickler letzlich aufgaben - es war zu hart das softupdates-Konzept einwandfrei zu implementieren.

Entsprechend fähige Entwickler vorausgesetzt stellte dies aber zumindest für OpenBSD kein Problem dar. Ich denke bei NetBSD war es wohl eher ein Mangel an Manpower und man war nur allzu glücklich über das "Journaling-Geschenk".
 
mücke schrieb:
Entsprechend fähige Entwickler vorausgesetzt stellte dies aber zumindest für OpenBSD kein Problem dar. Ich denke bei NetBSD war es wohl eher ein Mangel an Manpower und man war nur allzu glücklich über das "Journaling-Geschenk".
Zum Vergrößern anklicken....

Zur Umsetzung unter OpenBSD kann ich nichts sagen. Aber NetBSD hat ja auch eine Implementierung.

Generell ist es fuer nichtkommerzielle Freiwilligenprojekte enorm wichtig sich auf "Manpower-freundliche" Loesungen stuetzen zu koennen.

Davon abgesehen war unter NetBSD für die Integration und Anpassung von WAPBL auch einiges an Manpower noetig. Geschenk und Bürde zugleich ;-)

Aber egal, unter FreeBSD funktionieren softupdates gut und werden zukuenftig noch besser - das ist die Hauptsache :)
 
WAPBL ist zweifellos ein sehr interessanter Ansatz und wäre durchaus vorstellbar gewesen, diesen auch unter FreeBSD zu sehen. Allerdings scheint das Schiff dort ja in eine andere Richtung zu fahren, sprich wir werden es nie sehen. Stattdessen verfolgt man die Softupdates-Straße weiter.

Frau Aurora hat da einen schönen Artikel geschrieben, doch unter dem Strich macht sie nichts anderes, als die Argumente wieder aufzuweichen, die die Softupdate-Gegner seit 10 Jahren immer und immer wieder bringen. Erst einmal vergisst sie, dass alle drei BSDs eine andere Definition von VFS haben als Linux. Sie machen mehr in den Dateisystemen und weniger im VFS als Linux, was einerseits historisch begründet ist. BSD kam Mitte der achtziger durch die Einführung von NFS mehr oder weniger zufällig zu seinem VFS, wohingegen Linux von Beginn an einen Ansatz mehrerer Dateisysteme verfolgte und mit einem leistungsstarken VFS ausgestattet wurde. Heute unterstützen alle BSDs zwei, maximal drei bis vier Dateisysteme vollständig, wohingegen Linux um und bei 30 Stück hat, wenn man die Exoten mitzählt. Linux versucht entsprechend möglichst viel Funktionalität aus dem Dateisystem herauszuziehen und in das VFS zu verlegen. Das einzelne Dateisystem benötigt daher recht wenig Logik. Unter BSD aber hängen VFS und FFS/UFS-Dateisystem nach wie vor eng zusammen. Viel Logik wird innerhalb des Dateisystems realisiert, das VFS spielt diesem lediglich zu. Darin liegt auch die Schwierigkeit begründet Dateisysteme zu portieren. Das einzige Linux-Dateisystem, was es jemals in ein BSD geschafft hat, ist Ext2. Alle anderen Versuche zu portieren (ReiserFS, XFS) scheiterten. Umgekehrt ist es ähnlich, Linux hat FFS/UFS niemals vernünftig portiert.

So, kommen wir zum Thema. Das Hauptargument in dem Artikel ist, dass Softupdates extrem komplex zu implementieren sind. In gewisser Weise stimmt dies. Softupdates haben den Anspruch alle Änderungen der Metadaten auf der Platte atomar durchzuführen. Also entweder geht eine Änderung komplett durch oder sie geht gar nicht durch. Im Katastrophenfall kommt es daher zu keiner Inkonsistenz. Was durchgekommen ist, ist vorhanden und innerhalb des Dateisystems konsistent. Was nicht durchgekommen ist, ist schlicht nicht sichtbar. Es ist nicht vorhanden, weg und stört die Konsistenz nicht. Das Problem dabei ist, um dies zu erfüllen müssen wir die Eingabeoperationen serialisieren. Wir müssen aus dem parallelen Operationsstrom eine serielle Abfolgen bauen. Das Problem dabei sind dabei die in dem Artikel auch genannten, zyklischen Abhängkeiten. Also A benötigt B benötigt C benötigt A. Softupdates umgeht diese, indem sie durch ein verhältnismäßig komplexes Verfahren erst Rückwärts auflösen, anschließend vorwärts aktualisieren. Dieser Vorgang läuft komplett im RAM ab, das Schreiben auf die Platte erfolgt erst ganz am Ende in einem Rutsch anhand des so ermittelten Ablaufplans.

So, nun kommen wir zu dem Hauptpunkt des Artikels, dieses schöne Diagramm. Softupdates müssen ein atomares Schreiben auf die Platte sicherstellen, dies verlangt, dass eine ganze Reihe von Fällen beachtet werden. Nichts anderes macht dieser Callgraph, es ist übrigens nur ein Teil der ganzen Magie. Nun wird argumentiert, dass dies zu komplex zu verstehen sein und deshalb das Wahre. Es stimmt, es ist durchaus schwer zu begreifen, warum diese Operationen nötig sind, zumindest solange man keine Grafik des On-Disk Layout zu Hilfe hat. Nur der eigentliche Punkt wird übersehen. Bei Softupdates sind wir anschließend fertig. Bei Journaling haben wir an dem Punkt erst eine mit viel weniger Aufwand erreichte Transaktion. Diese wird nach unten durchgegeben, nun muss der Transaktionmanager diese aber mit den anderen Transaktionen verschmelzen, so dass die Konsistenz am Ende erhalten bleibt. Und dieser Vorgang ist ebenfalls alles andere als trivial. Da müssen Abhängigkeiten ermittelt werden, das ganze zerteilt, ein Shuffleprodukt errechnet werden, Vorwärts- und Rückwärtskonsistenz sichergestellt, etc. Man kann dort Sperren anwenden, was nicht wirklich optimal ist, gerade in Hinblick auf die Geschwindigkeit. Man kann optimistisch arbeiten und versuchen einen konfliktfreien Schedule erzeugen, was aber zu langen Rückstellzeiten von Transaktionen führt.

Nein, Journaling mag in den oberen Ebenen Vorteile haben und dort wesentlich einfacher sein. In den unteren Ebenen aber ist es dafür deutlich komplexer als Softupdates, was ebenfalls von Nachteil sein kann. Daher lasse ich das Argument, dass Softupdates zu komplex sein, nicht gelten. Was für Journaling spricht, ist lediglich die Tatsache, dass das Scheduling von Transaktionen aufgrund jahrelanger Forschung im Bereich Datenbanken und Dateisystemen gut verstanden ist, während Softupdates bis heute nur eine nennenswerte Implementierung haben.

Noch einmal in realen Zahlen. FFS/UFS ist in etwa 30.000 Zeilen implementiert, die Softupdates benötigen davon etwa 6.000, also knapp 20%. In XFS haben wir insgesamt 98.000 Zeilen, wobei XFS deutlich komplexer als FFS/UFS ist. Das Journaling sind ca. 20.000, also ebenfalls grob 20%. Im Verhältnis also nicht mehr.

Zudem sehe ich in Journaling einen Denkfehler. Man geht davon aus, dass nach der Katastrophe etwas auf der Platte ist, was in einem mehr oder minder definierten Zustand ist, aus welchem wir mit dem Journal einen konsistenten Zustand erreichen können. Jedoch geschehen im Moment des Crashes beim ansychronen Schreiben durchaus undefinierte Dinge, die in einem undefinierten Zustand enden. Das Journal kann dann nicht vollständig zurückgespielt werden, die Folge ist Datenverlust und der weg zum Backupregal. Gerade komplexe Journalingsateisysteme wie XFS und ReiserFS können das aus eigener Erfahrung (XFS aber unter Irix) sehr gut Softupdates und auch Copy on Write haben dieses Problem nicht. Meine Einschätzung für die Zukunft ist daher, dass Copy on Write, getragen durch den ZFS-Hype, Journaling tendentiell verdrängen wird.
 
@ mücke

ch bin ohnehin der Ansicht, daß nirgendswo wirklich das Gras grüner ist, aber gemeinhin wird in Linux-Gefilden alles irgendwie "schlechtgeredet", was nicht per se "selbst erfunden" wurde.
Zum Vergrößern anklicken....

Hat sie in dem Artikel doch gar nicht gemacht. Ich fand das sehr neutral. Die Frau weiß außerdem wovon sie redet. Sie war eine der Programmiererinnen, die bei Sun an ZFS mitgearbeitet hat.

Und XFS wie oben erwähnt ist auch irgendwie das ungeliebte Stiefkind innerhalb des Kernels.
Zum Vergrößern anklicken....

Weißt du auch warum? XFS ist einfach EXTREM KOMPLEX. Es gibt nicht viele Leute, die XFS wirklich verstehen. Die, die es tun, arbeiten mit Ausnahme von Christoph Hellwig alle bei SGI. Das ist u. A. auch der Grund, weshalb Redhat und Novell in ihren Enterprise Distros auf Ext3 setzen: die haben in-house keine Leute, die sich mit XFS auskennen. Ext3 hingegen ist grob gesagt Ext2 mit einem Journal und Ext2 basiert auf UFS, was altbewährte Technik aus den 80ern ist.

@ Yamagi

Noch einmal in realen Zahlen. FFS/UFS ist in etwa 30.000 Zeilen implementiert, die Softupdates benötigen davon etwa 6.000, also knapp 20%. In XFS haben wir insgesamt 98.000 Zeilen, wobei XFS deutlich komplexer als FFS/UFS ist. Das Journaling sind ca. 20.000, also ebenfalls grob 20%. Im Verhältnis also nicht mehr.
Zum Vergrößern anklicken....

Der Vergleich hinkt doch leider etwas. Vergleich FFS/UFS lieber mit Ext3, dann kommen sich die LOC schon näher ;-)
 
Es ist schon möglich Dateisysteme von Linux auf FreeBSD zu portieren. Es ist nur eine Frage des Aufwands und der Motivation. Zumindest XFS war ja in der Portierung durchaus weit gekommen, inklusive Schreibunterstützung, die man allerdings nur vorsichtig verwenden sollte. Nur dann stieß es auf weitaus weniger Interesse als die Portierer erwartet hatte, das Projekt war recht komplex und kam nur langsam voran. Dazu das Problem mit der GPL. Als dann ZFS schon nach wenigen Tagen einen funktionierenden Prototypen hatte, war da die Luft raus. Ob man jetzt brtfs oder Tux3 jemals sehen wird, weiß ich nicht. Aber ich denke, es ist eher unwahrscheinlich. ZFS ist zur Zeit der Weg, den man geht und wenn man den eines Tages verlassen sollte, wird man sich wahrscheinlich etwas suchen oder bauen, was in Sachen Lizenz kompatibler ist und vom Aufwand her geringer.

So, Ext3. Bitte nagelt mich auf die Zahlen nicht fest, ich kenne Ext3 in seinem Inneren abseits der Theorie kaum und kann hier nur eine naiv Zählung bieten. Insgesamt haben wir 16.000 Zeilen, davon grob 3000 für das Journal. Wären dann 18%. Dazu muss man sagen, dass Ext3 in seinem Aufbau einfacher ist als FFS. Es hat keine Trennung in untere und obere Ebene, benötigt kein Dirhashing und kommt mit einem Algorithmus zur Blockverteilung aus. Das führt insgesamt zu weniger Code. Wie weit das nun verfälscht kann ich nicht einschätzen.
 
sniket schrieb:
@ mücke



Hat sie in dem Artikel doch gar nicht gemacht. Ich fand das sehr neutral. Die Frau weiß außerdem wovon sie redet. Sie war eine der Programmiererinnen, die bei Sun an ZFS mitgearbeitet hat.



Weißt du auch warum? XFS ist einfach EXTREM KOMPLEX. Es gibt nicht viele Leute, die XFS wirklich verstehen. Die, die es tun, arbeiten mit Ausnahme von Christoph Hellwig alle bei SGI. Das ist u. A. auch der Grund, weshalb Redhat und Novell in ihren Enterprise Distros auf Ext3 setzen: die haben in-house keine Leute, die sich mit XFS auskennen. Ext3 hingegen ist grob gesagt Ext2 mit einem Journal und Ext2 basiert auf UFS, was altbewährte Technik aus den 80ern ist.

@ Yamagi



Der Vergleich hinkt doch leider etwas. Vergleich FFS/UFS lieber mit Ext3, dann kommen sich die LOC schon näher ;-)
Zum Vergrößern anklicken....


Jeff antwortete auf diesen Artikel:

http://valhenson.livejournal.com/47401.html?thread=319017#t319017

My feelings on your general statements of complexity are that writing high-performance high-quality software is hard. Browsing other filesystem implementations such as zfs or xfs does not give me a feeling that they are substantially simpler or easier to develop on. NetBSD's wapbl is quite simple but you pay a price for that in performance.
Zum Vergrößern anklicken....

@sniket

>XFS ist einfach EXTREM KOMPLEX.

Das ist schon klar und auch ZFS ist sicherlich nicht mal eben am Wochenende durchschaubar, aber was brachte diese Simplifizierung bei ext3? Ein unzureichendes Filesystem, kurzum eine massive Sackgasse. Ext4 folgte als Interimslösung bis zu brtfs. ext4 selbst aber ist irgendwie ein WIP-Projekt, online-Defrag "kommt" irgendwann, irgendwie hofft man aber auf den Heilsbringer brtfs. Derweil nutzen viele größeren Server XFS, weil irgendwie anfreunden kann sich keiner so richtig mit ext* - Ausnahmen bestätigen die Regel. Ich arbeitete übrigens früher gerne mit XFS unter Irix und verwende es auch heute noch, wenn Linux zum Einsatz kommt - it sucks less kommt mir dabei in den Sinn. Linux bietet die meisten Filesysteme und in der Praxis reduziert es sich im Prinzip auf zwei an der Zahl.

Demgegenüber stehen in FreeBSD ZFS und UFS2. Letzteres ist komplex im Zusammenhang mit SU? Im Vergleich zu _heutigen Filesystemen? Na ja, wenn das alles so komplex ist, warum wagt sich die Linux-Gemeinde dann an brtfs?
 
Ein unzureichendes Filesystem, kurzum eine massive Sackgasse.
Zum Vergrößern anklicken....
Ich frage mich ernsthaft, wie du zu solchen Aussagen kommst. Ext3 wird seit Jahren bei fast allen Distributionen als Standard-FS eingesetzt und tut seine Arbeit ordentlich. Bei mir persönlich lief es ebenfalls immer rund.

Ext4 folgte als Interimslösung bis zu brtfs. ext4 selbst aber ist irgendwie ein WIP-Projekt, online-Defrag "kommt" irgendwann, irgendwie hofft man aber auf den Heilsbringer brtfs.
Zum Vergrößern anklicken....
Was ist daran schlimm, dass Ext4 nur eine Übergangslösung darstellt? Bis Btrfs irgendwann als Standard-FS seinen Weg in die diversen Distributionen findet, dürfte wohl noch etwas Zeit vergehen. Fragmentierung war bei Ext* nie ein großes Problem (im Gegensatz zu ZFS. Wo ist da eigentlich das Defrag-Progrmam?) und das komplette FS als WIP zu bezeichnen, nur weil diese Funktion fehlt, halte ich auch für sehr an den Haaren herbei gezogen.
 
sniket schrieb:
Ich frage mich ernsthaft, wie du zu solchen Aussagen kommst. Ext3 wird seit Jahren bei fast allen Distributionen als Standard-FS eingesetzt und tut seine Arbeit ordentlich. Bei mir persönlich lief es ebenfalls immer rund.
Zum Vergrößern anklicken....

Nicht das jetzt der Eindruck entsteht ich habe etwas gegen Linux. Auf diversen Desktop-Kisten läuft das bei mir auch, zu meiner größten Zufriedenheit. Aber so viele Probleme bezüglich eines Filesystems wie bei ext* habe ich noch nie zu hören bekommen. Weder bei ufs, xfs oder ntfs.

sniket schrieb:
Fragmentierung war bei Ext* nie ein großes Problem (im Gegensatz zu ZFS. Wo ist da eigentlich das Defrag-Progrmam?)
Zum Vergrößern anklicken....

Kommt demnächst mit block pointer rewrite.
 
>Ext3 wird seit Jahren bei fast allen Distributionen als Standard-FS eingesetzt

Reden wir jetzt vom Desktop mit ein paar mp3s, Bilder etc. pp.? Oder einem ausgewachsenen Server?

Suse z.B. kam seit Jahren mit Reiser als default. Ext3 ist für den Desktop das genehmste Filesystem, aber dennoch nicht ideal. XFS z.B. hat in einigen Bereichen Performane-Probleme und kam (kommt) nach einem Stromausfall schon einmal ohne Daten daher. Dafür hat es jedoch für den Server-Betrieb Qualitäten zu bieten, die wir bei ext* besser erst gar nicht suchen. Nochmal zum mitschreiben: Server. Daheim gibt es auch viele die JFS nutzen. Zudem gehe ich hier in diesem BSDForum einfach mal davon aus, daß das Gros der hier Anwesenden selten mit default-Einstellungen arbeitet.

>ext4

http://blog.koehntopp.de/archives/2349-Was-bringt-ext4.html#extended

Böse Zungen könnten von einem "Bugfix-Filesystem" sprechen, zumindest im übertragenen Sinn.


>Fragmentierung war bei Ext* nie ein großes Problem

http://www.heise.de/open/artikel/Fragmentierung-224380.html
http://trac.transmissionbt.com/ticket/849
http://archives.free.net.ph/message/20070518.134838.52e26369.en.html

usw.

Wie gesagt Glaube Vs Realität. Oder wie der Redakteur dort meinte "Jehova" ;-)

>im Gegensatz zu ZFS. Wo ist da eigentlich das Defrag-Progrmam?

Du kennst ZFS? Wahrscheinlich nicht. Vor kurzem war etwas ähnliches zu lesen auf OSNews, dort brachte man den Punkt des fehlenden fsck vor - wie sich herausstellte einzig ob einer Wissenslücke des Autors. Auch hierbei gilt: Linux ist nicht die Welt.

Erst einmal etwas zu fsck, mehr als Beispiel für antiquierte Denkweisen: http://www.c0t0d0s0.org/archives/6071-No,-ZFS-really-doesnt-need-a-fsck.html

... und eine Erklärung was 'Fragmentierung' bei ZFS bedeutet, findet sich dort: http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg28153.html


>das komplette FS als WIP zu bezeichnen, nur weil diese Funktion fehlt

Ich bezeichne es noch als WIP, weil es einfach unausgegoren ist. Vielleicht wäre es besser von instabil zu sprechen (Tso's Vorstellungen z.B. bezüglich fsync usw.). Stable ist es ja nur für die Funktionalitäten per se und im Glauben der User.

Im Übrigen bin ich hier nicht der große Verfechter von ZFS bzw. möchte es über den grünen Klee loben. Doch viele Denkweisen gegenüber diesem sind einfach veraltet, sorgen für Vorurteile oder gar handfeste Probleme in der Praxis.
 
Zuletzt bearbeitet:
Reden wir jetzt vom Desktop mit ein paar mp3s, Bilder etc. pp.? Oder einem ausgewachsenen Server? [...] Suse z.B. kam seit Jahren mit Reiser als default.
Zum Vergrößern anklicken....
Sowohl als auch!? Reiser skaliert wegen dem BKL ab einer gewissen Anzahl von CPUs nicht mehr, deshalb auch der wechsel zu Ext3. Und selbst wenn Suse auf Reiser gesetzt hat, Redhat und Debian setzen auf Ext. Worauf willst du also hinaus?

Du kennst ZFS? Wahrscheinlich nicht. Vor kurzem war etwas ähnliches zu lesen auf OSNews, dort brachte man den Punkt des fehlenden fsck vor - wie sich herausstellte einzig ob einer Wissenslücke des Autors. Auch hierbei gilt: Linux ist nicht die Welt.
Zum Vergrößern anklicken....

Vielleicht solltest du dir erstmal darüber im Klaren werden, was so alles unter 'fsck' fällt ;-)
Siehe http://lwn.net/Articles/248180/

Im Übrigen bin ich hier nicht der große Verfechter von ZFS bzw. möchte es über den grünen Klee loben. Doch viele Denkweisen gegenüber diesem sind einfach veraltet, sorgen für Vorurteile oder gar handfeste Probleme in der Praxis.
Zum Vergrößern anklicken....

ZFS hat doch genauso seine eigenen Probleme und Kinderkrankheiten! Von wegen "the last word in filesystems" Lies dir doch einfach mal die Beiträge von solarix in diesem Thread http://www.bsdforen.de/showthread.php?p=206553 durch.
 
Okay ich mach es mal kurz: es sollte kein "BSD kann alles besser", sondern ein "BSD braucht sich keineswegs zu verstecken" werden. Gemeinhin gilt in der Linux-Welt leider das Credo "was nicht Linux ist, kann ja nichts taugen" - FUD mitunter. Falls jetzt jemand seinen Linux-Fan-Wimpel beschmutzt sieht, ich nutze auch mit größter Zufriedenheit Slackware seit den frühen 90ern und bin damit vollend zufrieden, bei FreeBSD stieg ich erst mit 5.0 ein, ein früher Versuch mit einem 68k NetBSD auf dem Amiga enttäuschte damals eher.

So und noch einmal zu ZFS, deine Antipathie diesem gegenüber ist ja nicht zu übersehen, aber ich erwähnte es _zuvor_ eigentlich nur unter ferner liefen, mein Hauptaugenmerk galt UFS2+SU, erst im vorletzten Posting ging ich überhaupt wirklich darauf ein. Im übrigen hatte Reiser3 schon andere Probleme ( http://www.ende-der-vernunft.org/2003/06/25/rasierfs/ ), Stromausfälle oder eine Panic überstand es nur recht schlecht, aber das nur nebenbei. War auch nur eine Erwähnung im Bezug auf diese ewig währende Journaling-Laudatio, die einfach nicht gerechtfertig ist.

Apropos ZFS, lies dir mal Jörg Möllenkamps Beitrag durch und du kennst wahrscheinlich auch zfs scrub? ;-)

Apropos ext4: http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.32.1

Taugt so etwas tatsächlich als Interimslösung, abseits des Desktops?
 
Zuletzt bearbeitet:
BSD braucht sich keineswegs zu verstecken
Zum Vergrößern anklicken....
Das habe ich auch nirgends erwähnt.

Gemeinhin gilt in der Linux-Welt leider das Credo "was nicht Linux ist, kann ja nichts taugen"
Zum Vergrößern anklicken....
Wie kommst du denn zu solchen Aussagen? Hier nochmal das Schlusswort aus dem Artikel über SU:

"Overall, soft updates is a sophisticated, insightful, clever idea - and an evolutionary dead end. Journaling and copy-on-write systems are easier to implement, require less special-purpose code, and demand far less of the programmer writing to the interface."

Wo genau ließt du da ein "kann ja nichts taugen"? Ausgeklügelte, clevere Idee hat sie SU genannt. Die Geschichte gibt ihr mit der zweiten Aussage auch Recht. SU wurden bisher nur für UFS implementiert. Journaling FS gibt es "wie Sand am Meer". Das hat Matt Dillon schon 2001 gesagt [1] [...] but the softupdates concept can break down with other filesystems [...]

[1] http://www.osnews.com/story/153/The_Big_BSD_Interview/page2/

Schön das du uns allen zeigst, wie toll du googlen kannst! Hattest du die Links noch als Bookmarks oder hast du mal eben einfach nach "reiserfs corruption" gesucht? ;-) Das ist doch alles ein extrem alter Hut. Als ob UFS unter FreeBSD so rock-solid wäre, dass da noch niemandem das FS kaputt gegangen ist [...]

ich nutze auch mit größter Zufriedenheit Slackware seit den frühen 90ern und bin damit vollend zufrieden
Zum Vergrößern anklicken....
Willst du uns damit zeigen wie "oldschool" du bist oder soll das schlichtweg die Richtigkeit deiner Aussagen unterstreichen? Vonwegen "ich bin seit Anfang an dabei, ich weiß wie der Hase läuft" ;-)
 
Hallo zusammen,

eine wahrhaft interesante Thematik weitere Infos liefert aber hierzu auch das grandiose freebsdhandbuch
Abschnitt 11.12.2.1. Details über Soft Updates

link > http://www.freebsd.org/doc/de/books/handbook/configtuning-disk.html

Diskussionen über Datei Systeme unter Linux gab es zuhauf insbesonders die Diskussion um Hans Reiser und sein ReiserFs .............
Link > http://www.golem.de/0808/61620.html

Allgemeine Info ReiserFs Link > http://www.tuxfutter.de/wiki/ReiserFS
Eigenschaften und Benchmarks Link > http://www.pro-linux.de/berichte/ext4/ext4.html
 
Zuletzt bearbeitet:
sniket schrieb:
Als ob UFS unter FreeBSD so rock-solid wäre, dass da noch niemandem das FS kaputt gegangen ist [...]
Zum Vergrößern anklicken....
Ich habe UFS in den Versionen 1 und 2, mit und ohne Snapshots seit 1996 im Einsatz. Privat, beruflich, auf im Schnitt mehr als 500 Kisten und weit über 2500 Platten. Vom kleinen Embedded Device bis hoch zum 128TiB RAID-Verbund. Das sind zusammen Millionen Laufstunden. In all den Jahren noch nie ein einziges unwiederbringlich zerlegtes Dateisystem. Egal was passierte. Stromausfälle, Crashs, defekte Controller, verbrannte Kabel, falsch wieder hergestellte RAID-Verbünde, amoklaufendes dd... Es war ein paar Mal hart an der Grenze, aber mit fsdb(8) war es immer wieder reparabel. Das schlimmste waren mal ein paar zerstörte Cylinder Groups, die man aber selbst dann noch mit ffs2recov retten, ausradieren und damit das Dateisystem wieder in Konsistenz bringen konnte. FFS/UFS ist in den in FreeBSD eingesetzten Versionen schlicht unkaputtbar und man muss schon verdammt viel Gewalt und PEBKAC anwenden, um es zerstört zu bekommen. :)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben