La de-duplication pourrait faire quelque chose ici. Je ne sais pas comment elle s'en sort quand le contenu d'un bloc est sensiblement le même, mais un peu décalé.
Effectivement c'est la déduplication qui peut aider (si elle est activée). Après je crois que fedora a un système qui permet de mettre à jour par application de diff. Ça doit simplifier les choses.
Donc je suis d'accord avec l'argument du snapshot instantané et qui ne prend que la place nécessaire, mais je pense que cette place nécessaire peut être très importante.
Il n'y a pas de miracle. Cet espace très important c'est la différence entre les 2 états de ton système. On peut envisager des compressions, des déduplication plus ou moins fine, c'est un curseur à positionner.
Supprimer un snapshot va au moins lancer une cascade d'opération pour mettre à jour les meta données de ton file système. Toutes les données devenues orphelines après cette suppression vont devoir etre "collectée" et cela peut representer un gros travail.
Non, il ne touche pas aux fichiers. Il modifie ces propres métadonnées pour supprimer la référence du snapshot. L'espace occupé ne sera réutilisé au fur et à mesure que tu en a besoin. C'est sans commune mesure avec un parcourt arborescent du système de fichiers.
Je ne sais pas pourquoi là tu parle de cascade d'opérations et en dessous tu parle d'un seul.
La grosse difference entre les deux? La suppression d'un snapshot se fera en un appel système et le reste c'est le file système qui fait. La suppression des 200 Gio risque de générer de nombreux appels pour chaque fichiers à supprimer.
C'est exactement mon point.
Cependant, je vois un peu cela comme une analyse amortie. Dans le modèle snapshot + update, tu va supprimer et créer de nouveaux fichiers puis plus tard tu vas supprimer le snapshot. Dans le modèle "nix", tu vas seulement créer de nouveaux fichiers (donc pas d'appel système pour les suppressions) et plus tard, lors de la "purge", tu vas supprimer tes fichiers inutiles. Les deux sembles équivalents, mais pas au même instant.
Tu remplace la suppression par des créations de liens ce qui a le même coût.
En fait, nix fait la même chose que les snapshot sauf qu'avec la connaissance interne du système de fichier c'est bien plus rapide à manipuler, mais ça demande nécéssite un redémarrage pour faire le changement. Après nix a d'autres intérêts.
[^] # Re: à chacun sa vision de la simplicité
Posté par barmic 🦦 . En réponse au journal Les rollbacks avec NixOS, ou comment casser son système. Évalué à 2.
Effectivement c'est la déduplication qui peut aider (si elle est activée). Après je crois que fedora a un système qui permet de mettre à jour par application de diff. Ça doit simplifier les choses.
Il n'y a pas de miracle. Cet espace très important c'est la différence entre les 2 états de ton système. On peut envisager des compressions, des déduplication plus ou moins fine, c'est un curseur à positionner.
Non, il ne touche pas aux fichiers. Il modifie ces propres métadonnées pour supprimer la référence du snapshot. L'espace occupé ne sera réutilisé au fur et à mesure que tu en a besoin. C'est sans commune mesure avec un parcourt arborescent du système de fichiers.
Je ne sais pas pourquoi là tu parle de cascade d'opérations et en dessous tu parle d'un seul.
C'est exactement mon point.
Tu remplace la suppression par des créations de liens ce qui a le même coût.
En fait, nix fait la même chose que les snapshot sauf qu'avec la connaissance interne du système de fichier c'est bien plus rapide à manipuler, mais ça demande nécéssite un redémarrage pour faire le changement. Après nix a d'autres intérêts.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll