Mic92/ltcp
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

fast fertig

Browse Source
This commit is contained in:
stoepsel93@higgsboson.tk 2014-04-03 20:49:00 +02:00
parent 3ccd5b11db
commit 5520f2e763
3 changed files with 7 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
bericht/ori/ori-con.tex
View File

@ -2,4 +2,4 @@
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 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.
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, diese Idee erfolgreich umzusetzen. Deshalb ist Ori momentan nicht zu gebrauchen.

5
bericht/ori/ori-function.tex
View File

@ -46,11 +46,12 @@ Wie aus dem Systemdiagramm ersichtlich ist, besteht Ori aus den Teilprogrammen \
\item[\emph{-- --journal-sync}] für synchrones Wiederherstellungs-Journal
\end{description}
\end{description}
\pagebreak
\item[\emph{libori}] verwaltet die Repositorien bestehend aus Index, Objekt-Speicher und Objekt-Metadaten. Die Repositorien werden lokal unter \emph{.ori} im Home-Verzeichnis gespeichert.
\end{description}
\pagebreak
Beispielverzeichnis mit einem Repo \emph{repo}: \\
\begin{tikzpicture}

6
bericht/ori/ori-ver.tex
View File

@ -38,9 +38,9 @@ Testaufruf GlusterFS:
Testaufruf OriFS:
\shellcmd{./iozone -azcR -I -f /ori-home/rep/testfile -b excel.xls} \\
\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. \\
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. \\
Lesend: \\
@ -60,6 +60,6 @@ Schreibend: \\
Auswertung: \\
Wie aus den Diagrammen ersichtlich wird, schneidet Ori angeblich sowohl beim Lesen, als auch beim Schreiben von Daten besser ab als GlusterFS. Es ist jedoch anzumerken, dass durch Fehlen der Un- und Mountoperationen Caching-Effekte aufgetreten sind, wodurch überhöhte Werte gemessen wurden. Da GlusterFS wie schon in 1.8.3.3 erwähnt, die Geschwindigkeit der Festplatte beim Lesen mit 104 MiB/s fast voll ausnutzt, liegt es nahe, OriFS ebenfalls dort einzuordnen, da beide Systeme auf FUSE aufbauen.
\pagebreak