FreeBSD: Journaling filesystem macht Fortschritte

Daniel Seuffert

Daniel Seuffert

Well-Known Member
Jedermann sind die ungezählten Beiträge von Linuxnutzern und ihrem endlosen Geschrei nach JFS wie z.B. ReiserFS hinlänglich bekannt, auch dieses Forum wurde schon hunderte Male von solchen posts heimgesucht. Dies und der performance-Aspekt beim bgfsck grosser filesysteme hatten Scott Long vor längerer Zeit bewogen eine Implementierung eines JFS in FreeBSD voranzutreiben (siehe z.B. link aus BSDForen). Doch nun naht baldige Abhilfe in Form von gjournal, einem Google Sommer of Code Projekt. Wie gestern auf current nachzulesen war hat der kroatische Student Ivan Voras (http://ivoras.sharanet.org/) eine Beta-Version von gjounal fertiggestellt, die bereits alle geplanten features enthält, download unter http://ivoras.sharanet.org/gjournal-beta.tgz. Weitere Informationen sind im SoC-Wiki unter http://wikitest.freebsd.org/moin.cgi/gjournal einsehbar.

Disclaimer: Das ist eine erste Beta-Version und nicht für Produktivzwecke gedacht, Kids don't try this at home!

Hier die Originalmail der Vollständigkeit halber:

Date: Mon, 15 Aug 2005 16:08:39 +0200 (CEST)
From: Ivan Voras <ivoras@fer.hr>
Subject: gjournal feature-complete beta version
To: current@freebsd.org
Message-ID: <20050815160205.H84002@geri.cc.fer.hr>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

gjournal is a GEOM journaling class (layer) that provides data journaling
and COW-like facilities to any disk-like devices GEOM knows about. It's
sponsored by Google's Summer of Code project.

I'm announcing availability of beta version (not for production use) that
needs more testing. It's available for download at:
http://ivoras.sharanet.org/gjournal-beta.tgz

Read the README file before using!

More information about the project can be found at:
http://wikitest.freebsd.org/moin.cgi/gjournal

Any feedback is welcome! :)
Zum Vergrößern anklicken....

Es geht also voran, hoffen wir auf ein baldiges Voranschreiten des Projektes und eine möglichst performante und sichere Implementierung bereits in FreeBSD 6.1 (ja, das wird kommen und es wird optional sein bevor das Geschrei der ewiggestrigen Zombies hier aufbrandet....).

Ach, bevor ich es vergesse, ihr wusstet alle schon was jetzt kommen muss: BSD is dying! :p


P.S.: Wird höchste Zeit für ein Multimedia-framework in FreeBSD, damit das Geschrei auch endlich aufhört (Desktop-orientierte "distros" gibbet ja nun auch schon). Aber wie ich bereits aus dunkelsten Quellen vernahm soll es auch dort schon Bestrebungen/Gedankengänge geben... In dem Sinne Leute: Fresse halten, Labern einstellen, was für BSD tun oder so ähnlich (ich glaub der Theo hatte da immer so nen Spruch parat). :D
 
Zuletzt bearbeitet:
Hi,

Daniel Seuffert schrieb:
Jedermann sind die ungezählten Beiträge von Linuxnutzern und ihrem endlosen Geschrei nach JFS wie z.B. ReiserFS hinlänglich bekannt, auch dieses Forum wurde schon hunderte Male von solchen posts heimgesucht.
Zum Vergrößern anklicken....

Warum tust du das als Geschrei/heimsuchen ab?


CU

Martin
 
@troll
Da ein JFS wohl "state-of-the-art" ist und es dieses unter *BSD nicht gibt.
Ich habe es bisher nicht vermisst, UFS2+snapshots leistet gute Dienste. Wenn man aber ein FS mit mehrere TB hat, oder auch schon nahe einem TB, dann dauert auch ein bgfsck lange, ein fsck wird eben benötigt. Da ist ein gutes JFS im Vorteil da es kein fsck braucht.
 
Hi,

asg schrieb:
@troll
Da ein JFS wohl "state-of-the-art" ist und es dieses unter *BSD nicht gibt.
Ich habe es bisher nicht vermisst
Zum Vergrößern anklicken....

Ich auch nicht. Ich wehr mich bloss dagegen Wünsche von Usern als Geschrei abzutun.
Aber egal, es kommt, alle sind glücklich und haben sich wieder lieb ;-)

CU

Martin
 
"wir haben bei linux jfs und ich hab gehört, dass das gut sein soll... warum hat das *bsd nicht? ich wusste doch schon immer, dass bsd scheisse und schon längst tot ist!"

--> das ist geschrei und zwar unbegründetes... jfs wurde bei bsd bisher nicht benötigt.
ufs2+bgfsck+snapshots alles genauso gut erledigen konnte. erst durch grosse hdds und partitionen jenseits der tb grenze wird das bsd konzept unbequem. aber das wurde ja auch schon erwähnt. und ich betone "unbequem", problematisch wird es dadurch nicht.

es ist schon, dass jfs auf geom oder später auf ufs2 basis wohl immer modulasei werden und jeder für sich entscheiden kann, ob es benötigt und eingesetzt wird oder nicht.

p.s. wer ironie findet, kann es behalten :p
 
Bevor hier aber alle das Jubeln anfangen, sollte man sich klarmachen, dass gjournal kein Journaling FS ist. Ganz im Gegenteil, es ist ein Layer, den man unter jedes beliebige FS schieben kann. Nachteil an der Sache ist, dass dies nur mit zwei physikalischen Laufwerken ueberhaupt Sinn macht.

Mit der passenden Hardware koennte das recht performant sein. Flexibel ist es allemal. Ein JFS fuer den Hausgebrauch ist es aber nicht (nix ReiserFS, nix XFS, etc.)
 
@troll: Mal im Kurzdurchlauf, ich dachte bei deinem nick müsste man wissen, warum ich es so flapsig geschrieben habe... :D

1. Geschrei wegen der Art, wie das oft vorgetragen wird.
2. Weil der grösste Teil der Leute bei JFS etwas postuliert, was er nie hinterfragt, geschweige denn verstanden hat.
3. Weil es (JFS) grösstenteils hype ist, von dem niemand genau weiß woher er kommt.
4. Weil die meissten Menschen nie wirklich in eine Situation kommen, in der ein JFS wirklich Sinn macht (ich z.B. in den letzten 20 Jahren nicht).
5. Weil Ironie enthalten ist und der gesamte post launig geschrieben wurde.
6. Weil FreeBSD adäquate Mittel mit UFS + softupdates hat, welche das Gleiche leisten.
7. Weil genau die Leute, welche auf JFS schwören, meistens das Backup und RAID vergessen, welches imho wesentlich wichtiger und sinnvoller ist.
8. Weil viele Leute irrigerweise meinen durch irgendeine Form von Software (hier JFS) minderwertige hardware (SCSI, vernünftige controller etc.) substituieren zu können, man denke nur beispielsweise an die RAID-Problematik und sich dann bei Problemen wundern, warum das letztlich ein Irrweg ist.
9. Weil jegliche Form von Software inklusive JFS auch implizite Nachteile hat, vom performance, CPU bis hin zur Problematik potentieller Sicherheitslöcher.

So, das reicht glaube ich hinreichend auf die Schnelle.

@MrFixit: True, aber was will man den mit spitzfindigen technischen Argumenten, wenn es um Dinge wie JFS geht? :D (Disclaimer: Ironiedetektor einschalten). Dann bringen wir gleich noch ein Argument: Wenn schon etwas journaled werden dann soll, dann bitte nicht auf der gleichen physikalischen Platte. Und ausserdem waren wir ja irgendwie bei ganz grossen filesystems, wo wir sowieso eine ganze Reihe von Platten brauchen, um sie überhaupt darstellen zu können.

Ok, ok, Schluss jetzt mit der leidigen Argumentiererei, ich brauch Kaffee. ;) :)
 
Gib mal ein wenig mehr preis von den Gedankengängen aus den dunklen Quellenüber ein Multimedia-Framework. Gibt es auch gedankengänge über eine Portierung von hal/dbus auf Freebsd oder eine alternative Lösung.

PS: da der kioslave media:/ von KDE entweder über hal oder über die Einträge in der fstab, angesteckte USB-Laufwerke anzeigt, gibt es eine vergleichebare Lösung für Freebsd in Verbindung mit devd? Ist devd mit dem was hal leistet vergleichbar? Zu dem Thema habe ich bisher keine vernünftige Dokumentation gefunden.

Bin für Tipps und Hinweise dankbar.
 
Sorry, ich darf keine Details aus diesen Quellen preisgeben, soviel nur: Nächtes Jahr sollen grundlegende Arbeiten stattfinden, die zuerst Sound betreffen; hal/dbus ist aber nicht drunter soweit mir bekannt. Und das wird wohl aus mehreren Ecken kommen, soweit die Sachen so verlaufen wie geplant. Ich werde natürlich entsprechende news verbreiten, wenn es soweit ist. Ich halte nichts davon die Gerüchteküche hochbrodeln zu lassen vor der Zeit. Man sollte erst dann ein Fass aufmachen, wenn genug Alk drin ist. :D
 
Daniel Seuffert schrieb:
Sorry, ich darf keine Details aus diesen Quellen preisgeben, soviel nur: Nächtes Jahr sollen grundlegende Arbeiten stattfinden, die zuerst Sound betreffen; hal/dbus ist aber nicht drunter soweit mir bekannt. Und das wird wohl aus mehreren Ecken kommen, soweit die Sachen so verlaufen wie geplant. Ich werde natürlich entsprechende news verbreiten, wenn es soweit ist. Ich halte nichts davon die Gerüchteküche hochbrodeln zu lassen vor der Zeit. Man sollte erst dann ein Fass aufmachen, wenn genug Alk drin ist. :D
Zum Vergrößern anklicken....

schade, hätte gern ein wenig gerüchte gelesen ;-( . im ernst, bisher hatte ich keine problem mit den multimediafähigkeiten von freebsd, so dass ich die notwendigkeit eines multimedia-frameworks nicht ernshaft erkannt habe.

für hinweise, ob es eine protierung von hal auf freebsd gibt und informationen darüber, wäre ich sehr dankbar!
 
snoopy schrieb:
im ernst, bisher hatte ich keine problem mit den multimediafähigkeiten von freebsd, so dass ich die notwendigkeit eines multimedia-frameworks nicht ernshaft erkannt habe.
Zum Vergrößern anklicken....
Ok, solange der Tastaturtreiber die Shift-Taste unterstützt, bin ich eigentlich zufrieden. Aber trotzdem: Sachen wie 5.1-Sound oder eine breitere Unterstützung von TV-Karten wäre IMO schon ganz nett. Ansätze sind ja schon vorhanden, da kann man weiter dran arbeiten.
 
Mein kleiner Seitenhieb war nur dazu gedacht darauf hinzuweisen, daß man auch in BSD-Kreisen nicht blind durch die Gegend läuft und bestimmte Schwachstellen bzw. ernsthaft notwendige Anforderungsprofile nicht erkennt, egal ob sie für alle oder nur einen bestimmten Teil der user zutreffen. Aber es ist ein Problem der Ressourcen wie immer, sowohl manpower als auch andere und wir sind uns einig, daß es speziell in den letzten 3 Jahren (5er branch) weitaus dringendere Baustellen gab und teilweise noch immer gibt. Für solch grosse Vorhaben müssen sich Leute teilweise monatelang dediziert hinsetzen und können das nicht nebenher machen. Ein aktuelles Beispiel, wo dies seit Montag dieser Woche umgesetzt wird ist Andre Oppermann ich verweise mal beispielhaft auf http://people.freebsd.org/~andre/tcpoptimization.html; SoC wäre jetzt ein anderes Beispiel.

Wir sind uns wohl einig, daß besserer support in der angesprochenen Richtung wichtig ist für einen grösseren Erfolg von BSD auf dem Desktop, egal wie der Einzelne dazu stehen mag. Ich verweise hier zumindest teilweise auch auf die Huhn-Ei-Problematik. will man mehr support und mehr features in BSD braucht man mittelfristig auch mehr supporter gleich welcher Natur und die kommen ganz sicher nicht aus der userbasis von Windows, Mac OS X, Linux, Plan9 oder whatever. Jedes OS wird wachsen müssen von den features her, um mit der allgemeinen Entwicklung Schritt zu halten, d.h. mehr code und mehr erforderlicher input von Produktionsfaktoren, wer stehen bleibt wird verlieren, Punkt.

Es wird mehr Multimedia geben speziell in FreeBSD und ziemlich bald. Aber es wäre imho wünschenswert wenn sich mehr Leute Gedanken darüber machen würden, wie das zu erreichen ist, anstatt nur dazusitzen und passiv zu Wehklagen bzw. zu Fordern.
 
Ich finde besonders gelungen, _wie_ journaling in FreeBSD umgesetzt wird. IMO ist das ein bemerkenswert besseres Design als andere Systeme es haben.

Soweit ich das verstanden habe sollte sich damit sogar eine FAT Partition journaln lassen. Wer auch immer so etwas krankes machen will :ugly:
 
asg schrieb:
Da ist ein gutes JFS im Vorteil da es kein fsck braucht.
Zum Vergrößern anklicken....
Wunschtraum?
Wenn es das journal selber zerlegt, braucht man einen fsck -- und der geht
dann *richtig lange*.

MrFixit schrieb:
Nachteil an der Sache ist, dass dies nur mit zwei physikalischen Laufwerken ueberhaupt Sinn macht.
Zum Vergrößern anklicken....
Das Journal auf die gleiche Platte (Spindel) zu schreiben, ist auch vom performance-Aspekt her nicht der Bringer. Geschweige denn bei schleichendem
Plattentod ist man dann auch schnell bei dem Punkt oben.


(Niemand will backup, alle wollen restore)
 
Journal, naja. Ist mir eigentlich sehr egal. Für mich war bisher UFS/Softupdates der Vorteil - aber wenn sich nun alle auf das Journal stürzen ... ;)
Mal abgesehen davon dass wenn ich das entschieden hätte der Entwicklungsaufwand irgendwo anders hingegangen wäre - aber mich fragt ja keiner ;)

Wie ist das dann gedacht: Journal + UFS, Journal + Softupdates + UFS (Wobei ist das schlau?) oder je nach dem nach was ich gerade möchte?

MfG Peschmä
 
Nein, Softupdates+Journal macht wenig Sinn. Um das korrekt zu verwenden brauchst du erstmal zwei "Platten" (besser NVRAM oder so) und auf der Data Disk mountest du UFS als sync/sync (Meta-/Realdaten). Alle writes werden jedoch sequenziell auf die Journal Disk geschrieben und bei niedriger Last, wird dieses Journal "committed" also auf die Data Disk uebertragen.

Das Journal uebertragen ist idempotent (kann also zig-mal ausgefuehrt werden, und es kommt immer das gleiche raus) und wenn also der Strom wegfaellt, macht man den Commit einfach nochmal (evtl. doppelt, aber dat is ja nu egal). Erst wenn der Commit wirklich angekommen ist, markiert man ihn als "done".

Passiert also sonst nix, dann kann man sich den fsck sparen, weil die Metadaten immer in einen konsistenten Zustand gebracht werden koennen, indem alle anstehenden Commits ausgefuehrt werden.

Technisch gesehen ist natuerlich Softupdates die "korrekte" Loesung, indem man die Abhaengigkeiten umordnet, um immer korrekte Metadaten zu haben. Leider ist Softupdates "over-engineered" und sehr komplex, das Writecaching/Reordering moderner Festplatten macht alles wieder zu Nichte und den fsck braucht man trotzdem. (Und gerade das wollen ja die User vermeiden)

Softupdates ist natuerlich schneller als Journalling (das Schreiben des Journals entfaellt! Writes auf die Platte sind u.U. besser angeordnet), was man vor allem beim Loeschen von /usr/ports merkt :)
Allerdings ist das Loeschen vieler kleiner Daten die einzige Operation, die massiv Metadaten anfassen muss, und wie haeufig kommt das vor? Will man damit werben? ("Wir haben das FS, auf dem man am schnellsten 10e6 Dateien loeschen kann" -- "Super! Das will ich!")

Genug geschrieben, liest sich ja eh keiner durch, aber HTH.
 
Hier war bisher immer nur die Rede von gjournal. Laut Projektseite arbeitet auch Brian Wilson an Journaling für UFS(2, 3). Sein Projekt wird von Scott Long betreut. Ivan's "GEOM Journaling Layer" (gjournal) betreuen andere Entwickler.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben