Journal Btrfs : idées d'application des snapshots inscriptibles

Posté par  (site web personnel) .
Étiquettes :
22
29
sept.
2009
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 est un nouveau système de fichier pour le noyau Linux, encore en développement. Outre sa manière bien spéciale de stocker les fichiers sur le disque (sous forme de B-tree), 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. 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) ?
  • # Au niveau de l'existant

    Posté par  (site web personnel) . Évalué à 6.

    Tu peux regarder ce qui à été fait pour l'intégration de ZFS dans nautilus : http://blogs.sun.com/erwann/entry/zfs_on_the_desktop_zfs
    • [^] # Re: Au niveau de l'existant

      Posté par  (site web personnel) . Évalué à 5.

      Pas mal du tout.

      Mais ce dont moi je parle, c'est aussi une intégration avec KDE. Mais sinon, vraiment pas mal. J'aime bien l'interface (qui occupe un peu trop de place à l'écran à mon gout).

      Je sens que ça va finir par une libatomicalfilesystem dans Logram, pour pouvoir utiliser ce genre de fonctionnalités avec Btrfs, ZFS et autres systèmes de fichiers le supportant.

      Merci beaucoup pour le lien, et mes félicitations aux développeurs.
    • [^] # Re: Au niveau de l'existant

      Posté par  . Évalué à 9.

      C'est classe !!

      Mais ca montre un point absolument alarmant actuellement : l'integration quasi nulle des systemes de fichiers dans les desktop managers.
      Quand on voit que meme les ACL ne sont pas gerees par Gnome (et KDE ?), quand vont etre integrees les fonctionnalites hyper avancees et nombreuses de btrfs ???

      A quoi ca sert d'avoir 25 FS a disposition si y'en a pas un seul (meme ext3 !!) qui n'est supporte un minimum par les DM ?
      • [^] # Re: Au niveau de l'existant

        Posté par  . Évalué à 10.

        Quand on voit que meme les ACL ne sont pas gerees par Gnome

        Installe le logiciel Eiciel, et tu pourras modifier tes ACLs avec Nautilus, dans les propriétés des fichiers. Hé oué, GNOME n'est pas si pourri, à condition d'utiliser les bons logiciels.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Au niveau de l'existant

        Posté par  . Évalué à 4.

        KDE gère les ACL depuis pas mal d'années.
        Sinon une difficulté pour les environnements, c'est qu'ils ne tournent pas que sous Linux mais aussi sur les systèmes BSD par exemple. Donc faut faire des abstractions, c'est pas forcément évident, ça prend du temps...
        • [^] # Re: Au niveau de l'existant

          Posté par  (site web personnel) . Évalué à 1.

          Les ACL sous Linux, c'est pas du POSIX ?
          Parce qu'a ce moment là, les BSD devraient aussi pouvoir l'implémenter, non?
          • [^] # Re: Au niveau de l'existant

            Posté par  . Évalué à 1.

            Les ACL sont POSIX oui, heureusement.
            Par contre une fonctionnalité comme les snapshots, non.
            Puis KDE tourne sur autre chose que les UNIX...
      • [^] # Re: Au niveau de l'existant

        Posté par  . Évalué à -1.

        Quand on voit que meme les ACL ne sont pas gerees par Gnome (et KDE ?)

        ça doit être parce que ça sert à rien. Franchement, les ACL ... qui a *vraiment* envie de passer du temps à définir des droits d'accès super fins ?
        Du temps ou j'utilisais Windows en réseau (c'était en école d'ingé y'a quelques années), c'était d'un pénible ... (en même temps, avec une GUI, c'est un peu couru d'avance)

        sinon, ça doit aussi être parce que seuls quelques FSs gèrent des ACLs, et en plus, ils gèrent pas tous les même ...
        • [^] # Re: Au niveau de l'existant

          Posté par  . Évalué à 9.

          Les ACLs ne servent a rien... on aura vraiment tout entendu !

          Qui a envie ? C'est pas qui a envie, c'est qui a besoin.

          Tu fais comment sous Unix pour donner des droits a 3 ou 4 utilisateurs differents sans creer un groupe ? Ah ben ouais, tu peux pas, et donc sans etre root tu es dans la merde parce que tu peux pas creer de groupe sans etre root (tu peux sudo groupadd mais ca serait une faille enorme car un user standard pourrait forcer un groupe avec le meme GID qu'un groupe systeme...)
          • [^] # Re: Au niveau de l'existant

            Posté par  . Évalué à 2.

            sans compter qu'on peut avoir envie de rajouter un utilisateur sur un fichier précis sans avoir à
            -> le rajouter à un groupe (qui peut avoir à d'autres dossiers/fichiers)
            -> modifier le groupe du fichier (ce qui peut bloquer d'autres utilisateurs)
            • [^] # Re: Au niveau de l'existant

              Posté par  . Évalué à 4.

              oui, je vois ce qu'on peut faire avec les ACLs. J'ai juste un peu de mal à imaginer des cas pratiques ou vraiment c'est super bien de faire des ACLs fins.
              Dans un contexte professionel, il me semble que des groupes pré définis par l'admin sys devrait répondre au besoin. Pour les données professionnelles, la rétention d'information n'est pas vraiment indiquée, et pour les données personnelles de l'employé, des droits limités à l'utilisateur permettent de garantir leur confidentialité.
              Reste le cas des données personnelles à partager avec seulement quelques collègues mais est-ce vraiment le rôle d'un service d'infrastructure de se préoccuper de ça ?

              En fait, dire que les ACLs fins permettent à l'utilisateur de gérer finement les droits sur ces fichiers, ça ne répond pas vraiment à la question. Au delà de l'utilité immédiate (donner des droits sans créer de groupes), ça s'inscrit dans quel contexte, dans quelle perspective. Bref : ça sert à quoi ?
              • [^] # Re: Au niveau de l'existant

                Posté par  (site web personnel) . Évalué à 4.

                Un exemple d'utilisation simple des ACLs. Tu as une équipe qui fait un site web (donc plusieurs personnes) et tu a www-data qui est un groupe (car tu as éventuellement d'autres processus (un antivirus) qui doivent accéder aux sites en tant que www-data).
                Tu as donc besoin de de deux groupes, donc les ACLs. Tu pourrais mettre les droits "etienne:webdev 0775", mais le problème c'est que tu veux que ww-data puisse écrire dans certain répertoire, donc tu va faire un "etienne:www-data 0770" et mettre une ACI qui va donner à "webdev" les droits rwx.

                C'est une utilisation que j'ai et je crois que ça répond à ta question.

                "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

              • [^] # Re: Au niveau de l'existant

                Posté par  (site web personnel) . Évalué à 3.

                Y a aussi l'exemple des clefs USB : https://linuxfr.org//~Elessar/28582.html
                • [^] # Re: Au niveau de l'existant

                  Posté par  (site web personnel, Mastodon) . Évalué à 1.

                  Merci pour le lien du journal, j'ai dû passer à travers cet été...et je me suis toujours posé la question de comment faire justement !!
                  • [^] # Re: Au niveau de l'existant

                    Posté par  (site web personnel) . Évalué à 3.

                    Oui, mais le seul souci, ça reste windows qui ne gère pas les périphériques de masse formatés avec autre chose que fat ou ntfs. :(

                    Sinon UDF + ACL aurait été le candidat idéal voir https://linuxfr.org//~alenvers/28585.html
                    • [^] # Re: Au niveau de l'existant

                      Posté par  . Évalué à 1.

                      Ouais, dommage que tu ne lises pas les commentaires des articles que tu pointes...

                      https://linuxfr.org//comments/1052497.html#1052497

                      Alors, la règle c'est d'avoir des secteurs de taille égale aux blocs du périphérique sous-jacent. Donc 512 sur la plupart des clefs USB.

                      C'était donc :
                      - un truc à ne pas oublier : demander à mkudffs de créer un SF avec secteurs de la bonne taille ;
                      - un bogue du noyau Linux <= 2.6.26, qui montait systématiquement avec taille de secteurs de 2048, sauf option contraire explicite.


                      Windows supportait correctement UDF sur peripheriques de masse avant Linux
                      • [^] # Re: Au niveau de l'existant

                        Posté par  (site web personnel) . Évalué à 3.

                        Je les ai lu les commentaires figure toi, et j'y ai appris que ce n'est qu'à partir de windows vista que ça fonctionne. De tes propres mots on y lit aussi que la politique de microsoft c'est de ne pas ajouter de fonctionnalités dans les services pack, sauf le sp2 de Xp.

                        Donc, je vois mal microsoft sortir un patch de support d'UDF pour Xp. Or, le but c'est quand même d'avoir un truc utilisable partout, autre que fat et ntfs. Je ne connais pas les stats, mais Xp représente encore certainement une sacré partie du parc, donc UDF.

                        Bon c'est bien que ce soit géré dans les nouvelles versions, mais quand on croise encore des postes équipés de win98 par ci par là, je me dit qu'UDF comme solution qu'on est sûr de pouvoir utiliser partout, c'est pas pour demain.
                        • [^] # Re: Au niveau de l'existant

                          Posté par  . Évalué à 1.

                          Donc, je vois mal microsoft sortir un patch de support d'UDF pour Xp. Or, le but c'est quand même d'avoir un truc utilisable partout, autre que fat et ntfs. Je ne connais pas les stats, mais Xp représente encore certainement une sacré partie du parc, donc UDF.

                          Super, et pour les Linux n'ayant pas le kernel 2.6.26 ou plus, tu fais quoi ?
                          Parce que bon, XP c'etait les kernel 2.4 hein, et il n'y a plus aucune distrib qui supporte ca quasiment...

                          Bon c'est bien que ce soit géré dans les nouvelles versions, mais quand on croise encore des postes équipés de win98 par ci par là, je me dit qu'UDF comme solution qu'on est sûr de pouvoir utiliser partout, c'est pas pour demain.

                          Tout a fait, ca ne veut pas dire que la faute en revient a MS pour autant.
                          • [^] # Re: Au niveau de l'existant

                            Posté par  . Évalué à 5.

                            Super, et pour les Linux n'ayant pas le kernel 2.6.26 ou plus, tu fais quoi ?

                            Tu upgrades? Ca coute pas cher et de plus le matos anciens est toujours supportes. Deux petits details qui ne sont plus vrai avec les systemes d'exploitation de Microsoft.
                            • [^] # Re: Au niveau de l'existant

                              Posté par  . Évalué à 0.

                              Et sous Windows tu installes un driver UDF non-MS, c'est bcp plus simple qu'upgrader sa distrib.
                              • [^] # Re: Au niveau de l'existant

                                Posté par  . Évalué à 2.

                                Pilote basé, si c'est bien celui que j'ai trouvé en faisant ma recherche, sur le pilote UDF FUSE pour linux, que l'on peut installer sans mettre à jour sa distribution.
                          • [^] # Re: Au niveau de l'existant

                            Posté par  (site web personnel) . Évalué à 3.

                            Comme dit ci-dessus, entre faire une upgrade via le gestionnaire de paquet et aller dans un magasin acheter un nouvelle OS et se farcir toute la réinstallation y une sacré différence, qui fait que la majorité de la première population va migrer alors que la seconde changera d'OS en changeant de machine.

                            Pour ce qui est de la faute de microsoft, si ils pétaient pas les burnes avec des brevets logiciels, ntfs me conviendrais tout aussi bien qu'UDF.
                            • [^] # Re: Au niveau de l'existant

                              Posté par  . Évalué à 1.

                              Tu t'es jamais dit que tu pouvais installer un driver pour ajouter le support plutot que devoir upgrader ton OS ?
                              • [^] # Re: Au niveau de l'existant

                                Posté par  (site web personnel) . Évalué à 3.

                                Ça ne répond pas aux contraintes qui nous intéresse, le but est de se balader avec sa clef USB, de la brancher sur un poste, quelqu'en soit l'OS, et hop, c'est partie.

                                Autre contrainte éventuel, pas de limitation trop contraignante au niveau de la taille des fichiers, adieu fat.

                                Enfin le but ici est de trouver un FS exempt de toute menace jurdique, donc adieu NTFS.

                                Au final, aujourd'hui on a rien qui répond à toutes ces contraintes.
                                • [^] # Re: Au niveau de l'existant

                                  Posté par  . Évalué à 0.

                                  Et quand tu te balades avec ta clef USB et tu tombes sur un Linux avec un kernel < 2.6.26 tu fais quoi ? Meme probleme.

                                  Bref, inutile de pointer le doigt sur MS, parce que Linux ne resoud pas le probleme de son cote non plus, dans les 2 cas il faut une update pour la majorite des machines, que ce soit un driver ajoute ou un kernel plus frais.
                                  • [^] # Re: Au niveau de l'existant

                                    Posté par  (site web personnel) . Évalué à 4.

                                    Le noyau 2.6.26 est le noyau de Debian stable. Debian stable est réputée pour évoluer lentement, très lentement, donc les distributions qui ont un noyau plus ancien que le 2.6.26 c'est pas très courant.

                                    "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                                    • [^] # Re: Au niveau de l'existant

                                      Posté par  . Évalué à 2.

                                      Et encore ils l'ont mis à jour.

                                      Mais il y a des serveur qui mettent pas à jour leur noyau, donc tu ne va pas pouvoir brancher ta clef sur certains serveur ça s'est une grosse contrainte...

                                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                      • [^] # Re: Au niveau de l'existant

                                        Posté par  . Évalué à 2.

                                        donc tu ne va pas pouvoir brancher ta clef sur certains serveur ça s'est une grosse contrainte...
                                        Euh brancher une clée usb sur un serveur... y'a que moi que ça fait tiquer ?
                                        • [^] # Re: Au niveau de l'existant

                                          Posté par  . Évalué à 2.

                                          C'était ironique… (j'aime pas les smileys)

                                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                • [^] # Re: Au niveau de l'existant

                                  Posté par  (Mastodon) . Évalué à 1.

                                  Enfin le but ici est de trouver un FS exempt de toute menace jurdique, donc adieu NTFS.

                                  Au final, aujourd'hui on a rien qui répond à toutes ces contraintes.


                                  Faut arrêter aussi avec la mauvaise foi.

                                  Les brevets ne s'appliquant pas par chez nous, je ne vois pas pas ce que tu en as à foutre. Si ça te démange tant que ça, arrête de partager tes fichiers avec des gens utilisant un OS sale.
                                  • [^] # Re: Au niveau de l'existant

                                    Posté par  (site web personnel) . Évalué à 4.

                                    J'en ai a foutre que ça à un impact sur des entreprises européennes, comme le démontre le cas tomtom, et donc sur l'économie européenne, et donc sur moi.
                                    • [^] # Re: Au niveau de l'existant

                                      Posté par  (Mastodon) . Évalué à 2.

                                      Je suis d'accord sur le fait que les brevets sont sans interêts et contre productif, mais personne n'a forcé tomtom à utiliser un fs microsoft dans leurs gps. Ils pouvaient très bien utiliser un autre fs ou payer une licence.

                                      Le méchant dans cette affaire, c'est la loi américaine et leur office des brevets, pas microsoft.

                                      Reste que pour ton usage personnel, tu n'en as juste rien à battre et microsoft n'a aucun devoir de fournir un support d'autres filesystems.
                                  • [^] # Re: Au niveau de l'existant

                                    Posté par  . Évalué à 2.

                                    Les brevets ne s'appliquant pas par chez nous, je ne vois pas pas ce que tu en as à foutre.
                                    Tomtom, qui n'est pas une boite américaine, a eux quelques problèmes avec ces brevets...
                                    "tant que c'est bon pour moi, les autres ils ont qu'a aller se faire foutre" , c'est ce que tu essaie de nous dire ?
                                    • [^] # Re: Au niveau de l'existant

                                      Posté par  (Mastodon) . Évalué à 2.

                                      D'une part TomTom dépose aussi des brevets, donc cautionnent ce système : je ne vois donc pas quelle pitiée je pourrai avoir envers eux.

                                      D'autre part, c'est hors sujet : on parle du choix d'un FS pour un utilisateur windowsphile. Si microsoft ne veut pas fournir le support pour ext3 ou autre fs utilisé sous linux, c'est leur droit et ça les regarde. Si les fat et ntfs leur suffisent, tant mieux pour eux. Si ça te dérange, tant pis pour ta gueule, t'as qu'à pas vouloir pénétrer des windows avec ton stick usb espèce de pervers.
          • [^] # Re: Au niveau de l'existant

            Posté par  . Évalué à 4.

            je savais bien que la formulation était un peu trollesque.

            ok, ça servirait moins à rien si c'était plus utilisable. Aujourd'hui (mon avis personnel que je partage), le niveau de complexité côté utilisateur pour la gestion fine des ACLs par rapport à l'intérêt que ça a n'est pas rentable.
            c'est vrai que ça fait longtemps que je ne me suis pas penché sur le sujet (pas assez parano ? ;) du coup, ça a peut-être évolué mais je n'y crois pas trop.
            • [^] # Re: Au niveau de l'existant

              Posté par  . Évalué à 3.

              J'ai un répertoire avec tout plein de photos à moi. J'ai envie que ma copine puisse les voire, supprimer etc ...
              Mais je ne veux pas que ma copine puisse faire de même avec le reste des fichiers de mon /home (j'ai un backup de la mort pour les photos, pas forcément pour tout mon travail en cours).

              Je mets donc un acl spécifique pour QU'ELLE puisse faire tout ce qu'elle veux avec mes photos, et rien d'autre dans mon home.
              Ainsi je touche pas aux groupes et je cr&é pas un groupe moietmacherie pour juste gérer un répertoire photo.

              C'est aussi ça l'intérêt
              • [^] # Re: Au niveau de l'existant

                Posté par  . Évalué à 3.

                enfin la typiquement, tu mettrais tes photos avec toi en propriétaire , et elle en groupe.
                Quand il n'y a que deux personnes ca va encore :P
                • [^] # Re: Au niveau de l'existant

                  Posté par  . Évalué à 10.

                  C'est quand il y en a beaucoup qu'il y a des problèmes.

                  Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

                • [^] # Re: Au niveau de l'existant

                  Posté par  . Évalué à 2.

                  Et tu es obligé de chgrouper chaque fichier. C'est vraiment très très pratique... En général ca fini par un cron bien dégueux qui tourne toutes les 5 minutes.

                  setfacl -d --set u::rwx,u:brittany:rwx::- Photos
                  Et c'est magique, tout les fichiers hériterons des bonnes permission automatiquement.

                  Peu de monde à besoin de définir des ACL compliquées, par contre il y a beaucoup d'use case ou les ACL rendent facile quelque chose qui était très chiant à faire ou pas possible avec les droits UNIX.
                  • [^] # Re: Au niveau de l'existant

                    Posté par  . Évalué à 2.

                    N'existe-t-il pas un équivalent de umask, pour les ACL ?
                    • [^] # Re: Au niveau de l'existant

                      Posté par  . Évalué à 2.

                      Je comprends ta question.

                      Tu as un mécanisme beaucoup plus puissant que l'umask. Quand un objet est créé il peut hériter automatiquement des permissions de son parent. C'est beaucoup plus pratique qu'un umask, qui lui s'applique à ton uid. En général tu veux définir une politique d'accès pour un fichier ou pour un sous arbre. Pas pour tout les fichiers que tu créés.

                      Le modèle UNIX est assez limité et exige d'énormes contorsions dès que tu veux élargir ou restreindre l'accès à plusieurs personnes. Entre un umask associé à l'uid, la manipulation de groupes qui demande d'être root, de ne pas pouvoir hériter des permissions du répertoire parent, de ne pas avoir de mask. Marrant, je me souviens de la même discussion en 2004...
                  • [^] # Re: Au niveau de l'existant

                    Posté par  . Évalué à -1.

                    Enfin pour madame michu les droits de permissions qui sont complique a mettre en place (c'est a dire les ACL sous linux et equivalents sur les autres systemes) cela ne sert a rien! Et si il faut un expert pour mettre en place les groupes et les users sont dans 99% des cas bien suffisant a mon avis.
                    • [^] # Re: Au niveau de l'existant

                      Posté par  . Évalué à 2.

                      Mettre en place des groupes ca demande d'être root et d'effectuer une action à chaque fois qu'un fichier est créé (chgroup). C'est difficile de faire moins pratique. Et ça devient un bordel innommable de gérer 126 groupes dont tu ne sais pas vraiment à quoi ils servent.

                      Faire la même chose avec des ACL, ca ne demande pas de privilège particulier, et une unique action. Une fois que ta règle par défaut a été ajoutée t'es tranquille et ca n'a aucune incidence sur les autres fichiers. Tu peux facilement proposer une interface graphique très simple proposant "Partager tout les fichiers créés dans ce répertoire avec les utilisateurs suivants". Chose impossible avec les droits UNIX. Pourtant ça me semble être ce que veulent faire les gens en pratique...

                      Tout ce que tu dis c'est que les interfaces graphiques sont merdiques. Rien de nouveau sous le soleil. La première utilisation des ACL que j'ai eu, c'était pour partager les répertoires Video et Music de chaque compte entre tout les membres de la famille en 2002. Comme tu le vois un use case d'entreprise avec une sécurité militaire loin des besoins de madame michu. J'attends ta proposition pour une solution aussi simple avec les droits UNIX...
                      • [^] # Re: Au niveau de l'existant

                        Posté par  . Évalué à 0.

                        tu remarqueras que je n'ai pas dit que les ACL etaient inutile en soit. Juste que sur tous les OS c'est le merdier pour s'en servir et que au final madame michu passe outre et soit elle fait pas de repetoire partage soit le systeme est tout ouvert (sous windows de tout de facon 90% des pc sont sous un seul compte: le comte administrateur donc ils s'en tapent soit sous linux tu as differents utilisateurs mais souvent tu peux ouvrir la plupart des fichiers et repertoire d'un autre utilisateur.
                    • [^] # Re: Au niveau de l'existant

                      Posté par  . Évalué à 2.

                      Avec des ACL tu peux faire des GUI pour les cas d'utilisations simples et courant, genre ajouter un utilisater dans la liste des personne qui ont droit de modifier un dossier et ses fichiers par exemple.

                      Ça réponds à des besoins simples, facilement compréhensibles et explicables, sans exploiter toutes la puissance des ACL, mais on s'en fout un peu complètement, enfin madame Michu surtout.
                  • [^] # Re: Au niveau de l'existant

                    Posté par  . Évalué à 2.

                    Et tu es obligé de chgrouper chaque fichier.
                    setgid sur le répertoire racine, une seule foi.
                    Normalement ça marche.
            • [^] # Re: Au niveau de l'existant

              Posté par  (Mastodon) . Évalué à 2.

              Perso je m'y suis intéressé rapidement par pure curiosité, et l'intérêt est évident. La mise en oeuvre demande du boulot. Chez moi je n'ai jamais ressenti le besoin de les mettre en oeuvre pour autre chose que pour "voir" (de toute façons chez moi, on pourrait m'effacer des répertoires entiers que je ne m'en apercevrai que quant le proprio ralera), et au boulot malheureusement on les utilisent pas. Cela devrait être une fonction par défaut, je suis d'accord là dessus. Les distributions pourraient faire l'effort de l'intégration des ACLs pour quelques fonctions pratiques et basiques, je sais pas moi, faire une partoche /home/share/bin pour éviter d'avoir un vrai ~/bin. Mais bon ... c'est une exemple typique pù certains diront "c'est très cons" lorsque d'autre verront une utilité pour eux. Les ACLs s'est typiquement le genre de trucs qu'il est difficile d'appliquer par avance d'une part, et dont le système n'a pas vraiment besoin pour lui même d'autre part. Donc... c'est peut être pour cela que c'est peu utilisé ?
      • [^] # Re: Au niveau de l'existant

        Posté par  (Mastodon) . Évalué à 2.

        Pour les acl les réponses sont déjà là. (quoi qu'on pourrait citer les filers de chez NetApp par exemple, pour ceux ayant déjà tripoter ce genre de choses c'est vraiment bien, la gestion de droits avancés, pour s'affranchir des limitations que pbpg décrit fort justement ici, ouaih :p)

        Pour la fonctionnalité de snapshooting, détrompes toi car je pense qu'il s'agit d'une fonction très attendue. C'est une fonction qui va permettre de mieux supporter le rythme effréné de développement de linux et des logiciels libres. Et cela, pas que pour Mr et Mme Michu...

        En se situant au niveau du FS, la fonction devient transversale, s'affranchit des trucs-uiq-marchent-mal comme l'option de Yum, de Urpmi et de Apt. Qui prends tout les fichiers du système, et non le système lui même. IRL les fichiers contenus pas le système sont plus importants que le système lui même, dans de très nombreux cas

        Pour avoir pas mal manipulé OpenSolaris, après des tests persos et après les bons conseils de Bruno B, je peux dire que c'est vraiment un régal à l'usage. En fait c'est même une killer feature. Car je n'en doute (je vérifie même pas avant) que tout comme les FS ext, il sera possible de déporter le journal d'une machine sur une autre machine, et d'y tirer les snapshooting. Les systèmes de sauvegarde tels que nous les connaissons sont en train de disparaitre, doucement, mais surement.

        C'est vraiment ce genre de fonctions, intégrées à bas niveau, qui va permettre d'avoir moins de machines "figées" recevant juste quelques mises à jour classiques (et encore...) parcequ'on a peur de les péter. Car sur ces machines aussi il faut valider les maj classiques sur une machine neutre. Cela ira tellement plus vite avec le snapshooting de fs...Moins de machines figées, plus de machines prête à suivre le rythme de développement de linux, moins de failles.

        mes deux cents.
  • # Magie des snapshots !

    Posté par  (site web personnel) . Évalué à 3.

    Personnellement, je ne vois aucun autre intérêt au système que celui décrit, mais quel intérêt !!!! C'est trop génial :D
    • [^] # Re: Magie des snapshots !

      Posté par  (site web personnel) . Évalué à 10.

      Je trouve dommage, ça enlève la petite suée et les tremblements aux moments de lancer une grosse modification sur un serveur ...

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

      • [^] # Re: Magie des snapshots !

        Posté par  . Évalué à 10.

        Si tu veux garder cette sensation (voire mieux : la doubler), il suffit d'utiliser BtrFS tant qu'il est encore en phase de développement et jouer avec les snapshots !
        Adrénaline garantie \o/
  • # Pas si invisible que ça

    Posté par  . Évalué à 6.

    Si le gestionnaire de paquets utilise les snapshots et que pendant ses mise à jour Mr Michu tape une lettre ou récupère ses emails et que la mise à jour tourne mal, plus de lettre sauvegardée, et plus d'emails. Ça peut être très gênant.

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Pas si invisible que ça

      Posté par  (site web personnel) . Évalué à 2.

      Il faut donc stocker les mails sur le home, qui ne sera pas concerné par le revert..
      • [^] # Re: Pas si invisible que ça

        Posté par  (site web personnel) . Évalué à 4.

        Sauf avec les distrib qui mettent / et /home sur la même partition :/
        • [^] # Re: Pas si invisible que ça

          Posté par  . Évalué à 2.

          Lesquelles ? Oo
          • [^] # Re: Pas si invisible que ça

            Posté par  . Évalué à 9.

            Ubuntu ?

            En version desktop, elle ne gère pas LVM, et crée deux partitions par défaut, / et swap. C'est vraiment une distribution rétrograde.

            C'est peut-être pour ça qu'elle s'impose sur le bureau : elle imite Microsoft qui a compris que la clef du succès réside dans la pauvreté technique et la richesse du bling bling.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Pas si invisible que ça

      Posté par  (site web personnel) . Évalué à 3.

      Mais non, car un type ingénieux va mixer l'emmental[1] avec Brtfs et ainsi créer la fonctionnalité emmental-snapshot. Donc lors du snapshot on défini des trous (genre les fichiers déjà ouvert avant le snapshot) ...
      Je sais pas si c'est déjà existant, mais ça serait pas mal.

      [1] http://fr.wikipedia.org/wiki/Emmental

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

      • [^] # Re: Pas si invisible que ça

        Posté par  . Évalué à 3.

        Ça me marche pas s'il démarre l'application après.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Pas si invisible que ça

        Posté par  (Mastodon) . Évalué à 2.

        Ce dont tu parles ressemble fort à la fonction de backup de Oracle... C'est drôle, c'est justement Oracle qui s'occupe de btrFS.
    • [^] # Re: Pas si invisible que ça

      Posté par  (Mastodon) . Évalué à 2.

      euh...ça c'est si tu es assez con pour utiliser le même volume pour ton système et les données utilisateurs.

      Quand on utilise un volume manager et des FS moderne, on crée des volumes à tour de bras pour chaque type d'usage.
    • [^] # Re: Pas si invisible que ça

      Posté par  (site web personnel) . Évalué à 4.

      Je ne sais pas dans quel monde vous vivez. Madame Michu utilise hotmail, gmail, laposte, ... : un webmail en ligne.

      Sinon pour ne pas perdre de fichier lorsqu'un "rollback" est fait par apt-get, il « suffit » que le système et la $HOME soient sur des partitions séparées.
  • # ZFS

    Posté par  . Évalué à 10.

    c'est ce que font les clones sous ZFS. Ces clones sont basés sur les snapshots (i.e. un clone a pour source un snapshot, qui a lui même pour source un dataset). Comme pour les snapshots, créer un clone est instantané et celui ci ne consomme pas un seul octet à l'initialisation.

    Si les modification apportées à un clone sont validées alors ont peu transformer ce clone en dataset à part entière avec la commande promote (le snapshot sous-jacent au clone devient un snapshot du nouveau dataset). On peut, ainsi, préparer une mise-à-jour d'application sur un clone, et si tout est OK, on le promeut et supprime l'ancien dataset orgininal.... pratique !
    • [^] # Re: ZFS

      Posté par  . Évalué à 6.

      et celui ci ne consomme pas un seul octet à l'initialisation.
      Sisi.
      L'information n'est pas ex nihilo. La création d'un snapshot consomme bien de la place sur le fs (ne serait ce que pour conserver la racine de l'arbre et indiquer qu'il y a un snapshot).

      Par contre cette information est extrêment faible, et ne dépend pas de la taille des données dans le snapshot
      • [^] # Re: ZFS

        Posté par  . Évalué à 2.

        oui bon, tu as raison, mais tu chipotes; tu vois bien l'idée qu'il y avait derrière mon propos.

        D'ailleurs, en chipotant aussi, je dirais que ce sont les metadata du snapshot qui prennent un peu de place (nom, source dataset), le snapshot en lui même prenant effectivement 0 octet :-)
  • # BRTF

    Posté par  . Évalué à -2.

    Par contre il a l'air limité au raid0, raid1 et raid10. Sinon j'ai cherché sur le site mais pas de trace s'il supporte lvm.
  • # Mais say super!

    Posté par  . Évalué à 2.

    En plus de madame Michu, ça résoud aussi le problème de "comment faire une image disque à un instant T d'un serveur en production dont les données arrêtent pas de changer".

    :+)

    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: Mais say super!

      Posté par  (site web personnel) . Évalué à 3.

      Oui, enfin ça, lvm sait déjà le faire depuis longtemps. D'ailleurs, c'est à peu près la seule manière de faire des sauvegardes cohérentes d'un serveur.
  • # Waouw

    Posté par  . Évalué à 4.

    Comme quoi, Mme Michu n'est pas si bête que tout le monde le prétend. Elle apprend vite ! Et ça, surtout depuis que son fiston à installer nunux.
  • # Cas des bases de données

    Posté par  . Évalué à 2.

    Qu'en est-il au niveau des bases de données ?

    En général, à moins de geler la base, il n'y a aucun moyen de savoir si les fichiers de base sont cohérents au moment du snapshot. La restauration du snapshot peut donc entraîner une corruption de la base.

    Btrfs apporte-t-il une solution à ce problème ?
    • [^] # Re: Cas des bases de données

      Posté par  . Évalué à 2.

      Un bon gestionnaire de base de donnée (comme PostgreSQL) fait ça.
    • [^] # Re: Cas des bases de données

      Posté par  . Évalué à 1.

      > La restauration du snapshot peut donc entraîner une corruption de la base.

      Non. Pas avec un bon gestionnaire de donné puisqu'il doit aussi supporter les coupures de courrant par exemple.
      MySQL pose problème car par défaut il n'utilise pas flush.
      • [^] # Re: Cas des bases de données

        Posté par  (site web personnel) . Évalué à 4.

        Normalement, le flush n'est pas nécessaire, car Btrfs gère également le cache des fichiers, donc s'il est correctement codé, il met dans le snapshot le contenu du cache (donc il faut un flush global, comme si la commande sync était appelée juste avant toute opération sur les snapshots)
  • # Pas de titre

    Posté par  . Évalué à 10.

    Un snapshot est une image de l'état dans lequel se trouve le système de fichier à un instant T.

    Un instantané, quoi. Mais le français, c'est has been.
  • # Faisable avec LVM

    Posté par  . Évalué à 1.

    Avec LVM, on peut déjà le faire. Pour sauvegardé une BD :
    arrêt BD, snapshot, start BD, montage dans /saved_fs, sauvagarde, destruction du snapshot.
    Par contre, je ne sais pas si on peut revenir en arrière.
    • [^] # Re: Faisable avec LVM

      Posté par  . Évalué à 10.

      arrêt BD
      start BD
      Ben ça, déjà, ça pue. :D

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # git ?

    Posté par  (site web personnel) . Évalué à 1.

    Cela ressemble beaucoup à git tout ça.

    "La première sécurité est la liberté"

    • [^] # Re: git ?

      Posté par  (site web personnel) . Évalué à 6.

      Oui et non. Essayes de versionner une partition de 100Go avec Git, la moindre opération va prendre plusieurs minutes. Et côté utilisation du disque, avec Git, tu auras au moins une copie du fichier sur le disque, et une autre (compressée) dans .git/.

      Les snapshots, c'est un truc à peu près instantané quelle que soit la taille de la partition, et qui ne stocke pas en double les trucs qui n'ont pas à l'être.

      Par ailleurs, une fonctionnalité importante d'un gestionnaire de backup est de pouvoir oublier certains snapshots (typiquement, faire un snapshot par minute conservé quelques minutes, puis un par heure conservé sur la journée, puis un par jour, ...). Avec Git, au contraire, une fonctionnalité essentielle est qu'on ne peut pas éditer l'historique sans tout casser.

      Bref, un système de backup à base de snapshot et un gestionnaire de versions, c'est pas fait pour la même chose, et ça ne répond pas aux mêmes besoins.
  • # Réinventer la roue ?

    Posté par  (Mastodon) . Évalué à 6.

    (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).

    Ça fait trente ans que VMS fait ça.
  • # Bonne idée

    Posté par  (site web personnel) . Évalué à 1.

    J'ai dernièrement fait un rm -rf * dans mon homedir ... je pensait être dans un sous dossier.

    Finalement, je n'ai pas perdu grand chose. Principalement le dossier Desktop (qui me sert de poubelle en quelque sorte) mais j'ai eu peur sur le moment.

    Vive btrfs
  • # BtrFS et Wikipedia

    Posté par  . Évalué à 2.

    Je viens de faire un tour sur la page de Btrfs et je vois qu'il est annoncé :"Introduction Stable: 23 mars 2009".
    Alors :
    * Soit y a quelqu'un qui s'est chié sur la page de WP ;
    * Soit j'ai raté un épisode dans l'évolution de BtrFS ;
    * Soit j'ai pas compris ce que le mot "introduction" voulait dire (ça, c'est vrai).

    Pour info, la page en:Btrfs indique "Introduced Stable: Yet to be released".
  • # "Autre cas, la fameuse «restauration système» de Windows..."

    Posté par  . Évalué à 1.

    Windows est donc en avance sur Linux, non?

    -->[]
  • # FS/Noyau

    Posté par  (site web personnel) . Évalué à 2.

    >> Petit rappel : Btrfs est un nouveau système de fichier pour le noyau Linux

    Un FS, c'est à quel point dépendant du noyau ? C'est pas supposé justement être un truc assez abstrait pour être manipulé par n'importe qui ?

    Ou alors est-ce que la phrase est un raccourci pour (le très long et chiant) « un système de fichiers prévu comme choix par défaut pour les prochaines distributions d'OS qui tournent sous un noyau GNU/Linux » ?

    En tout cas, ça a l'air cool, mais il me reste deux/trois questions
    Le snapshot reste-t-il sur la même partoche ? Le FS est-il distribué ? Peut-on prendre un instantané d'un(e liste de) répertoire(s) et non de toute une partition ou de tout le système ? Peut-on prendre plusieurs instantanés et revenir de n en arrière ? Peut-on restaurer chez soit un snapshot d'un autre système (en supposant que les deux étaient identiques lors de la « photo ») ?
    • [^] # Re: FS/Noyau

      Posté par  . Évalué à 2.

      De ce que j'ai compris de la discussion ci-dessus, le snpashot ne change pas de partition, vu que quand on le fait il ne se passe (presque) rien !
      Il n'y a pas réécriture des données, mais seulement création des métadonnées le déclarant (un peu comme la création d'un tag dans un dépôt SVN : ça ne duplique pas le code, ça ne fait que marquer une révision particulière).
      • [^] # Re: FS/Noyau

        Posté par  (site web personnel) . Évalué à 2.

        Donc c'est du "write on commit" avec une liste de modifications pour les blocs modifiés.

        Donc une simple écriture incrémentale¹ sur le disque. J'ai rien contre, mais je pense qu'il vaut mieux passer du temps sur des trucs utiles comme de bon FS distribués alors…

        ¹: Je m'imagine bien que je simplifie là, mais bon. On n'est plus à l'âge d'augmenter la vitesse des processeurs, ni à celui de pleurer quand on fait rm -rf /
        • [^] # Re: FS/Noyau

          Posté par  . Évalué à 3.

          BTRFS n'est pas un FS distribué, c'est un FS destiné à gérer physiquement les données sur un support de masse (disque dur, SSD, ...).
          Toutes les personnes qui utilisent un ordinateur ont besoin d'un système de fichiers localement, les cas d'utilisations d'un FS distribué sont plus ciblés et concernent beaucoup moins de monde.
          Il vaut mieux passer son temps sur un FS qui profitera à tout le monde.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.