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

ori fertig

This commit is contained in:
stoepsel93@higgsboson.tk 2014-04-04 09:31:27 +02:00
parent 6638b866aa
commit cc5ce5191b
3 changed files with 9 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
bericht/ori/ori-doc.tex
View File

@ -1,8 +1,8 @@
\subsection{Dokumentation}
Da das Projekt Ori erst im November 2013 publik gemacht wurde, gibt es bisher noch keine umfassende Dokumentation. Neben der Abhandlung >>Replication, History, and Grafting in the Ori File System<< unter: \\
Da das Projekt Ori erst im November 2013 publik gemacht wurde, gibt es bisher noch keine umfassende Dokumentation. Die Abhandlung >>Replication, History, and Grafting in the Ori File System<< unter: \\
\url{http://sigops.org/sosp/sosp13/papers/p151-mashtizadeh.pdf} \\
und der Projektseite: \\
enthält eine Reihe von Benchmarks, sowie eine Übersicht über das Design von Ori. Neben der Projektseite: \\
\url{http://ori.scs.stanford.edu} \\
existiert noch das Git-Repo zu Ori auf der Code-Hosting-Plattform Bitbucket unter: \\
\url{https://bitbucket.org/orifs/ori/wiki/Home}.

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

@ -34,7 +34,7 @@ Wie aus dem Systemdiagramm ersichtlich ist, besteht Ori aus den Teilprogrammen \
\item[\emph{hostremove [host]}] entfernt den Host \emph{host}.
\item[\emph{hosts}] listet alle eingetragenen Hosts auf.
\end{description}
\item[orifs] nutzt \emph{libFUSE}, um Repositorien als FUSE-Dateisysteme einzubinden.
\item[orifs] nutzt \emph{libFUSE}, um Repositorien als FUSE-Dateisysteme einzubinden. Desweiteren produziert \emph{orifs} automatisch in periodischen Abständen (Tag, Woche, Monat und Jahr) Snapshots.
\begin{description}
\item[\emph{[OPTIONS] mountpoint}] bindet ein Repo in \emph{mountpoint} ein. Das Verzeichnis \emph{mountpoint} muss vorhanden sein. \emph{OPTIONS} sind u.a.:
\begin{description}
@ -82,4 +82,9 @@ Beispielverzeichnis mit einem replizierten Repo \emph{repo}: \\
\altentry{orisyncrc}{1}
\end{tikzpicture}
Das Verzeichnis \emph{.ori} enthält neben dem Repo \emph{repo.ori} die beiden Logs für den Ori-Client und Orisync, sowie die Konfigurationsdatei für Orisync. Im Repo befindet sich neben einer \emph{id}, einem \emph{index} (Speicheradressierung durch Hash-Summen), dem Log und der Version von Ori, sowie den Metadaten und Snapshots, noch der Unix Domain Socket, ein Verweis auf den \emph{HEAD} des Repos und der Objektspeicher \emph{objs} mit den verschlüsselten \emph{*.pak}-Archiven, das Verzeichnis \emph{ref} bestehend aus den Unterverzeichnissen \emph{heads} (Commit-ID des Repo-Heads) und \emph{remotes} (URL des Quell-Repos). \\
Ori's Datenmodell besteht aus Commit-Objekte (Snapshots und History-Kontext), Bäume (Verzeichnisse), Blobs und LargeBlobs (Dateien). Alle Snapshots sind aufgebaut aus den Quell-Baum-Hash, den Eltern-Commit-Hash(es), einem Zeitstempel und dem Nutzernamen. Optional kann der Nutzer eine Beschreibung anhängen. Bäume vereinen den Verzeichniseintrag und die I-Node-Felder in sich. Blobs speichern Daten von weniger als 1MB, LargeBlobs teilen größere Dateien in kleinere Blobs, indem sie eine Liste von Blob-Hashes von Dateiteilen speichern. Dadurch können Blobs dedupliziert werden. Alle Objekte werden durch SHA-256-Hashes eindeutig adressiert.
\pagebreak

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

@ -4,7 +4,7 @@
Die aus der Abhandlung \href{http://sigops.org/sosp/sosp13/papers/p151-mashtizadeh.pdf}{>>Replication, History, and Grafting in the Ori File System<<} von Entwicklern der Standford University stammende Grafik >>Figure 1<< zeigt eine bespielhafte Nutzung von Ori. Das Dateisystem eines Nutzers wurde über mehrere Geräte repliziert. Ein Freund des Nutzers hat mit Hilfe des Grafting eines der Verzeichnisse des Nutzers in sein eigenes Dateisystem übertragen. Änderungen an den übertragenen Dateien sollen später manuell synchronisiert werden können. \\
Wenn ein Verzeichnis Q als Verzeichnis Z in das Ziel-Dateisystem übertragen wird, soll dort ein spezieller Commit-Eintrag erstellt werden. Dieser enthält zusätzlich zu einem normalen Eintrag die UUID des Quell-Dateisystems \emph{graft-fsid}, den Quell-Pfadnamen \emph{graft-path}, einen Hash des Original-Commits aus dem Quell-Dateisystem \emph{graft-commit} und den Ziel-Pfadnamen \emph{graft-target}. \\
Wenn ein Verzeichnis Q als Verzeichnis Z in das Ziel-Dateisystem übertragen wird, soll dort ein spezieller Commit-Eintrag erstellt werden. Dieser enthält zusätzlich zu einem normalen Eintrag die UUID des Quell-Dateisystems \emph{graft-fsid}, den Quell-Pfadnamen \emph{graft-path}, einen Hash des Original-Commits aus dem Quell-Dateisystem \emph{graft-commit} und den Ziel-Pfadnamen \emph{graft-target}. Ist das Quell-Verzeichnis selbst gegrafted worden, werden dessen Quell-Informationen eingetragen. \\
Das Grafting soll mit Hilfe dieses Befehls ausgeführt werden: