Bon, comme tu l'as vu toi même, effectivement, l'idée c'est de mmaper un fichier (quitte à le réagrandir avec ftruncate), et de créer directement les structures de données dans l'espace mémoire mappé du fichier (en C++ avec le placement new, je ne sais pas en Rust comment faire). Ce qui évite toute copie de données (vu que tu travailles directement dans le fichier) mais ça nécessite de ne pas avoir de pointeur mais des index dans d'autres conteneur (ce qui n'est pas plus mal en fait, ça rend le code beaucoup plus stable).
Du coup, lors d'une itération de ton archive, tu peux directement "pointer" sur les données précédentes, que tu n'as même pas besoin de lire physiquement. Ce n'est pas le cas en mode "read" où tu dois charger tout l'index en mémoire pour le modifier.
Évidemment, le prix à payer, c'est la portabilité, c'est à dire que sur les machines big endian (est-ce que ça existe encore ces choses ?) ne peuvent pas lire une archive LE, car il faut swapper les entiers avant de les utiliser. Mais pour une solution de backup, vu que tu restaures l'archive sur la même machine que tu sauvegardes, l'endianness ne change pas, ce n'est pas un problème.
Je fais effectivement un diff inversé (pas sur les données, seulement sur l'index), comme git pack car à chaque fois que tu lances un backup, c'est beaucoup plus rapide que d'avoir à reconstituer l'index à partir de la genèse. Donc, oui, je modifie l'index en fin de backup en stockant la version la plus récente comme une nouvelle itération, comprendre la hiérarchie complète des fichiers, à la fin de l'index avec un lien vers l'index de la version précédente. Puis dans le header de l'archive, je change le pointeur du catalogue vers la dernière version.
J'ai également une fonction de purge qui élimine les révisions les plus anciennes (probablement la fonction la plus dure à coder pour un système de backup qui déduplique).
La documentation du format est dans le header "Frost.hpp" vers la ligne 268.
[^] # Re: Ressemble beaucoup à Frost
Posté par xryl669 . En réponse à la dépêche Jubako et Arx, un conteneur universel et son format d’archive. Évalué à 5.
Bon, comme tu l'as vu toi même, effectivement, l'idée c'est de mmaper un fichier (quitte à le réagrandir avec ftruncate), et de créer directement les structures de données dans l'espace mémoire mappé du fichier (en C++ avec le placement new, je ne sais pas en Rust comment faire). Ce qui évite toute copie de données (vu que tu travailles directement dans le fichier) mais ça nécessite de ne pas avoir de pointeur mais des index dans d'autres conteneur (ce qui n'est pas plus mal en fait, ça rend le code beaucoup plus stable).
Du coup, lors d'une itération de ton archive, tu peux directement "pointer" sur les données précédentes, que tu n'as même pas besoin de lire physiquement. Ce n'est pas le cas en mode "read" où tu dois charger tout l'index en mémoire pour le modifier.
Évidemment, le prix à payer, c'est la portabilité, c'est à dire que sur les machines big endian (est-ce que ça existe encore ces choses ?) ne peuvent pas lire une archive LE, car il faut swapper les entiers avant de les utiliser. Mais pour une solution de backup, vu que tu restaures l'archive sur la même machine que tu sauvegardes, l'endianness ne change pas, ce n'est pas un problème.
Je fais effectivement un diff inversé (pas sur les données, seulement sur l'index), comme git pack car à chaque fois que tu lances un backup, c'est beaucoup plus rapide que d'avoir à reconstituer l'index à partir de la genèse. Donc, oui, je modifie l'index en fin de backup en stockant la version la plus récente comme une nouvelle itération, comprendre la hiérarchie complète des fichiers, à la fin de l'index avec un lien vers l'index de la version précédente. Puis dans le header de l'archive, je change le pointeur du catalogue vers la dernière version.
J'ai également une fonction de purge qui élimine les révisions les plus anciennes (probablement la fonction la plus dure à coder pour un système de backup qui déduplique).
La documentation du format est dans le header "Frost.hpp" vers la ligne 268.