mrmcd111b

OpenSolaris (10 Min + 5 Min Diskussion)
Bei Sun Microsystems wurde beschlossen, Solaris in  den OpenSource überzuführen. Dieser Prozess wurde im Juni  2005 angefangen.
Heute befindet man sich in der Situation, dass es von Sun  noch alte Distributionen von Solaris gibt, die nicht im  OpenSource sind (Solaris …, 8, 9 und 10) sowie die neuen  Distributionen (OpenSolaris ) die schon OpenSource sind.
Alle diese Distributionen lassen sich kostenfrei herunterladen  und benutzen.
Für die Solaris Distributionen ist voller Support und  OpenSolaris 2008.05 ist eingeschränkter Support verfügbar.
Der Support für OpenSolaris wird schrittweise ausgebaut werden.  Der Nachfolger von Solaris 10 wird auf OpenSolaris basieren,  der Source und voller Support wird verfügbar sein.

Dtrace - Dynamic Tracing (20 Min + 10 Min Vorführung und Diskussion)
Dtrace ist ein Beispiel für die neuen Projekte im OpenSolaris,  die schon Eingang in andere Betriebssysteme gefunden haben.

Mit Dtrace wird die Sichtweise auf den Kernel bzw. auf die  Arbeitsweise von Programmen verändert. Statt einzelne Prozesse  bis zum Systemcall zu untersuchen ist mit Dtrace der gesamte Ablauf
auch im Kernel beobachtbar. Dazu ist ein generelles System zum  Beobachten von Kernel-Modulen erstellt worden, das zusätzlich immer  auch den Kontext des rufenden User-Programms kennt.
Daher sind einzelne Programme, zusammenarbeitende Programme oder  auch der Ablauf im Kernel beobachtbar.
Um solche Beobachtungen effizient zu ermöglichen wurden verschiedene  Design-Entscheidungen getroffen:

• Messungen dürfen keine Locks im Kernel nutzen
• Daten müssen effizient verarbeitet werden
• Der Overhead ohne Messungen muss minimal sein

Realisiert wird Dtrace durch eine Bibliothek libdtrace,  die die dtrace Kernel-Möglichkeiten verschiedenen
Anwendungsprogrammen - auch eigenen - zur Verfügung stellt.  Das Userland-Programm dtrace nutzt ebenfalls die libdtrace.

Wie funktioniert dtrace?
Mit einem D-Programm wird eine Anfrage gestartet.  Die Sprache D ist C-artig und ist ähnlich wie die Sprache  AWK limitiert.  Ein D-Programm besteht aus Klauseln, die Datenwerte an spezifizierten  Messpunkten im Kernel oder im Userprogramm nutzen können.  Ob die Daten verarbeitet werden lässt sich mit Bedingungen pro  Messpunkt einschränken.
Aus den Daten kann man dann einfache Ausgaben, formatierte Ausgaben  oder Statistiken erstellen, wobei die Statistikfunktionen Bestandteil  von dtrace sind.
Die Implementierung nutzt an jedem potentiellen Messpunkt eine  Liste von Callback-Funktionen. Solange diese Liste leer ist ist der  Overhead extrem klein.  Wenn ein Messpunkt benutzt wird, dann wird eine Callback-Funktion  addiert, die lediglich die Bedingung prüft und dann gegebenenfalls die
benötigten Daten in einen zirkulären gesharten Puffer schreibt;  das Schreiben erfolgt unsynchronisiert und daher sehr effizient  Das Anwendungsprogramm liest regelmässig (1x pro Sekunde) die
aufgelaufenen Daten aus dem gesharten Puffer.
Gerade wenn viel gemessen wird, ist das Verhältnis von Lesevorgängen zu Daten sehr effizient.  Ist weniger los, dann ist die Bearbeitung zwar weniger effizient, allerdings ist das nicht negativ zu bewerten,  weil dann ja noch genug Ressourcen da sind.

ZFS - Design und Möglichkeiten (45 Min)
ZFS ist ein Filesystem einer neuen Generation.
Erstmals wurde auf den Volume Manager verzichtet und diese Funktion mit ins Filesystem integriert. Eigentlich macht das Sinn, weil Filesystem und Volume Manager verwalten jeweils die gleichen Dinge.
Das Filesystem verwaltet Datenbereiche in Form von konfigurierbaren Stücken Plattenspeicher. Die Datenbereiche sind benannt, meist in hierarchischer Form angeordnet und man nennt sie Dateien.
Ein Volume Manager verwaltet Datenbereiche in Form von konfigurierten Stücken Plattenspeicher. Die Datenbereiche sind benannt, meist nicht hierarchisch angeordnet, können mit Redundanzverfahren (RAID-1, RAID-5, RAID-6, RAID-*… kombiniert werden und man nennt sie Volumes.
Warum werden in bisherigen Systemen diese beiden Dinge immer kombiniert, obwohl sie doch augenscheinlich das Gleiche tun? Zumal man bei näherem Hinsehen noch weitere Nachteile findet,
weil ein Filesystem nicht optimieren kann, weil es gar nicht weiss, ob und wieviele Platten im Volume sind und wo ohne Nachteile paralell I/O Vorgänge angestossen werden können.
Der Volumemanager kann auch nicht optimieren, weil die Konsistenz des Filesystem (bzw. der Check derselben via fsck) hängt an der Reihenfolge der Schreibvorgänge; die darf daher vom Volume-Manager
nicht verändert werden. Hier zeigt sich, das ohne weitere Transparenz die Optimierung leidet.
Ein anderer Punkt sind die Redundanz-Verfahren im Volume Manager. Diese können nämlich vom Filesystem nicht genutzt werden, da es beim Volume schlicht kein programmatisches Interface gibt,
eine alternative Deutung eines Blocks anzufordern.

Selbst wenn das Filesystem weiss, dass der Block so nicht richtig sein kann, gibt es keine Möglichkeit automatisch den anderen Block des Spiegels zu lesen.
Um diese Sackgassen zu entfernen wurde mit ZFS ein neues Filesystem geschaffen, dass noch eine Reihe weitere Verbesserungen enthält:
Alle Blöcke eines ZFS sind mit langen Prüfsummen geschützt (256 Bit)

• ZFS enthält den Volumemanager
• ZFS kann RAID-1/RAID-5/RAID-6 nutzen, um defekte Blöcke wieder zu rekonstruieren und zu reparieren.
• ZFS hat eine vereinfachte Administration
• ZFS arbeitet mit Transaktionen auf den Platten, ein fsck ist nie mehr notwendig.
• ZFS hat unlimitierte Snapshots