URL: https://linuxfr.org/users/steckdenis/journaux/btrfs-id%C3%A9es-dapplication-des-snapshots-inscriptibles Title: Btrfs : idées d'application des snapshots inscriptibles Authors: steckdenis Date: 2009年09月29日T19:58:50+02:00 Tags: btrfs Score: 22 Bonjour, À qui n'est-ce pas arrivé, quand on présente des fonctionnalités avancées aussi abstraites que des «snapshots inscriptibles dans Btrfs», de se demande à qui ça pourrait servir ? En effet, quand on entend ce genre de choses, on a tendance à dire que ça ne servira que dans des fermes de serveurs virtualisés, ou je ne sais quoi. Petit rappel : [Btrfs](http://fr.wikipedia.org/wiki/Btrfs) est un nouveau système de fichier pour le noyau [Linux](http://fr.wikipedia.org/wiki/Linux), encore en développement. Outre sa manière bien spéciale de stocker les fichiers sur le disque (sous forme de [B-tree](http://fr.wikipedia.org/wiki/Arbre_B)), il permet également tout un tas de fonctionnalités toutes plus farfelues les unes que les autres, comme le redimensionnement à chaud, la défragmentation à chaud, les snapshots, etc. Un snapshot est une image de l'état dans lequel se trouve le système de fichier à un instant T. On peut le voir comme une révision dans les [systèmes de contrôle de révisions](http://fr.wikipedia.org/wiki/VCS). Par exemple, imaginez que vous avez un certain système de fichiers, et que vous allez y apporter des modifications. Pour ne pas perdre de données, vous allez créer un snapshot contenant l'état actuel, et le supprimer si tout s'est bien passé. C'est justement ce fonctionnement qui m'a donné une idée d'application dans la vie de tous les jours de ces snapshots inscriptibles : Madame Michu découvre la console. Elle n'est pas du tout à l'aise, et suit un tutoriel trouvé quelque-part. Elle n'a vraiment pas confiance. Pour travailler en sécurité, elle commence par taper la commande "snapshot", par exemple. Cette commande, un script shell, crée un nouveau snapshot (éventuellement nommé suivant la date et l'heure, et enregistré quelque-part). Ensuite, elle fait ses modifications. Une fois les modifications terminées, soit tout a bien marché, et elle tape "apply", soit quelque-chose a mal tourné, et elle tape "revert". Madame Michu est donc contente, car elle peut faire ce qu'elle veut, y compris un "rm -rf /" (bon, peut-être pas, /usr/bin/revert doit exister, sauf si c'est une commande interne de son shell), si quelque-chose tourne mal, un simple revert lui remettra son système de fichier exactement comme il était. Un autre cas : Monsieur Michu (qui a entre temps pu avoir accès à l'ordinateur) décide d'installer un paquet. Son gestionnaire de paquets, en toute transparence, lui crée un snapshot. Ensuite, il installe les paquets. Si quelque-chose tourne mal, et que le système a été touché, un revert suffira à le remettre d'aplomb. Si tout va bien, on continue. Autre cas, la fameuse «restauration système» de Windows. Monsieur Michu va installer une application en la compilation lui-même, pour la première fois. Il est un peu plus frileux que Madame Michu, et donc suit scrupuleusement la documentation, qui ne précise pas la suite «snapshot, revert». Par contre, prudent, il va dans la GUI «Restauration du système», et crée un nouveau point de restauration. Il peut alors s'amuser comme il veut, modifier tout son système, puis finalement restaurer son point si quelque-chose a mal tourné. Remarquez que l'application de restauration étant en RAM, un "rm -rf /" peut être contré ! Encore un autre cas ! Madame Michu, qui s'est battue avec son mari pour récupérer l'ordinateur (avant qu'il ne soit totalement foutu), décide de modifier un document OpenDocument pour son travail. Elle sait qu'elle va y apporter de grosses modifications, et n'a pas envie d'en créer des copies. Clic droit»Propriétés»Historique»Créer un point de sauvegarde, et le voilà placé dans son "petit snapshot" (note: il faut voir si c'est possible de versionner tout un fichier et pas seulement un disque entier, pour permettre de restaurer les fichiers un à un). Elle modifie ensuite son fichier, puis l'enregistre. Elle peut faire ça plusieurs fois, l'onglet «Historique» lui affiche toutes les versions, c'est parfait. Si un jour elle fait une bêtise, un simple _revert_ lui rendra le sourire. Voilà, ceci est la liste de tout ce qu'on peut imaginer avec ce magnifique Btrfs. Inutile maintenant de vous dire que ce sera le système de fichiers par défaut de Logram, une fois sorti (mais à mon avis, Logram sortira après Btrfs). Petits points intéressants : * Btrfs est censé capturer des snapshots instantanément * Dans mes exemples, les snapshots ne doivent pas être inscriptibles. On pourrait tourner ça de la sorte : créer le snapshot » passer dedans » écrire dedans » le garder ou le jeter * Il faut voir s'il est facile de passer un snapshot comme étant la «racine du système de fichier», c'est à dire ce que fait la commande «apply». Btrfs étant en développement, on pourrait le demander à ses développeurs Voilà, j'attends vos avis. Avez-vous d'autres idées ? Trouvez-vous ceci intéressant ? Est-ce possible techniquement (maintenant ou plus tard) ?

AltStyle によって変換されたページ (->オリジナル) /