Merci pour cette belle découverte et le travail derrière !
merci <3
Quelle volumétrie peut-t-on adresser avec planka/ptar ?
En terme de volumétrie, la limite théorique pour plakar et ptar est aux alentours de 18EB, même si je pense que d'autres problèmes se poseront avant, il faut que quelqu'un teste :-)
En pratique, on teste jusqu'à du multi-TB, au dessus ça devient compliqué pour nous, mais considérant notre architecture logicielle, il n'y théoriquement rien qui permet de monter beaucoup plus haut..
Comment se comporte le format .ptar à l'ajout de fichier ? Le fichier est massivement modifié ? (Je pense notamment à de la synchro via syncthing par exemple)
Le format .ptar ne supporte pas l'ajout de fichier, il est immutable une fois crée: il s'agit en réalité d'un repo qui a été sérialisé et figé en lecture seule, toute modification produit des erreurs de sommes de contrôle.
Aujourd'hui, l'ajout d'un fichier revient à recréer un nouveau .ptar en utilisant en source un ancien .ptar en mode synchro et le nouveau fichier, avec du coup une réécriture complète. Techniquement, il est possible d'écrire une version un peu différente de l'outil qui sache faire cet ajout de manière un peu plus efficace, mais ce n'est pas le cas présentement.
Le nombre de snapshots est limité ou peut poser problème au delà d'un certain usage ?
Il n'est pas limité et j'ai monté le test à plusieurs dizaines de milliers en ce qui me concerne. Cela n'a aucune incidence sur la création de backup, la restoration et/ou la manipulation/navigation d'un snapshot en particulier.
Le seul problème est sur des fonctionnalités à la marge type "chercher un fichier dans l'intégralité des snapshots" ou "afficher une timeline de tous les snapshots qui possèdent un répertoire" parce qu'il n'y a pas de secret: il faut les ouvrir et ça sera lent.
Il y a un peu de cache là où c'est possible mais sachant que les repo plakar sont "stateless", il n'y a pas de base de donnée pour s'abstraire d'un serveur et pour limiter les pré-requis sur un nouveau poste, donc on est en environnement assez contraint.
Comment le projet plakar se positionne par rapport à borgbackup ou https://dvc.org/ par exemple ? (le format .ptar semble à première vue un gros avantage à mes yeux pour le partage/transfert et peut-être plus "léger" qu'avoir toute une arborescence à synchroniser)
Pas certain de comprendre la question du positionnement, désolé.
Le format .ptar a pour objectif de remplacer le format "repo" ?
Non, pas du tout, il s'agit vraiment du même format mais sous une forme transportable, les deux ont vocation a vivre en parallèle pour des usages différents, sachant que les améliorations apportés à l'un bénéficient à l'autre :-)
Est-t-il prévu d'intégrer un code correcteur d'erreur ? (je pense notamment à des backups sur clé usb plus ou moins fiables ...) (oui, oui, 3-2-1-0)
Long débat, on n'est pas encore convaincu de l'utilité:
Les ECC ne permettent de corriger qu'un taux marginal d'erreur pour un overhead qui est significatif... si l'on considère qu'un second dépôt offre une correction totale.
On s'est réservé la marge nécessaire pour pouvoir ajouter si on change d'avis, pour l'instant la conviction est que c'est usine à gaz pour pas grand chose: le seul projet à le supporter à notre connaissance est kopia, en expérimental depuis très longtemps, et ça a plus l'air d'être fait pour dire "on le fait" que par bénéfice réel.
J'aime beaucoup l'ui intégrée également ! (ce que borg ne propose pas de mémoire)
[^] # Re: Je trouve ce projet super intéressant !
Posté par Gilles Chehade (site web personnel) . En réponse au lien .ptar: archive format for a single self-contained, portable, immutable, deduplicated, encrypted file. Évalué à 4.
merci <3
En terme de volumétrie, la limite théorique pour plakar et ptar est aux alentours de 18EB, même si je pense que d'autres problèmes se poseront avant, il faut que quelqu'un teste :-)
En pratique, on teste jusqu'à du multi-TB, au dessus ça devient compliqué pour nous, mais considérant notre architecture logicielle, il n'y théoriquement rien qui permet de monter beaucoup plus haut..
Le format .ptar ne supporte pas l'ajout de fichier, il est immutable une fois crée: il s'agit en réalité d'un repo qui a été sérialisé et figé en lecture seule, toute modification produit des erreurs de sommes de contrôle.
Aujourd'hui, l'ajout d'un fichier revient à recréer un nouveau .ptar en utilisant en source un ancien .ptar en mode synchro et le nouveau fichier, avec du coup une réécriture complète. Techniquement, il est possible d'écrire une version un peu différente de l'outil qui sache faire cet ajout de manière un peu plus efficace, mais ce n'est pas le cas présentement.
Il n'est pas limité et j'ai monté le test à plusieurs dizaines de milliers en ce qui me concerne. Cela n'a aucune incidence sur la création de backup, la restoration et/ou la manipulation/navigation d'un snapshot en particulier.
Le seul problème est sur des fonctionnalités à la marge type "chercher un fichier dans l'intégralité des snapshots" ou "afficher une timeline de tous les snapshots qui possèdent un répertoire" parce qu'il n'y a pas de secret: il faut les ouvrir et ça sera lent.
Il y a un peu de cache là où c'est possible mais sachant que les repo plakar sont "stateless", il n'y a pas de base de donnée pour s'abstraire d'un serveur et pour limiter les pré-requis sur un nouveau poste, donc on est en environnement assez contraint.
Pas certain de comprendre la question du positionnement, désolé.
Non, pas du tout, il s'agit vraiment du même format mais sous une forme transportable, les deux ont vocation a vivre en parallèle pour des usages différents, sachant que les améliorations apportés à l'un bénéficient à l'autre :-)
Long débat, on n'est pas encore convaincu de l'utilité:
Les ECC ne permettent de corriger qu'un taux marginal d'erreur pour un overhead qui est significatif... si l'on considère qu'un second dépôt offre une correction totale.
On s'est réservé la marge nécessaire pour pouvoir ajouter si on change d'avis, pour l'instant la conviction est que c'est usine à gaz pour pas grand chose: le seul projet à le supporter à notre connaissance est kopia, en expérimental depuis très longtemps, et ça a plus l'air d'être fait pour dire "on le fait" que par bénéfice réel.
Merci <3