Les snapshots Un snapshot est un fichier qui reste toujours dépendant des autres snapshot. On ne peut pas créer un snapshot et l'oublier. Meme si un snapshot n'est plus utilisé, il doit etre entretenu (protégé). Cela veut dire qu'une liste de snapshot doit etre maintenu. Si jamais drnap est redémaré, il doit connaitre la liste. La solution sera de créer les snapshots dans un répertoire. L'argument qu'on fourni à drsnap n'est pas le nom d'un fichier, mais le nom d'un répertoire. Ce répertoire contient tous les snapshots. -- Il faut une façon simple de préserver la relation entre les snapshots. Le système que nous avons en tete doit supporter les scénarios suivants: Le cas simple. On crée des snapshot préservant une copie et passant au suivant. V1 - V2 - V3 - V4 Par contre, on pourra avoir V1 - V2 Trouvant un problème dans V2, on revient a V1 et on continue a évoluer. On fait alors V3 et on conserve V1 comme référence. On obtient alors V1 - V2 | - V3 -- Les snapshots seront gèrés par deux fichiers. Un fichier data qui ne contiendra que le data sans aucun formattage. Un fichier index permettra de savoir quel tranche existe dans le fichier data (sparse) et aussi permettra de connaitre la génération de la tranche, permettant de savoir si on doit protéger ou pas la tranche. En utilisant des fichiers séparés, on peut injecter le data d'un snapshot directement sur un device et faire un mount, ou un mount loopback. Ca prendra un utilitaire pour relire un snapshot intégralement sans trous. -- Comment identifier le snapshot qui est la référence pour un client. Comment se rappeler ce que nous considérons maintenant comme la version courante. Un lien symbolique pointant vers le bon fichier snapshot ? -- Un snapshot read-write pourrait etre isolé de l'original en copiant des tranches de temps en temps. Pas super utile puisque le snapshot est gèrer sur l'archiveur, qui ne voit que peut d'activité. -- Une solution pour identifier les fichiers serait base-A base-A-A base-A-B base-A-B-A On avait un fichier base-A. On a crée un snapshot. Le snapshot laisse derrière lui base-A et on continue a mettre à jour base-A-A. On décide ensuite de faire évoluer le snapshot base-A, on fait alors un autre snapshot relatif à base-A. Comme base-A-A existe déjà, on fait base-A-B. Cela veut dire que base-A-B provient de base-A, mais est indépendant de base-A-A. On peut alors faire un autre snapshot base-A-B-A laissant derrière base-A-B. Si on veut préserver base-A-A, base-A ne peut pas changer ou bien, on doit protéger base-A-A en copiant les tranches de base-A avant de les modifier. Une solution peut-etre plus efficace serait de toujours geler la base lorsqu'on fait un snapshot. Donc on a base-A ensuite on fait un snapshot. base-A ne bouge plus et on fait évoluer base-A-A maintenant, on souhaite modifier base-A. On a pas le droit. On fait immédiatement base-A-B base-A-B est indépendant de base-A-A. base-A ne bouge jamais. On ne peut modifier que les bouts de branche. Cette notion simplifie le code. Lorsqu'on modifie une vue, il n'y a pas d'impact majeur. Contrairement à LVM, on a pas besoin de protéger tous les snapshot quand on modifie la base (parce qu'on ne modifie jamais la base). Cette stratégie simplifie la gestion des générations. Il n'y a qu'un seul cas a gèrer -On veut modifier une tranche et on a pas le data. On va chercher une copie dans le parent, ou le parent du parent, etc... On ne modifie jamais le parent. Contrairement à LVM, la version prod pourrait échouer (manquer d'espace disque). Il faudra une solution pour éliminer des snapshot et simplifier alors l'arborescence. --- On demand snapshot. On pourrait permettre d'etablir une connexion sur un snapshot non terminal et créé un snapshot lors de la premiere écriture. --- Pour revenir en arriere, drsync pourrait se servir du superblock raid1 et trouver a quel version le volume appartient. On fournirait a drsync uniquement la destination, il trouverait la source tout seul. BUGS: snap doit calculer la lettre lorsqu'on fait une nouvelle branche. On doit verifier que la branche existe.