treeentry -> altentry

TODO function und rest vergleich glusterfs

bericht/chef/chef-comparison.tex

@@ -64,7 +64,7 @@ Nachfolgend ist die Ordnerstruktur eines Cookbooks am Beispiel von
   \altentry{default.rb}{2}
 \altentry{files}{1}
   \altentry{default}{2}
-    \treeentry{apt-proxy-v2.conf}{3}
+    \altentry{apt-proxy-v2.conf}{3}
 \altentry{libraries}{1}
   \altentry{helpers.rb}{2}
   \altentry{network.rb}{2}
@@ -84,7 +84,7 @@ Nachfolgend ist die Ordnerstruktur eines Cookbooks am Beispiel von
     \altentry{01proxy.erb}{3}
     \altentry{acng.conf.erb}{3}
   \altentry{ubuntu-10.04}{2}
-    \treeentry{acng.conf.erb}{3}
+    \altentry{acng.conf.erb}{3}
 \altentry{CHANGELOG}{1}
 \altentry{metadata.json}{1}
 \altentry{metadata.rb}{1}

bericht/ori/ori-con.tex

@@ -1,5 +1,5 @@
 \subsection{Fazit}
 
-Während meiner Ausarbeitung stieß immer wieder auf Funktionen, die zwar in der Abhandlung oder im Manual aufgeführt sind, aber nur teilweise bzw. überhaupt nicht funktionierten. Es war mir nicht möglich die automatische Synchronisation \emph{orisync} erfolgreich zu starten. Auch Segmentation Faults oder undefinierte Fehler traten immer wieder auf. \\
+Während meiner Ausarbeitung stieß immer wieder auf Funktionen, die zwar in der Abhandlung oder in den Man-Pages aufgeführt sind, aber nur teilweise bzw. überhaupt nicht funktionierten. Es war mir nicht möglich die automatische Synchronisation \emph{orisync} erfolgreich zu starten. Auch Segmentation Faults oder undefinierte Fehler traten immer wieder auf. \\
 
-Abschließend möchte ich noch sagen, dass zwar Ori einen guten Ansatz darin hat, Speicherdienst, Dateisystem und Versionskontrollsystem in sich zu vereinen, aber noch in fast allen Bereichen scheitert. Deshalb ist Ori momentan nicht zu gebrauchen.
+Abschließend möchte ich noch sagen, dass Ori zwar einen guten Ansatz darin gefunden hat, Speicherdienst, Dateisystem und Versionskontrollsystem in sich zu vereinen, aber noch in fast allen Bereichen scheitert, diesen erfolgreich umzusetzen. Deshalb ist Ori momentan nicht zu gebrauchen.

bericht/ori/ori-function.tex

@@ -5,7 +5,7 @@
 Wie aus dem Systemdiagramm ersichtlich ist, besteht Ori aus den Teilprogrammen \emph{ori}, \emph{orisync} und \emph{orifs}, die auf \emph{libori} aufgebaut sind.
 
 \begin{description}
-	\item[\emph{ori}] stellt die Schnittstelle zum Nutzer dar. Hier werden Repositorien erstellt, gelöscht und manuelle Operationen ausgeführt. Folgende Befehle sind implementiert:
+	\item[\emph{ori}] stellt die Schnittstelle zum Nutzer dar. Hier werden Repositorien erstellt, gelöscht und manuelle Operationen ausgeführt. Folgende Befehle sind laut Hilfe u.a. implementiert:
 	\begin{description}
 		\item[\emph{newfs [name]}] erstellt ein neues Repo namens \emph{name}.
 		\item[\emph{removefs [name]}] löscht das Repo \emph{name}.
@@ -13,12 +13,16 @@ Wie aus dem Systemdiagramm ersichtlich ist, besteht Ori aus den Teilprogrammen \
 		\item[\emph{status}] gibt eine Liste modifizierter Dateien aus.
 		\item[\emph{diff}] zeigt alle Änderungen seit dem letzten Snapshot an.
 		\item[\emph{snapshot [description]}] erstellt einen Snapshot mit einer optionalen \emph{description}. Zugleich wird das Repo eingecheckt.
-		\item[\emph{purgesnapshot [commitid]}] löscht den Snapshot zu \emph{commitid} und gibt Speicher frei. 
+		\item[\emph{purgesnapshot [commitid]}] löscht den Snapshot zu \emph{commitid} und gibt Speicher frei.
+		\item[\emph{snapshots}] gibt eine Liste aller für das Repo vorhandennen Snapshots aus. 
 		\item[\emph{log}] zeigt die History des Repos an.
+		\item[\emph{filelog [file]}] zeigt die History der Datei \emph{file} an.
 		\item[\emph{replicate [node:repo]}] repliziert das Repo \emph{repo} von Node \emph{node}.
 		\item[\emph{pull}] synchronisiert manuell das Repo.
 		\item[\emph{merge [commitid]}] vereinigt manuell das vorhandene Repo mit dem von \emph{commitid}.
 		\item[\emph{checkout [commitid]}] checkt das Repo mit \emph{commitid} lokal aus.
+		\item[\emph{tip}] gibt die letzte Commit-ID des Repos aus.
+		\item[\emph{show}] zeigt Informationen zum Repo (Verzeichnis, UUID und HEAD des Repos, sowie aktuelle Version von Ori) an. 
 	\end{description}
 	\item[\emph{orisync}] entdeckt andere Kopien eines Repos und synchronisiert diese automatisch.
 	\begin{description}
@@ -46,3 +50,34 @@ Wie aus dem Systemdiagramm ersichtlich ist, besteht Ori aus den Teilprogrammen \
 \end{description}
 
 \pagebreak
+
+Beispielverzeichnis mit einem Repo \emph{repo}: \\
+
+\begin{tikzpicture}
+	\treeroot{.ori/}
+		\altentry{repo.ori/}{1}
+			\altentry{objs/}{2}
+				\altentry{pack0.pak}{3}
+			\altentry{refs/}{2}
+				\altentry{heads/}{3}
+					\altentry{default}{4}
+				\altentry{remotes/}{3}
+			\altentry{tmp/}{2}
+				\altentry{fuse/}{3}
+					\altentry{journal}{4}
+			\altentry{trusted/}{2}
+			\altentry{HEAD}{2}
+			\altentry{id}{2}
+			\altentry{index}{2}
+			\altentry{metadata}{2}
+			\altentry{ori.log}{2}
+			\altentry{README}{2}
+			\altentry{snapshots}{2}
+			\altentry{uds}{2}
+			\altentry{version}{2}
+		\altentry{oricli.log}{1}
+		\altentry{orisync.log}{1}
+		\altentry{orisyncrc}{1}
+\end{tikzpicture}
+
+\pagebreak

bericht/ori/ori-ver.tex

@@ -1,22 +1,65 @@
 \subsection{Vergleiche}
 
-Da Ori Merkmale von Speicherdiensten, verteilten Dateisystemen und Versionskontrollsystemen in sich vereint, wurden aus diesen die Vertreter Dropbox, GlusterFS und Git zu einem Vergleich herangezogen.
+Da Ori Merkmale von Speicherdiensten, Versionskontrollsystemen und verteilten Dateisystemen in sich vereint, wurden aus diesen die Vertreter Dropbox, Git und GlusterFS zu einem Vergleich herangezogen.
 
 \subsubsection{Cloud-Speicherdienst Dropbox}
 
+Dropbox speichert seine Daten in der Cloud auf einem oder mehreren Servern, Ori hingegen seine Repositorien dezentral auf den einzelnen Nodes. Dies erhöht die Sicherheit der Daten, da nur Nutzer mit ssh-Zugang einfachen Zugriff auf diese erhalten. Desweiteren sind die Daten besser vor Verlust geschützt, da mit einer einzigen Kopie eines Repos die Daten auf allen Nodes wiederhergestellt werden können. Das Grafting würde in etwa dem Freigeben bei Dropbox entsprechen, jedoch bräuchte man dort keinen direkten Zugang zu einem Node und die Synchronisation des freigegeben Verzeichnis erfolgt automatisch. Bei Dropbox ist es außerdem möglich Verzeichnisse und Dateien für alle öffentlich im Internet zugänglich zu machen. Mit einem funktionierenden \emph{orisync} könnte auch bei Ori die Synchronisation der Daten zwischen den Nodes realisiert werden.
+
+
+\subsubsection{Versionskontrollsystem Git}
+
+Die Versionsverwaltung von Ori ähnelt sehr der von Git. So entsprechen sich die Befehle \emph{ori snapshot} und \emph{git commit}. \emph{ori pull} und \emph{ori checkout [commitid]} bilden zusammen die Funktion von \emph{git pull} ab. Darüber hinaus ist der Funktionsumfang von Git größer als der von Ori. Um Ori und Git zu vergleichen, haben die Entwickler den FUSE-Treiber deaktiviert und Ori als einfaches Checkin/Checkout-Programm vermessen. Laut ihren Angaben waren die adds und commits, sowie Klon-Operationen von Ori um 64 bzw. 70\% schneller als die von Git. Bei den Repositorien-Größen wurden von den Entwicklern folgende Werte gemessen:
+
+\begin{center}
+	\begin{tabular}{|l|r|r|r|}
+		\hline
+		Data Set & Raw Size & Ori & Git \\ \hline
+		Linux Snapshot & 537.6MB & 450.0MB & 253.0MB \\ \hline
+		Zlib & 3.044MB & 2.480MB & 2.284MB \\ \hline
+		Wget & 13.82MB & 12.46MB & 6.992MB \\ \hline
+		User Documents & 4.5GB & 4.6GB & 3.4GB \\ \hline
+		Tarfiles & 2.8GB & 2.3GB & 2.3GB \\ \hline
+	\end{tabular}
+\end{center}
+
+Es ist ersichtlich, dass Git gegenüber Ori bei der Speichernutzung im Vorteil ist. Die Unterschiede in Geschwindigkeit und Speichernutzung liegen an den unterschiedlichen Kompressionsarten. Während Git eine Kombination aus Ganz-File-Dedublizierung, differentieller Kompression und einfacher Kompression verwendet, nutzt Ori nur Unter-File-Dedublizierung und einfache Kompression. Aufgrund der fehlenden differentiellen Kompression ist Ori im Gegensatz zu Git in der Lage, Snapshots zu löschen, da keine extra Dekompressions- und Kompressionsschritte benötigt werden.
+
+\pagebreak
+
+
 \subsubsection{Verteiltes Dateisystem GlusterFS}
 
 Um Ori mit mit dem Dateisystem GlusterFS zu vergleichen, wurde auch Ori mit dem IOzone-Benchmark vermessen und die dabei aufgezeichneten Werte mit denen aus der Benchmark-Aufgabe verglichen. \\
 
-	\hfill \includegraphics[scale=1]{benchmarks/ori/iozone-fastfs-read-tmpl.pdf} \hspace*{\fill}
+Testaufruf GlusterFS:
-	
-	\hfill \includegraphics[scale=1]{benchmarks/ori/iozone-orifs-read-tmpl.pdf} \hspace*{\fill}
-		
-	\hfill \includegraphics[scale=1]{benchmarks/ori/iozone-fastfs-write-tmpl.pdf} \hspace*{\fill}
 
-	\hfill \includegraphics[scale=1]{benchmarks/ori/iozone-orifs-write-tmpl.pdf} \hspace*{\fill}
+\shellcmd{./iozone -azcR -+q 1 -U /fastfs -f /fastfs/testfile -b excel-fastfs.xls}
-	
-\subsubsection{Versionskontrollsystem Git}
 
+Testaufruf OriFS:
+
+\shellcmd{./iozone -azcR -I -f /ori-home/rep/testfile -b excel.xls} \\
+
+Beim Vermessen von \emph{orifs} wurde die Option \emph{-U /ori-home/rep} weggelassen, weil \emph{orifs} vom System nicht automatisch un- und gemounted werden kann. Dadurch können während des Testens Caching-Effekte aufgetreten sein und die gemessenen Werte nach oben hin abweichen. \\
+
+Lesend: \\
+
+	\hfill \includegraphics[scale=1.1]{benchmarks/ori/iozone-fastfs-read-tmpl.pdf} \hspace*{\fill}
+	
+\vspace{1cm}
+	
+	\hfill \includegraphics[scale=1.1]{benchmarks/ori/iozone-orifs-read-tmpl.pdf} \hspace*{\fill}
+
+Schreibend: \\
+
+	\hfill \includegraphics[scale=1.1]{benchmarks/ori/iozone-fastfs-write-tmpl.pdf} \hspace*{\fill}
+
+\vspace{1cm}
+
+	\hfill \includegraphics[scale=1.1]{benchmarks/ori/iozone-orifs-write-tmpl.pdf} \hspace*{\fill}
+
+Auswertung: \\
+
+	
 
 \pagebreak