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.
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.
Die Versionsverwaltung von Ori ähnelt sehr der von Git. So entspricht der Befehle Oris \emph{ori snapshot} den Befehlen \emph{git commit} und \emph{git push} von Git. \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:
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 Inner-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.
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. \\
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. \\
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.
