Neuer gvinum geht in -CURRENT ein

Yamagi

Yamagi

Possessed With Psi Powers
Teammitglied
Früher einmal war "vinum" der bekannteste und zuverlässigste Weg unter FreeBSD Softraids und Volumenmanagement aller Art zu implementieren. Als ein Klon des im professionellen Umfeld seinerzeit sehr verbreiteten Veritas Volume Managers war vinum sehr leistungsfähig und beliebt. Dann jedoch kam FreeBSD 5 und brachte GEOM mit. Damit funktionierte der alte vinum nicht mehr, er wurde auf "gvinum" aktualisiert. Doch gvinum war nie fertig gestellt worden, ihm fehlte Funktionalität und Geschwindigkeit. Darunter so wichtige Dinge wie ein "online rebuild", also das Neubauen eingehängter Pleyes (Volumes). Wurde er mit FreeBSD 7.0 zumindest soweit feherfrei, dass man ihn wieder benutzen konnte, kommt nun eine weitere Aktualisierung.

In den letzten Jahren haben Ulf Lilleengen und Lukas Ertl im Rahmen des Google SoC sowie ind er Zeit danach gvinum grundlegend überarbeitet. Die fehlenden Funktionen wurden eingebaut, die Architektur grundlegend überarbeitet und eine ganze Reihe Fehler beseitigt. gvinum kann nun wieder zur Laufzeit eingehängt und ausgehängt werden, man kann diverse RAID-Typen nutzen (mirror, stripe, concat, raid5), Plexes können wieder aufgebaut werden, wärend das System läuft und genutzt wird, defekte Laufwerke verschwinden nicht mehr ohne Warnung, Plexes können zur Laufzeit erweitert werden, etc. Viele dieser Funktionalität ist schon durch andere GEOM-Klassen abgedeckt, aber dennoch ist gvinum sinnvoll. Erfüllt es doch den Ruf nach einem integrierten Volumenmanager abseits von ZFS.

Ulf Lilleengen schrieb:
Date: Mon, 16 Mar 2009 16:58:00 +0100
From: Ulf Lilleengen <lulf@FreeBSD.org>
To: freebsd-current@freebsd.org
Cc: freebsd-arch@freebsd.org, freebsd-geom@freebsd.org
Subject: [HEADS UP] Merge of projects/gvinum to head

[-- PGP Ausgabe folgt (aktuelle Zeit: Di 17 Mär 09:57:51 2009) --]
gpg: WARNING: This version has been built with support for the Camellia cipher.
gpg: It is for testing only and is NOT for production use!
Warning: using insecure memory!
gpg: Unterschrift vom Mo 16 Mär 16:57:52 2009 CET mittels DSA-Schlüssel ID
+73087425
gpg: Korrekte Unterschrift von "Ulf Lilleengen <lulf@idi.ntnu.no>"
gpg: alias "Ulf Lilleengen <lulf@bbnett.no>"
gpg: alias "Ulf Lilleengen <lulf@FreeBSD.org>"
gpg: alias "Ulf Lilleengen <lulf@pvv.ntnu.no>"
gpg: alias "Ulf Lilleengen <lulf@kerneled.com>"
gpg: alias "Ulf Lilleengen <lulf@kerneled.org>"
gpg: alias "Ulf Lilleengen <lulf@stud.ntnu.no>"
gpg: WARNUNG: Dieser Schlüssel trägt keine vertrauenswürdige Signatur!
gpg: Es gibt keinen Hinweis, daß die Signatur wirklich dem vorgeblichen
+Besitzer gehört.
Haupt-Fingerabdruck = FDC2 6422 3949 9965 0F33 8726 0882 E0F2 7308 7425
[-- Ende der PGP-Ausgabe --]

[-- Die folgenden Daten sind signiert --]

Hello,

This is a heads-up for a merge of gvinum project code into HEAD. This means
that gvinum implementation will be changed some. The code is based on the
work done by Lukas Ertl as well as the work I did before/during Google SoC
2007 and afterwards. It has been staying in p4 for some time, and then moved
to the subversion project repository not long ago. The main reason for the
delay of getting this into HEAD have been the lack of reviewers of the code,
but after some discussion and help from testers, I've decided this is a good
time to get it in (should perhaps have been merged a bit earlier) Testers
have spotted several differences from the original gvinum, and I've tried to
make it behave as the old implementation wherever that seemed the best way to
go. Luckily, the work has gotten a bit of attention lately, thanks to Rick C.
Petty for helping out with testing and bugfixing, as well as all others who
have dared to run the new gvinum. So, what does this update offer?

From the user aspect:
- Implementation of many of the missing commands from the old vinum:
attach/detach, start (was partially implemented), stop (was partially
implemented), concat, mirror, stripe, raid5 (shortcuts for creating volumes
with one plex of these organizations).
- Support for fixing degraded plexes while mounted. - Support for growing
for striped and raid5-plexes, meaning that one can extend the volumes for
these plex types in addition to the concat type. Also works while the
volume is mounted.
- The parity check and rebuild no longer goes between userland/kernel,
meaning that your gvinum command will not stay and wait forever for the
rebuild to finish. You can instead watch the status with the list command.
- Many problems with gvinum have been reported since 5.x, and some has been
hard to fix due to the complicated architecture. Hopefully, it should be
more stable and better handle edge cases that previously made gvinum
crash.
- Failed drives no longer disappears entirely, but now leave behind a dummy
drive that makes sure the original state is not forgotten in case the
system is rebooted between drive failures/swaps.

From the technical aspect:
- Gvinum now uses one single workerthread instead of one thread for each
volume and each plex. The reason for this is that the previous scheme was
very complex, and was the cause of many of the bugs discovered in gvinum.
Instead, gvinum now uses one worker thread with an event queue, quite
similar to what used in gmirror.
- The rebuild/grow/initialize/parity check routines no longer runs in
separate threads, but are run as regular I/O requests with special flags.
This made it easier to support on-mount growing and parity rebuild.

Probably, there are many other issues that have been fixed, perhaps new
issues introduced. This is why this is dropped in HEAD now, to give it more
attention from the uses before the 8.0 branch. All in all, this will make
gvinum an easier beast to handle for users. If you have any issues related to
this, send in problem reports or drop me an e-mail, and I'll take a look.
For interested reviewers, the code resides in
svn://svn.freebsd.org/base/projects/gvinum

--
Ulf Lilleengen

[-- Ende der signierten Daten --]
Zum Vergrößern anklicken....
 
Hmm Jamm, lecker. Ich freue mich immer mehr auf 8.0! ZFS v.13 und ein funktionierendes gvinum - das verkrafte ich ja gar nicht ;)
 
Rofl, alleine die Vorstellung ZFS auf gvinum finde ich amüsant.

Was ich hier ja auch interessant finde ist die Verschlüsselungsunterstützung. Hier ist man wohl mittels Geli weiter als ZFS selbst. Die Cryptounterstützung in ZFS steckt noch stark in den Kinderschuhen, wobei Geli problemlos mit ZFS und auch gvinum basierten Arrays klarkommt.

Insgesamt kann man da schon auf 8.0 gespannt sein. Ich muss sagen irgendwie freut es mich auch sehr das zu sehen, nachdem ich damals in den 5er Tagen doch ernsthaft an der Zukunft von FreeBSD gezweifelt habe.
 
Jo, ich staune auch nur noch. So ziemlich alles, was für Bisspuren in der Schreibtischplatte verantwortlich ist scheint in Ordnung gebracht zu werden. Ich bin ja eher der Moserkopp, aber auf 8 bin ich _wirklich_ gespannt. Das scheint der Meilenstein zu werden, auf den seit 5 hingearbeitet wird.
 
Ich hoffe, dass sie es auf den letzten Metern nicht versauen. Es gab da ja die Gerüchte, bzw. sogar Diskussionen, mit 8.0 bereits im April zu beginnen. Das wäre in meinen Augen aber zu früh, lieber Juni oder Juli. Es gab halt in den letzten Tagen und Wochen viele Änderungen die erst sacken müssen, vimage ist auch noch nicht komplett da... Da lieber ein wenig Ruhe und uns noch warten lassen. :)
 
Ach, FreeBSD macht eigentlich nicht viel falsch. Es gab die grausame FreeBSD 5 Serie, die man kritisieren konnte. Auch FreeBSD 6 war durchwachsen. Aber mit FreeBSD 7 hat man die Kurve bekommen, weitgehende Fehlerfreiheit, hohe Geschwindigkeit, alles in allem sehr durchdacht. Und noch verbleibende Kritikpunkte (VFS, USB) geht man mit FreeBSD 8 gezielt an. Natürlich ist nicht alles perfekt, aber wo ist es das schon? Und ich sage es mal ganz ehrlich, wem das nicht passt, kann ja auf andere Systeme wechseln. So, machen wir keine Diskussion draus, da eskaliert nur wieder in Streit.
 
Ich wollte hier keine Diskussion anfangen, nur den Leuten aufzeigen, dass der gemeinte Thread übler quatsch war.

Daumen hoch für 7.2 und noch höher für 8.x :)
 
Ist für 8 eigentlich auch schon LLVm/Clang Unterstützung eingeplantalso das Kompilieren des Kernels/Userlands mit LLVM.
Würde mich mal interessieren. DragonFly kann es ja schon. Laut Mailinglisten sogar recht gut und einem anderen Thread hier entnehme ich, dass die FreeBSD Devs auch daran arbeiten.
 
Jein. Es wird seitens FreeBSD daran gearbeitet, man kann den Kernel bereits bauen. Das Userland hakt noch ein wenig. Es ist da wohl auch ein größeres Patchset in Arbeit. Daher sagen wir mal: Wahrscheinlich ja, aber nicht auf jeden Fall. Kommt halt ein bisschen drauf an. Siehe auch http://wiki.freebsd.org/BuildingFreeBSDWithClang

Aber ich glaube, mittelfristig muss LLVM wo der Weg sein, den man gehen wird. Ganz einfach, da neue Versionen des GCC dank GPL3 nicht mehr importiert werden können. Nur bis man einen Wechsel wagen kann, wird noch viel Wasser die Elbe hinabfließen. LLVM ist noch zu jung, FreeBSD noch zu sehr auf den GCC zugeschnitten.
 
Nur bis man einen Wechsel wagen kann, wird noch viel Wasser die Elbe hinabfließen.

Passt, dann werde ich ihr etwas zuschauen, und da wir atm grade fast-Hochwasser haben gehts ja dann vielleicht etwas schneller :-D

Ja, LLVM muss definitiv der Weg sein, und ein sehr guter noch dazu wie ich finde. Es gibt keine Lizenzproblematik wie beim gcc und ich sehe bei LLVM auch die Chance viele dinge besser und sauberer zu implementieren als dies beim gcc der fall ist.
Auch ein bereich der sicher noch sehr spannend wird.
 
Yamagi schrieb:
Aber ich glaube, mittelfristig muss LLVM wo der Weg sein, den man gehen wird. Ganz einfach, da neue Versionen des GCC dank GPL3 nicht mehr importiert werden können. Nur bis man einen Wechsel wagen kann, wird noch viel Wasser die Elbe hinabfließen. LLVM ist noch zu jung, FreeBSD noch zu sehr auf den GCC zugeschnitten.
Zum Vergrößern anklicken....

LLVM verwendet GCC. Da ist lizenz-technisch nichts gewonnen.

Außerdem meinst du dass neue GCC-Versionen nicht importiert werden wollen, niemand hindert FreeBSD dran ;)

Man darf ja gerne gegen GPL sein, aber was an der GPLv3 schlimmer ist als an der GPLv2 konnte bis jetzt auch niemand erklären.
Wenn man das weiterhin behauptet, ohne das irgendwie belegen zu können, dann unterstützt man die Verbreitung von FUD.

In vielen Fällen dürften besonders BSD-User die Änderungen, gerade in der LGPLv3, begrüßen, da diese die Unklarheiten/Ungenauigkeiten um Inline-Funktionen und Linken von C++-Programmen behebt.
 
Jo, die Bemühungen gehen um clang. Mit dem GCC-Forentend würde das System sicher viel einfacher anzupassen sein. :)
 
Ich glaube, dass das Frontend die Sprache in irgendeine allgemeine Datenstruktur parst und das Backend diese dann in ein Binary für die verschiedenen Architekturen verwandelt.
 
soul_rebel schrieb:
...
Man darf ja gerne gegen GPL sein, aber was an der GPLv3 schlimmer ist als an der GPLv2 konnte bis jetzt auch niemand erklären...
Zum Vergrößern anklicken....
Ich glaube es geht um die Patent-Klauseln in der v3. Man verliert Nutzungsrechte, wenn man Techniken patentiert die in v3-Software verwendet werden (oder so etwas in der Art, ist nur aus dem Sumpf meines Gedächtnisses). Vermutlich ist das FreeBSD Core Team nicht der Meinung, dass man die Nutzungsrechte aufheben sollte, weil jemand ein bestimmtes Patent hält.
 
Nun, ich will hier keine Lizenzdiskussion starten, denn die sind fruchtlos und wir hatten sie schon etwa 100 Male. Jetztendlich ist die Lizenz etwas, was der Entwickler einer Software für sich allein entscheidet und diese Entscheidung ist zu akzeptieren. Basta. Das sollte an dieser Stelle präventiv einmal gesagt sein. :)

Die FreeBSD Foundation schrieb im Sommer 2007 - als die GPL3 gerade neu war - einen offenen Brief. Dieser gibt natürlich nur ihre Ansichten wieder und nicht die von FreeBSD, FreeBSDs Coreteam und seinen Entwicklern. Steht so auch drin. Aber dennoch sagt er eigentlich zwischen den Zeilen alles, was gesagt werden muss.

The comments below represent the opinions of the FreeBSD Foundation, not the FreeBSD project or the FreeBSD Core Team.

On June 29th, the Free Software Foundation unveiled version 3 of the GNU General Public license (GPL). Even though the majority of software included in the FreeBSD distribution is not covered by any version of the GPL, our community cannot ignore this very popular license or its most recent incarnation. Through extremely successful evangelization, and the popularity of Linux, the misconception that OpenSource and the GPL are synonymous has become pervasive.

This misconception isn't new, so why write about it now? Version 3 has further "refined" the GPL's concept of "free" software. Some use models that were possible under "loopholes" in GPLv2 are now explicitly forbidden in GPLv3. Appliance vendors in particular have the most to lose if the large body of software currently licensed under GPLv2 today migrates to the new license. They will no longer have the freedom to use GPLv3 software and restrict modification of the software installed on their hardware. High support costs ("I modified the web server on my Widget 2000 and it stopped running...") and being unable to guarantee adherence to specifications in order to gain licensing (e.g. FCC spectrum use, Cable TV and media DRM requirements) are only two of a growing list of issues for these users. In short, there is a large base of OpenSource consumers that are suddenly very interested in understanding alternatives to GPL licensed software.

Against the backdrop of GPLv3, the stark difference between the BSD licensing philosophy and that of the Free Software Foundation are only too clear. Consider this quote from FSF founder Richard M. Stallman:
"It has been, essentially, sixteen years since GPL version 2 came out. We didn't think it would be this long before we made the next version, and we'll try to attend to future upgrade needs more quickly. We won't wait more than a decade, this time."

A GPL proponent might argue that a license for free software must be upgraded periodically since we cannot anticipate what new use models for free software might be developed that restrict freedom. The BSD license is as permissive as possible exactly because we cannot predict the future or to what beneficial purpose (commercial or otherwise) our software will be used.

As a community, this is the perfect time to clarify these differences. Toward that end, the FreeBSD Foundation has started to engage with large current and potential users of OpenSource software to understand their use models and how the GPLv3 might impact them. What is clear from the early results of this initiative is that the GPLv3 is a critical concern for many current commercial users of OpenSource software. As these companies devise strategies for dealing with GPLv3, so must the FreeBSD community - strategies that capitalize on this opportunity to increase adoption of FreeBSD.

Through our outreach efforts and support of legal services to the FreeBSD core team, the FreeBSD Foundation is working to guarantee our community has all the necessary resources and information to develop an effective response to version 3 of the GPL. However, to be effective, the members of our community must engage on this issue, understand the importance of our licensing philosophy, and promote that philosophy to others. This is a unique opportunity. Please help us to make the most of it!

Justin T. Gibbs

Vice President and Founder

The FreeBSD Foundation
Zum Vergrößern anklicken....

Die Quelle: http://www.freebsdfoundation.org/press/2007Aug-newsletter.shtml
 
snapshots?

du merkst nun gleich: hier kommt wieder mal ne platte Frage eines DAU:

Du sagtest, daß dies (und andere Optionen auch) in CURRENT eingebaut werden.
Ich nehme an, daß dies jeweils brandaktuell ist.
Wenn ich mir nun einen snapshot downloade, kann der das natürlich noch nicht drinnen haben?
Diese snapshots werden ja (ca) monatlich veröffentlicht und sehen mir eigentlich ziemlich komplett aus.

Im Umkehrschluß: wenn du uns im Februar die Neuigkeiten erklärst, sind die dann in den snapshots 200903... drin?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben