diff options
Diffstat (limited to 'pdf')
-rw-r--r-- | pdf/doc.tex | 88 |
1 files changed, 62 insertions, 26 deletions
diff --git a/pdf/doc.tex b/pdf/doc.tex index 042f212..35891b6 100644 --- a/pdf/doc.tex +++ b/pdf/doc.tex @@ -372,7 +372,7 @@ De plus, comme aucune donnée ne peut être supprimée, nous en profitons pour r \chapter{Présentation de DNA-Backup} -Notre proposition : DNA-Backup, ressemble donc plus à un système de sauvegardes qu'à un système de fichiers. +DNA-Backup, notre proposition, ressemble donc plus à un système de sauvegardes qu'à un système de fichiers. Chaque nouvelle version vient s'ajouter à la précédente, car il est impossible de supprimer ou de modifier des données et on applique un \emph{pipeline} de compression sur les données de chaque version afin d'en minimiser la taille. @@ -460,11 +460,8 @@ la capacité du DNA-Drive étant pour le moment bien inférieure à ce qui exist \section{Fonctionnement général} Le système part donc du principe qu'on dispose, sur un support de stockage classique, d'une copie des données stockées en \ac{adn} appelée le \emph{repo} (Figure~\ref{fig:big-picture}). -Cependant, les informations ne sont pas stockées exactement de la même manière. -En effet, le repo profite du fait qu'il se trouve déjà sur un système de fichiers. -Il utilise donc différents fichiers pour stocker ses données, -et contrairement au DNA-Drive qui est plus optimisé pour les écritures que pour les lectures, -le repo doit permettre de rapidement accéder aux données d'un chunk. +Sa raison d'être est d'accélérer la création et la restauration d'une version +en fournissant un accès rapide aux données que contient le DNA-Drive. \begin{figure*}[ht] \centering @@ -477,8 +474,10 @@ le repo doit permettre de rapidement accéder aux données d'un chunk. \draw (5,1) rectangle (7.5,3) node[midway] {Repo}; \draw (10,1) rectangle (12.5,3) node[midway] {DNA-Drive}; -\draw[Arrow] (3,2) -- (5,2) node[midway,below] {Commit}; -\draw[Arrow] (7.5,2) -- (10,2) node[midway,below] {Synthèse}; +\draw[Arrow] (3,2.3) -- (5,2.3) node[midway,above] {Commit}; +\draw[Arrow] (7.5,2.3) -- (10,2.3) node[midway,above] {Export}; +\draw[Arrow] (5,1.7) -- (3,1.7) node[midway,below] {Restore}; +\draw[Arrow] (10,1.7) -- (7.5,1.7) node[midway,below] {Import}; \end{tikzpicture} @@ -486,30 +485,46 @@ le repo doit permettre de rapidement accéder aux données d'un chunk. \label{fig:big-picture} \end{figure*} -Pour ajouter une nouvelle version, on fait un \emph{commit} dans le repo. -Le repo doit être présent lorsque l'on veut faire un commit, -car le pipeline de compression tire parti des données existantes. -La copie stockée en \ac{adn} dans le DNA-Drive n'est donc utilisé que pour restaurer le repo -dans le cas d'une défaillance ou d'une duplication. +Pour créer une nouvelle version ou en restaurer une existante, DNA-Backup n'utilise donc que le repo. +Il est ensuite possible d'exporter les données du repo vers le DNA-Drive, +ou bien de reconstruire le repo en important les données du DNA-Drive, +par exemple dans le cas d'une défaillance ou bien d'une duplication. -\subsection{Fonctionnement du repo} +DNA-Backup stocke les données d'une version d'une manière assez particulière. +Chaque version est en fait un \emph{disque virtuel} contenant les données des fichiers mis bout-à-bout. +Ce disque virtuel ne contient aucune métadonnée, seulement le contenu des fichiers +et c'est sur lui qu'on applique le pipeline de compression. +Il n'est donc pas stocké sous la forme d'un segment continu, mais en tant qu'un ensemble de chunks. +La liste des chunks qui le compose fait partie des métadonnées que DNA-Backup doit enregistrer. +C'est à partir de cette liste et du contenu des chunks que l'on peut recréer le disque virtuel. +Mais le disque virtuel à lui seul ne suffit pas à restaurer une version. +En effet, il ne contient aucune métadonnée, +il est donc impossible de savoir à quel fichier correspond une donnée. +DNA-Backup doit donc également sauvegarder pour chaque version une liste de noms de fichiers, +permettant de retrouver dans son disque virtuel où commence et où s'arrête chaque fichier. -Au tout début du commit, avant l'application du pipeline de compression, -DNA-Backup fait un listage des fichiers du dossier source. -Les données de ces fichiers sont ensuite concaténées en un segment virtuel continu. -De cette manière, si la taille d'un fichier n'est pas aligné sur la taille d'un chunk, -les données du fichier suivant y seront ajoutées, au lieu d'avoir à le combler avec des bits de bourrage. -Les métadonnées (chemin, taille, etc~\textellipsis) ne sont pas ajoutées dans ce segment. -Elles sont stockées à part, car leur petite taille par rapport aux données nous offre lors d'une restauration -la possibilité de rapidement les récupérer. -En effet, les métadonnées nous permettent à elles seule d'obtenir une arborescence de dossiers et de fichiers que l'on peut parcourir. +Pour restaurer une version, il faut donc dans un premier temps +reconstruire en mémoire le disque virtuel à partir de sa liste de chunks, +puis le découper en fichiers à partir de la liste des noms de fichiers. + + +\subsection{Organisation du repo} -Dans le repo, les données sont organisées par version, on a donc à la racine du repo un dossier par version (Figure~\ref{fig:repo-dir-tree}). +Dans le repo, les données sont organisées par version, chacune dans un dossier. Chaque dossier de version contient ses propres informations. +La Figure~\ref{fig:repo-dir-tree} montre un exemple d'arborescence de repo comportant deux versions. + + +\paragraph{Chunks} Les chunks d'une version sont stockés dans un dossier \verb|chunks| chacun dans un fichier séparé et compressé indépendamment des autres. De cette manière, il est très facile d'accéder au contenu d'un chunk précis. +\paragraph{Files} + +\paragraph{Recipe} + + \begin{figure*}[ht] \centering @@ -546,7 +561,11 @@ De cette manière, il est très facile d'accéder au contenu d'un chunk précis. \verb|repo/00000/hashes| & 3923672 & 0.9\% \\ \verb|repo/00000/chunks| & 412263137 & 97.8\% \\ \end{tabular} - \caption{Exemple de répartition des données d'un repo comportant une seule version pour une taille totale de 401 Mio.} + \caption{ + Répartition des données d'un repo comportant une seule version pour une taille totale de 401 Mio. + Ce repo a été obtenu à partir d'un dossier de code source, + il s'agit donc d'un grand nombre de fichiers texte de petite taille, fortement déduplicables et compressibles. + } \label{tab:repo-data-distribution} \end{subtable} @@ -554,6 +573,7 @@ De cette manière, il est très facile d'accéder au contenu d'un chunk précis. \label{fig:repo-organisation} \end{figure*} +\paragraph{Hashes} Pour ne pas avoir à recalculer les signatures (fingerprints et sketches) de tous les chunks du repo lors d'un commit, on stocke ses valeurs dans un fichier \verb|hashes| séparé. Celui-ci ne sera pas synthétisé en \ac{adn}, @@ -571,6 +591,22 @@ car les données qu'il contient peuvent être recalculées à partir du contenu % version précédente. % \end{itemize} +\subsection{Ajouter une version au repo} + +Pour ajouter une nouvelle version, on fait un \emph{commit} dans le repo. +Le repo doit être présent lorsque l'on veut faire un commit, +car le pipeline de compression tire parti des données existantes. + +Au tout début du commit, avant l'application du pipeline de compression, +DNA-Backup fait un listage des fichiers du dossier source. +Les données de ces fichiers sont ensuite concaténées en un segment virtuel continu. +De cette manière, si la taille d'un fichier n'est pas aligné sur la taille d'un chunk, +les données du fichier suivant y seront ajoutées, au lieu d'avoir à le combler avec des bits de bourrage. +Les métadonnées (chemin, taille, etc~\textellipsis) ne sont pas ajoutées dans ce segment. +Elles sont stockées à part, car leur petite taille par rapport aux données nous offre lors d'une restauration +la possibilité de rapidement les récupérer. +En effet, les métadonnées nous permettent à elles seule d'obtenir une arborescence de dossiers et de fichiers que l'on peut parcourir. + \subsection{L'export vers le DNA-Drive} On imagine le \emph{DNA-Drive} comme un segment de \emph{pools} (Figure~\ref{fig:data-layout}) @@ -636,7 +672,7 @@ lire que les \emph{pools} contenant des \emph{chunks} de ce fichier. -\chapter{Fonctionnement détaillé} +\chapter{Détails d'implémentation} % \section{Détails à propos du repo} |