FreeBSD: Journaling für UFS

asg schrieb:
Pawel Dawidek hat patches für FreeBSD Current und FreeBSD 6.x bereitgestellt um gjournal, ein meta-data und full data file system, zu testen.

Mittels gjournal ist kein fsck mehr nötig, nichteinmal mehr ein bgfsck.

Technische Einzelheiten, die Patches und wie gjournal arbeitet, gibt es unter:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=67275+0+current/freebsd-current
Zum Vergrößern anklicken....
Wenn wir bei Heise wären, dann müßte ich jetzt schreiben,
"Ich dachte die Soft Updates wären so toll!" :)

Aber mal im Ernst, wie groß ist die Chance, dass das in den generischen Kernel reinkommt?
Oder wird das so laufen wie bei ReiserFS und dem Linux-Kernel?
 
Ich denke die Chancen sind sehr groß.

Und privat werde ich sicherlich bei Softupdates bleiben.
Allerdings finde ich schon sehr gut, wie sauber hier mal wieder implementiert wurde. Jetzt kann man sogar seine 1,44MB Floppy mit FAT12 mit einem Journal versorgen ;)
 
Die Performanceunterschiede sind allerdings teilweise ziemlich krass:

Code: 
Copying one large file:
UFS:		8s
UFS+SU:		8s
gjournal(1):	16s
gjournal(2):	14s

Copying eight large files in parallel:
UFS:		120s
UFS+SU:		120s
gjournal(1):	184s
gjournal(2):	165s

Untaring eight src.tgz in parallel:
UFS:		791s
UFS+SU:		650s
gjournal(1):	333s
gjournal(2):	309s

Reading. grep -r on two src/ directories in parallel:
UFS:		84s
UFS+SU:		138s
gjournal(1):	102s
gjournal(2):	89s

Ich bin mir auch noch nicht ganz im klaren ob man das Journaling auf ein vorhandenes System aufsetzen kann.

Es wäre ganz interessant zu wissen, ob ich meinen SWAP für das Journal verwenden kann. Der Platz wird ja sowieso nie gebraucht.
 
@tib
Ja, SF sind vollkommen ausreichend mit bgfsck. Es wird nur dann eklig wenn man ein FS hat welches sehr gross ist und das System anfängt einen bgfsck zu starten der dann im Hintergrund Ressourcen frisst und dementsprechen lange braucht.
 
[LoN]Kamikaze schrieb:
Es wäre ganz interessant zu wissen, ob ich meinen SWAP für das Journal verwenden kann. Der Platz wird ja sowieso nie gebraucht.
Zum Vergrößern anklicken....
Das wäre doch ziemlich unsinnig, da die ungeschriebenen Journals doch nach einem Absturz vorhanden sein müssen... oder nicht? :hack:
 
Du kannst deinen Swap einfach neu partitionieren, in einen kleineren Swap und ein rohes device für das journal.

Und was die Performanceunterschiede angeht: Es sind immerhin die von Pawel geposteten Werte ;)
 
@Maledictus
Ich habe nur die Werte von Pawel zitiert, weil ich sie bemerkenswert finde. Ich selbst habe mein system natürlich noch nicht umgebaut.

Im Grunde genommen brauche ich gar keinen Swap, deswegen bin ich ja erst auf die Idee gekommen.

@Dinh
Ja, den verdienst du. Ich werde die Swap partition wohl kaum als Swap verwenden, wenn ich dort die Journals ablege.
 
[LoN]Kamikaze schrieb:
@Dinh
Ja, den verdienst du. Ich werde die Swap partition wohl kaum als Swap verwenden, wenn ich dort die Journals ablege.
Zum Vergrößern anklicken....
Achso, jetzt erst versteh' ich, was du überhaupt vorhast. Dachte, du wolltest die Journals irgendwo im (normal benutzten) Swap ablegen...
 
Oh je, wenn ich für so blöd gehalten werde...

Was hab ich blos falsch gemacht?!
 
Die Missverständnisse werden ja immer schlimmer! :D

Hab doch nur ein bisschen zu unkonzentriert gelesen und mich gefragt: wtf hat das den im Swap zu suchen. ;)
 
vor eine paar jahren hieß es aus der bsdecke noch journalling wäre des teufels - oder vielleicht besser gesagt des GNUs - werk und jetzt will man es doch haben :D

nein ehrlich ich fände es besser man würde ein dateisystem dass schon journalling hat und trotzdem "gut" performt - wie XFS - nehmen und dass ordentlich implementieren.
dann kann man seine root partition ruhig unter UFS2 ohne SU lassen und für seine daten XFS nehmen. hey das könnte man ja sogar von linux aus mounten und beschreiben....
aber das wäre vielleicht auch zu viel der interooperabilität, lieber parallel alles neu machen :kopfschüttel:
 
soul_rebel schrieb:
aber das wäre vielleicht auch zu viel der interooperabilität, lieber parallel alles neu machen :kopfschüttel:
Zum Vergrößern anklicken....
Wie lange verwendest Du schon Un*x?

Das Kommandozeilen-Adventure ist dann beendet, wenn jeder Nutzer seinen eigenen inkompatiblen Kernel hat! :)
 
soul_rebel schrieb:
vor eine paar jahren hieß es aus der bsdecke noch journalling wäre des teufels - oder vielleicht besser gesagt des GNUs - werk und jetzt will man es doch haben :D
Zum Vergrößern anklicken....
Vor ein paar Jahren in der IT... eventuell vielleicht hat sich inzwischen ein bisschen klein wenig etwas geändert. Journaling (vor allem reines Metadaten-Journaling) ist nach wie vor ein Werk des Teufels. Inzwischen sind eben die Plattenkapazitäten auf Storage-Systemen so groß geworden, dass durch reinen Pragmatismus der Zeitvorteil des Journalings beim reine-machen ein valider Punkt ist.
Die Klientel ist inzwischen da, und wird nun bedient.

nein ehrlich ich fände es besser man würde ein dateisystem dass schon journalling hat und trotzdem "gut" performt - wie XFS - nehmen und dass ordentlich implementieren.
Zum Vergrößern anklicken....
(a) XFS und ReiserFS werden ja zZ portiert.... 'ordentlich' dauert eben.
(b) XFS hat nur Metadaten-Journaling
aber das wäre vielleicht auch zu viel der interooperabilität, lieber parallel alles neu machen :kopfschüttel:
Zum Vergrößern anklicken....
Hast du Pawels Mail gelesen? Welcher Teil vom gjournal Mechanismus ist parallel neu gemacht?
Also journal (fast) unabhängig vom Dateisystem.

@Dinh: das Journal muss zwingend auf ein One-Time eli device.....
 
soul_rebel schrieb:
aber das wäre vielleicht auch zu viel der interooperabilität, lieber parallel alles neu machen :kopfschüttel:
Zum Vergrößern anklicken....

... ja, Linux hat's vorgemacht: Da wurden gleich 5 oder 6 Journaling-FS parallel entwickelt!!

Gut, in der BSD-Welt hatte man es bisher eher mit Packetfiltern, aber in Sachen Journaling sehe ich da jetzt auch noch einiges auf uns zukommen. Unter anderem gibt es im Rahmen von SoC ein neues Journaling-Projekt unter NetBSD.

Allerdings dachte ich, dass Journaling mittlerweile schon wieder "Schnee von gestern" sei, und das Zauberwort jetzt "COW" (copy-on-write) heisst?

Und warum ausgerechnet das olle XFS?
ZFS, ReiserFS-4 oder ext3cow sind doch wesentlich hipper...
 
[LoN]Kamikaze schrieb:
Oh, jemand hat's gelesen... Überraschung. Das ist das erste mal das eins meiner versteckten Kommentare entdeckt wurde.
Zum Vergrößern anklicken....
Sie sind sichtbar, sobald einer Deiner Beiträge gequotet wird. Auf den übrigen Blödsinn ist bestimmt einfach keiner eingegangen. :rolleyes:
 
(a) XFS und ReiserFS werden ja zZ portiert.... 'ordentlich' dauert eben.
Zum Vergrößern anklicken....
mhm ich sag ja besser orgnaisieren ;)
mawei schrieb:
ZFS, ReiserFS-4 oder ext3cow sind doch wesentlich hipper...
Zum Vergrößern anklicken....
ZFS is unter CDDL -> miese
mit reiserfs habe ich nur schlehte erfahrung gemacht, ext3cow noch nie ausprobiert.
aktuelle linux benchmarks zeigen deutlich, dass fast immer XFS schneller und resourcen sparender ist als andere.
 
soul_rebel schrieb:
ZFS is unter CDDL -> miese
.
Zum Vergrößern anklicken....

Ja, wirklich "mies" der Matt Dillon, will der das doch glatt nach DragonflyBSD portieren...

...von den fiesen Linux-Typen ganz zu schweigen, die im Rahmen von SoC an einer Portierung arbeiten ;)
 
soul_rebel, du laberst auch alles nach, was dir das gnu vorbetet?

CDDL ist nichtmal halb so mies wie GPL, bitte vorher informieren!

Es heisst übrigens Reiser4 und nicht ReiserFS-4 afaik.

afaik sind GPL und CDDL inkompatibel. ooooohhhhhhhhhhh :ugly:
Aber man kann es ja sicherlich als Kernelmodul implementieren, so bekommt man ja auch proprietären code in den Linuz Colonel. :ugly:³
 
soul_rebel schrieb:
mhm ich sag ja besser orgnaisieren ;)

ZFS is unter CDDL -> miese
mit reiserfs habe ich nur schlehte erfahrung gemacht, ext3cow noch nie ausprobiert.
aktuelle linux benchmarks zeigen deutlich, dass fast immer XFS schneller und resourcen sparender ist als andere.
Zum Vergrößern anklicken....

Kein Filesystem fliegt Dir allerdings bei Ausfall der USV so schnell um die Ohren wie XFS.....

Im übrigen ist die CDDL keine schlechter Lizenz als die Apache Lizenz.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben