Avant de discuter je voulais juste repréciser un truc. Je suis rentré dans le débat parce que je vois pleins d'avantages à nix versus le snapshot avant upgrade. J'ai aussi fais des suppositions sur comment était fait ces snapshot. Je pensais que l'utilisateur faisait un snapshot avant toute intervention sur son système (i.e. installation de paquet, changement de config, ...) et concevrait ses snapshot pendant une longue période, parce que c'est ce que j'aurais fais. J'ai aussi imaginé que l'utilisateur intégrait ces snapshot dans sa procédure de backup.
Bref, j'ai mal compris, donc pas mal des points de mon argumentation ne sont pas valable dans ce contexte. Je veux bien admettre que nous ne sommes pas d'accord sur la stratégie de mise à jour.
Maintenant, tu soulèves certains points sur btrfs qui m’intéressent fortement et que j'aimerais discuter.
En gros, je ne suis pas d'accord avec toi ;) Mais ma connaissance de btrfs est limité, donc si je dis une connerie, arrête moi immédiatement.
Je présume que tu parle de snapshot pre-zfs/hammerfs/btrfs. Avec la technique du CoW, c'est instantané et ça ne coûte que la place réellement nécessaire.
Non, je parlais bien de snapshot btrfs.
La place réellement nécessaire lors d'une mise à jour importante c'est généralement égale à tout ce que tu as changé pendant cette mise à jour. Ce qui peut être beaucoup et le CoW ne va pas faire grand chose ici à mon avis.
Si tu met à jour un paquet de la version X à la version Y, ta distribution va commencer par supprimer les fichiers du paquet, puis installer les nouveaux, ainsi:
Le CoW ne va pas faire grand chose ici, car tu supprimes un fichier puis tu en met un nouveau (que tu sors généralement d'une archive que tu viens de décompresser). Il n'y a pas de copie dans ce processus et ce n'est pas une édition d'un fichier que le CoW pourrait traquer en ne changeant que les blocs différents.
Quand bien même, il y a de grande chances que tous les blocs d'un fichier soient différents après la mise à jour.
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é.
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.
Supprimer un snapshot ne coûte rien. Ça ne ralenti pas ton build suivant, ça prend le même temps quelque soit la taille de ton fs ou des données contrairement à une suppression de 200Gio sur disque.
Ici je ne suis pas d'accord. 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.
La suppression des 200Gio par nix va faire sensiblement la même chose.
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.
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.
(Je sais pas pourquoi tu parle de backup quand il est question de snapshot)
Je me sers de snapshot dans ma stratégie de backup du système, d'ou ma confusion.
[^] # Re: à chacun sa vision de la simplicité
Posté par Guillaum (site web personnel) . En réponse au journal Les rollbacks avec NixOS, ou comment casser son système. Évalué à 2.
Avant de discuter je voulais juste repréciser un truc. Je suis rentré dans le débat parce que je vois pleins d'avantages à nix versus le snapshot avant upgrade. J'ai aussi fais des suppositions sur comment était fait ces snapshot. Je pensais que l'utilisateur faisait un snapshot avant toute intervention sur son système (i.e. installation de paquet, changement de config, ...) et concevrait ses snapshot pendant une longue période, parce que c'est ce que j'aurais fais. J'ai aussi imaginé que l'utilisateur intégrait ces snapshot dans sa procédure de backup.
Bref, j'ai mal compris, donc pas mal des points de mon argumentation ne sont pas valable dans ce contexte. Je veux bien admettre que nous ne sommes pas d'accord sur la stratégie de mise à jour.
Maintenant, tu soulèves certains points sur btrfs qui m’intéressent fortement et que j'aimerais discuter.
En gros, je ne suis pas d'accord avec toi ;) Mais ma connaissance de btrfs est limité, donc si je dis une connerie, arrête moi immédiatement.
Non, je parlais bien de snapshot btrfs.
La place réellement nécessaire lors d'une mise à jour importante c'est généralement égale à tout ce que tu as changé pendant cette mise à jour. Ce qui peut être beaucoup et le CoW ne va pas faire grand chose ici à mon avis.
Si tu met à jour un paquet de la version X à la version Y, ta distribution va commencer par supprimer les fichiers du paquet, puis installer les nouveaux, ainsi:
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.
Ici je ne suis pas d'accord. 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.
La suppression des 200Gio par nix va faire sensiblement la même chose.
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.
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.
Je me sers de snapshot dans ma stratégie de backup du système, d'ou ma confusion.