Journaling-Dateisystem für NetBSD fertiggestellt

M

mawei

Well-Known Member
Seit geraumer Zeit wurde daran gearbeitet und nun ist es soweit: NetBSD-Entwickler Simon Burge hat für das FFS-Dateisystem Metadaten-Journaling implementiert. Damit verfügt die Familie der BSD-Betriebssysteme über ein weiteres Journaling-Dateisystem. Möglich wird dies, nachdem das Unternehmen "Wasabi Systems" den ursprünglich von Darrin B. Jewell entwickelten Code an das NetBSD-Projekt spendiert hatte.

Neben Simon Burge, waren auch die Entwickler Greg Oster, Antti Kantee,und Andrew Doran maßgeblich an der Implementierung für NetBSD beteiligt.

Für die NetBSD-Anwender ist dies ein großer Schritt nach vorne, zumal sich die meisten Entwickler nie so recht mit der von FreeBSD übernommenen soft-dependencies Technologie ("softupdates") anfreunden konnten.

Längeren Warte- und Ausfallzeiten aufgrund von notwendigen Dateisystem-Überprüfungen nach Systemabstürzen gehören damit weitestgehend der Vergangenheit an - zurzeit jedoch nur mit einem ganz frischen NetBSD-current oder bald mit dem Release von NetBSD 5.0.

Zur Ankündigung auf der NetBSD-Projektseite: http://netbsd.org/changes/#wapbl
 
soul_rebel schrieb:
Und so divergieren die BSD-CodeBases weiter ....
Zum Vergrößern anklicken....

Na, das ist doch der Sinn von getrennten Projekten, oder? Weil welchen Sinn hat es sonst, das ich z.B. FreeBSD und NetBSD zur Auswahl habe, wenn es eh keinen Unterschied, bis auf den Namen, gibt?

Wichtig ist eigentlich nur, das die Schnittstelle gleich bleibt. Das wird sich mit dem neuen FS ja nicht ändern?
 
Amin schrieb:
Na, das ist doch der Sinn von getrennten Projekten, oder? Weil welchen Sinn hat es sonst, das ich z.B. FreeBSD und NetBSD zur Auswahl habe, wenn es eh keinen Unterschied, bis auf den Namen, gibt?

Wichtig ist eigentlich nur, das die Schnittstelle gleich bleibt. Das wird sich mit dem neuen FS ja nicht ändern?
Zum Vergrößern anklicken....

Naja, es gibt Diversität die gut ist und welche die unnütz ist.
* Dass vier BSDs mit unterschiedlicher Schwehrpunktsetzung unterschiedliche Kernels haben: sinnvoll.
* Dass bestimmte BSDS mit bestimmten Focus mehr Zeit in bestimmte Projekte investieren: sinnvoll.
* Dass alle disklabel und UFS-Implementierungen am Ende von einander abweichen: sinnvoll?
* Dass jedes BSD seine eigene Implementierung von ifconfig, route etc mit eigener Syntax rumschleppt: sinnvoll?

Aber was solls. Ich habe noch nie wirklich NetBSD benutzt und habe noch keine Person im real-life getroffen die dies tut, insofern werde ich sobald auch keine NetBSD-Dateisysteme mounten müssen ;)
 
Ich finde den Vorstoß gut. Wenn sich FFS+Journal in der (NetBSD-)Praxis als stabil erweist, wäre das doch eine Sache, die andere BSDs übernehmen könnten. IMHO hat insbesondere OpenBSD noch Nachholbedarf, was das Dateisystem angeht (FreeBSD scheint ja mehr auf ZFS zu setzen, da wäre ein verbessertes FFS/UFS nicht so dringend nötig)...
 
ZFS wird meiner Meinung nach wenn dann nur langfristig das Standarddateisystem werden. Bisher setzt ja sogar Solaris noch auf UFS.
Gerade weil sich FreeBSD im Moment auch in den Embedded-Bereich orientiert (ARM, MIPS, z.B. NLSU2) wird UFS wegen des horrenden Speicherhungers von ZFS die erste Wahl bleiben.
 
SierraX schrieb:
Und warum hast du jetzt nochmal das flamen angefangen?
Zum Vergrößern anklicken....
LOL, war nicht als Flame gemeint.

"Die BSDs" als Platformen könnten IMHO halt echt von mehr Zusammenarbeit in bestimmten Bereichen profitieren. Aber das scheint ja an vielen Punkten zu scheitern, selbst von den Nutzern ist das offensichtlich nichtmal erwünscht...

Und was ZFS angeht, glaube ich nicht, dass das so schnell bei FreeBSD Standard wird. Nach allem was ich jetzt drüber gelesen hab, ist das ja echt ernüchternd.
Und auf den meisten Maschinen wie Desktops, Notebooks etc brauch man den ganzen Firlefanz ja auch nicht. Da ist mir Performance wichtiger (schließlich möchte man abundzu auch andere Sachen machen als copy-on-write ;) ).
Mist das könnte man jetzt wieder als Flame werten... oh nein... ich bin weg.
 
soul_rebel schrieb:
"Die BSDs" als Platformen könnten IMHO halt echt von mehr Zusammenarbeit in bestimmten Bereichen profitieren. Aber das scheint ja an vielen Punkten zu scheitern, selbst von den Nutzern ist das offensichtlich nichtmal erwünscht...
Zum Vergrößern anklicken....

Ich denke mir das auch immer wieder, aber wie realistisch ist das? Wirkliche Kooperation hat es nach meinem Wissen zwischen den Projekten auch nie gegeben. Warum sollten die Nutzer sich also etwas wünschen, vom dem sie wissen, dass es die Entwicker gar nicht interessiert? Von der Tendenz her streben die Projekte nunmal eher auseinander als dass sie sich aufeinander zubewegen.


Und was ZFS angeht, glaube ich nicht, dass das so schnell bei FreeBSD Standard wird. Nach allem was ich jetzt drüber gelesen hab, ist das ja echt ernüchternd.
Zum Vergrößern anklicken....

Was meinst Du mit "ernüchternd" konkret, die Hardwareanforderungen?


Und auf den meisten Maschinen wie Desktops, Notebooks etc brauch man den ganzen Firlefanz ja auch nicht.
Zum Vergrößern anklicken....

Welchen "Firlefanz" meinst Du? Ich finde die meisten Funktionen von ZFS sehr sinnvoll, durchaus auch auf dem Notebook.
 
mawei schrieb:
Ich denke mir das auch immer wieder, aber wie realistisch ist das? Wirkliche Kooperation hat es nach meinem Wissen zwischen den Projekten auch nie gegeben. Warum sollten die Nutzer sich also etwas wünschen, vom dem sie wissen, dass es die Entwicker gar nicht interessiert? Von der Tendenz her streben die Projekte nunmal eher auseinander als dass sie sich aufeinander zubewegen.
Zum Vergrößern anklicken....
Ja, so ist das. War halt auch mehr Wunschdenken...
Was meinst Du mit "ernüchternd" konkret, die Hardwareanforderungen?
Zum Vergrößern anklicken....
Die Hardware-Anforderungen sind ein Hauptpunkt. Klar kann man sagen, heuzutage hat eh jeder Rechner 3GiB RAM, aber waraum genau soll jetzt mein Notebook oder Desktop ein Drittel seines Rams für Disk-IO opfern?
Und das sind sogar theoretische Notebooks und Desktops. Momentan würde ZFS die kompletten Kapazitäten meiner Maschinen verbrauchen.

Außerdem ist es nach allem, was ich bisher gehört habe auch nicht wirklich stabil. Dinge wie RSYNC sollen zu Panics führen. Zu ZFS auf Geli gibts kaum Quellen. Wahrscheinlich braucht man dann gleich zwei extra Kerne fürs FS...

Welchen "Firlefanz" meinst Du? Ich finde die meisten Funktionen von ZFS sehr sinnvoll, durchaus auch auf dem Notebook.
Zum Vergrößern anklicken....
U.u. kenn ich ja nicht alle features von ZFS, aber Dinge wie Raid, Redundanz, Snapshots und ähnliches, brauche ich auf Arbeitsmaschinen nicht. Dafür legt man die Daten ja zentral ab.
 
[OT]Zum Aufmuntern ein Artikel der Zeigt, dass der (geistige) Austausch in einer anderswo ganz gut klappt: http://kerneltrap.org/Linux/Comparing_HAMMER_And_Tux3 [/OT]

Ganz interessant, dass sich derzeit wieder etwas im Bereich Filesystems tut. Und dann geht das Gejammer "warum machen die nicht nur eines? Zusammen haben sie mehr Manpower und dann ist das auch kompatibel, ..." wieder los.

Aber überlegt mal, wie Evolution funktioniert!
Überlegt mal wo wir wären, wenn Unix nicht von ein paar computerspielesüchtigen Wissenschaftlern erstellt worden wäre! Was wären, wenn man auf zusätzliche Programmiersprachen verzichtet hätte? Seid doch froh, dass sie alle so unterschiedlich sind. Wenn alle gleich wären, gäbe es ja viel weniger Möglichkeiten zum experimentieren. Wenn mal ein BSD einen Blödsinn macht, kann man ein anderes nehmen oder das BSD sieht es ein und schnappt sich den Code von woanders. Treiber werden ja ohnehin alle hin in alle Richtungen kopiert. Ein BSD beginnt mal, dann übernimmt es das nächste, ein paar Bugs werden gefunden und ein paar Verbesserungen gemacht und irgendwann kommt es wieder zurück. Schaut euch mal die Commitmessages an, dann seht ihr das auch. Wer dazu keine Lust hat soll sich doch mal den 4.2er Song von den ach so konservativen und andere Systeme verfluchenden OpenBSDern anhören.
Das Geplänkel zwischen den BSDs ist eher oberflächlich und wird ohnehin nur von einen Teil der Entwickler und User ausgetragen. Wohl auch mehr zum Spaß oder weil man gerade Frust ablassen muss.

Ich sehr gerade, dass es etwas neues gibt: http://kerneltrap.org/Linux/Btrfs_0.16_Improved_Scalability_And_Performance
 
Ja, FreeBSD + ZFS wird noch eine Weile dauern. Aber ich möchte zu bedenken geben, dass das derzeit in FreeBSD 7 enthaltene ZFS ziemlich alter Code ist. Sun und vor allem die OpenSolaris-Community hat einiges getan, um ZFS besser skalierbar (nach unten) zu machen.
 
Ogion schrieb:
Ja, FreeBSD + ZFS wird noch eine Weile dauern. Aber ich möchte zu bedenken geben, dass das derzeit in FreeBSD 7 enthaltene ZFS ziemlich alter Code ist. Sun und vor allem die OpenSolaris-Community hat einiges getan, um ZFS besser skalierbar (nach unten) zu machen.
Zum Vergrößern anklicken....

Vorletzte Woche ist in CURRENT der neueste ZFS Code von OpenSolaris eingeflossen.
 
Dann halt dich doch ein wenig mit dem Wettern gegen ZFS zurück :D

Ist ja auch ein Fileserver FS, und wer es einsetzt sollte sich dem bewusst sein.

An dieser Stelle ein Vote für ZFS-Light, mit Copy-on-Write und Checksums, aber ohne Volume Mgmt. und Raid.
 
Also mir ist es auch mit sehr viel Gewalt nicht gelungen Pawells ZFS-Patches auf FreeBSD 8.0-CURRENT in einem Parallels mit nur 256MB RAM auf dem Macbook zum Absturz zu bringen. Es hat rsync überlebt, bonnie++, große Kopieraktionen, usw. Ich werde, sobald ich wieder zu Hause bin, das ganze nochmal richtig auf echten Rechnern testen und meine Ergebnisse hier in das Forum stellen.

Mein Problem mit FFS/UFS2 ist inzwischen, dass es kein Dateisystem der 2000er ist und auch keines der 90er. Es stammt aus dem tiefsten 80ern. Dank seines weitgehend linearen Aufbaus ist es zwar recht robust, aber schon im direkt Vergleich mit dem auch schon wieder 14 Jahre alten XFS ist es klar unterlegen. Gefühlt langsamer, selbst wenn man es async mountet. Um Zugriffe halbwegs schnell hinzubekommen, ist Dirhashing notwendig. Dann diese Sache mit den unterschiedlichen Algorithmen und dem daraus resultierenden 5% bis 10% Cachebereich, der frei gehalten werden muss.
Meine ganz persönliche Meinung ist, dass wir als BSD gut daran tun würden, uns geistig langsam mal vom heiligen FFS/UFS2 zu lösen und die Suche nach Alternativen zu beginnen. Ich denke dabei nicht an ZFS, dies ist lizenztechnisch kaum möglich und wird ressourcentechnisch wohl niemals in Bereiche kommen, dass man es als "schlank" bezeichnen kann. ZFS wird wohl immer nur ein weiteres unterstütztes Dateisystem bleiben. Ich denke auch nicht an einen weites Aufguss des Vorhandenen, sein es nun BLUFFS oder UFS3. Ein modernes Dateisytstem für BSDs wäre neu entwickelt und entsprechend modern implementiert, HAMMER wäre da _eine_ Option.
Dann ist das die Sache mit dem Jounrnaling. Journaling hat meiner Meinung nach einen Denkfehler. Es lässt Schäden am Dateisystem zu, gibt nur die Möglichkeit mit sie zu reprarieren. Das kann massiv schief gehen, ich kann inzwischen einen mehrbändigen Roman über durch Kleinigkeiten geschrottete XFS, JFS, ReiserFS, Ext3FS, etc. schreiben. Softupdates hingegen verhindern diese Schäden von vornherein, sind per Definition um weiten robuster. Nur leider haben Softupdates nach wie vor Vermittlungsprobleme und leiden unter technischem Stillstand. Da ist der gute, alte FUD, das Softupdates ein fsck brauchen würden. Sie brauchen den Dateisystemcheck nur, um noch als belegt markierten Speicher wieder freizugeben. Da es sich dabei normalerweise um Platzverluste im unteren Megabytebereich handelt, ist es kein Problem ein solches fsck Stunden oder auch Tage herauszuzögern. Wenn die Kiste Montag nenn Stromausfall hat, spricht kaum etwas dagegen das fsck am Sonnabend drauf im Hintergrund auszuführen. Nein, der von mir erträumte Nachfolger zu FFS/ZFS würde wieder auf Softupdates setzen, nur würde man bei der Konstruktion drauf achten, dass dieser letzte Grund für ein fsck wegfällt, dass man wie ein Journalingdateisystem komplett ohne auskommt. ZFS nutzt im Übrigen mit dem strengen Copy on Write Modell einen Mechanismus, der Softupdates gedanklich sehr ähnlich ist, eine Tatsache, die man sich klauen könnte.

Nur meine 2 Cents zum Thema.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben