ext3cow : système de fichier versionné

Posté par (page perso) . Modéré par Jaimé Ragnagna.
Tags :
1
7
mai
2007
Linux
ext3cow est un système de fichier versionné basé sur ext3. Il fonctionne sur le noyau Linux 2.6, est disponible sous forme de patch, et il est bien entendu opensource. ext3cow (third extended filesystem, copy-on-write) permet aux utilisateurs de voir leur système de fichier (fichiers et répertoires) comme il était à n'importe quel point dans le temps passé (« timeshifting »).

Cela peut être utile pour la gestion de révision évidemment (code source, documentation, fichiers personnels, etc.), mais aussi la détection d'intrusions, la prévention de perte de données et également pour répondre aux besoins légaux de rétention de données.

Certains points de ext3cow sont intéressants :
  • il ne pollue pas les répertoires de copies de fichiers nommés (généralement suffixés) par un identifiant de version ;
  • il consomme peu en terme de stockage (5 à 15 % de metadata) et performance (lors des snapshots) ;
  • il est modulaire et ne nécessite pas de changements du noyau ou des interfaces VFS.

Le concept de système de fichiers versionnés n'est pas nouveau (euphémisme), mais ext3cow diffère des autres par de nombreux avantages (voir synthèse en PDF), dont le fait qu'il référence des versions à n'importe quelle date dans le temps et pas par des identifiants de version (qu'il faut évidemment connaître). ext3cow est bien entendu incompatible avec ext2/ext3, mais il devrait apparaître des outils de conversion triviaux rapidement car il y a regain d'intérêt dû à une brève sur Slashdot. Exemple rapide :
[user@machine] echo "This is the original foo.txt" > foo.txt
[user@machine] snapshot
Snapshot on . 1057845484
[user@machine] echo "This is the new foo.txt." > foo.txt
[user@machine] cat foo@1057845484
This is the original foo.txt.
[user@machine] cat foo
This is the new foo.txt.
[user@machine] snapshot /usr/bin
Snapshot on /usr/bin 1057866367
[user@machine] ln -s /usr/bin@1057866367 /usr/bin.preinstall
[user@machine] /usr/bin.preinstall/gcc
  • # intéressant

    Posté par . Évalué à  8 .

    c'est intéressant, et cela à l'air sympa à utiliser. Par contre est-ce que cela ne fait pas un peu redondance face à un système comme zfs, qui semble plus puissant tout en offrant entre autres cette fonctionnalité, et surtout qui permettrait d'avoir un système de fichier compatible linux, *bsd et mac osx ?

    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: intéressant

      Posté par (page perso) . Évalué à  3 .

      ben le Leopard de chez Mac est censé intégrer cette nouvelle fonction sous la dénommination Time Machine.

      D'ailleurs à ce sujet, je trouve vraiment classe que la communauté du libre soit aussi "dans le match" à ce niveau là.

      Je n'y vois que des avantages au boulot, par exemple, ou je passe pas mal de temps à corriger des versions de fichiers...
      je vais suivre avec attention ce développement, en tout cas.
      • [^] # Re: intéressant

        Posté par . Évalué à  3 .

        justement, il me semble que le "time machine" utilise ou utilisera zfs pour ajuster plus finement ses possibilités ?

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: intéressant

          Posté par . Évalué à  7 .

          non

          Time Machine d'apple n'est qu'un programme de backup et une élégante interface pour parcourir ce backup

          le backup est stocké dans un dossier, avec des sous dossiers pour les jours de sauvegardes

          ce n'est PAS ZFS
          ce ne sont PAS des meta-données (que gère déjà HFS+)
          ou des "forks" de fichiers (que gère HFS+)

          ce n'est PAS lié au système de fichier (léopard n'abandonne pas hfs+ )

          ce n'est PAS du snapshot.
          --

          cela dit , oui ZFS sera intégré à leopard. les beta permettaient déjà de créer des partitions ZFS avec toutes leurs possibilités (sauf en faire une partition de boot, le firmware des mac ne sachant pas booter dessus pour le moment).
    • [^] # Re: intéressant

      Posté par . Évalué à  5 .

      Il n'y pas une histoire de licence qui empêche que ZFS soit intégré au noyau Linux?
      • [^] # Re: intéressant

        Posté par (page perso) . Évalué à  2 .

        a priori c'est plus le cas, selon Wikipedia :

        http://fr.wikipedia.org/wiki/Zettabyte_File_System

        "Sun a indiqué qu'ils comptaient porter le produit sur Linux. Actuellement, il n'y a aucun projet pour HP-UX, ou même AIX. Mais depuis que ZFS est en open source, le portage peut être effectué sans la participation de Sun. Matt Dillon du projet DragonFlyBSD a d'ores et déjà prévu de porter ZFS pour la version 1.5 de leur OS.

        ZFS est désormais supporté par Leopard Mac OS X, ainsi que sur la dernière version de Tiger (10.4.9)."
        • [^] # Re: intéressant

          Posté par (page perso) . Évalué à  4 .

          Youpiii on aura enfin un système de fichier moderne pour notre OS.

          Certaines personnes peuvent trouver que l'utilisation de nos bonnes vieilles partitions est excellante, mais je pense plutôt que cela rend difficile toute opération de redimentionnement. Du coup lorsque j'ai acheté un disque de 200GB, j'ai fait une multitude de partitions de 10GB qui ne sont finalement pas pratiques.
          Et si c'est compatible Mac OS X, que du bonheur.

          Concernant l machine a remonter le temps, je trouvais cela uen très bonne idée de la part d'Apple. Nous on l'a (avec les gestionnaires de révisions comme bzr notament qui ne nécessient pas de créer un repository, je le conseille d'ailleurs, ou maintenant avec ext3cow) mais ce n'est pas intégré dans l'interface graphique et pas acessible aux utilisateurs de base. Sans forcémennt faire une interface 3D comme dans Mac OS, je pense que cela peut être intéressant d'intégrer cela.
          Et il y a aussi le fait que je pense que la machine a remonter le temps prendra des snapshots automatiquement aussi. Même si on doit pouvoir en faire soi même aussi, je pense.
      • [^] # Re: intéressant

        Posté par . Évalué à  4 .

        je ne savais pas, merci de l'info. Effectivement :

        http://kerneltrap.org/node/8066

        Par contre c'est en développement pour fuse, et l'argumentaire ici est intéressant également :

        http://zfs-on-fuse.blogspot.com/2007/04/zfs-in-linux-kernel.(...)

        moi je rêve d'un système de fichier pleinement compatible entre tous les unix (linux, *bsd, solaris, mac os x).
        Qui a dit vfat ?

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: intéressant

          Posté par . Évalué à  3 .

          EXT3cow : Introduced July 2003 (Linux)

          ZFS : Introduction octobre 2005 (Solaris 10)



          Mais bon comme d'hab' l'utilisateur final va d'abord s'en servir sur Mac & Co grâce à une interface graphique adaptée...
          • [^] # Re: intéressant

            Posté par . Évalué à  3 .

            >l'utilisateur final va d'abord s'en servir sur Mac & Co

            Personnellement, je me souviens d'avoir utilisé un système de versionnement de fichier sur VMS, donc c'est un peu plus vieux que ça.

            Mais sinon tu as raison si on prend le nombre d'utilisateurs finaux de VMS + de Solaris 10 + de distrib Linux fournissant Ext3cow, on est probablement loin du compte du nombre d'utilisateurs Mac qui l'utiliseront..
            • [^] # Re: intéressant

              Posté par . Évalué à  6 .

              Ce qui serait bien c'est que l'on arrive enfin à avoir un système de fichier commun à un maximun d'OS et qui soit plus évolué que la FAT32.
              Parce que à l'heure des clés USB, des disques durs portables, etc. il est dommage de ne pouvoir utiliser que la FAT32 si on veut être certains de pouvoir partager nos données avec nos amis sous Mac, Windows, Linux, Solaris, etc.
              ZFS a une bonne tête, mis à part, son problème de licence. Alors Monsieur Sun un petit effort?
              • [^] # Re: intéressant

                Posté par . Évalué à  1 .

                Et bien le probleme c'est Windows, comme ils represent une grosse majorité des utilisateurs et que ZFS pour Windows, ce n'est pas près d'arriver..

                D'un autre coté, il me semble qu'il est possible de lire des partitions ext2 sous Windows (en ajoutant un soft), c'est toujours mieux que FAT..
                • [^] # Re: intéressant

                  Posté par . Évalué à  1 .

                  Oui Windows peut accéder à de l'ext2, c'est que j'entends dire souvent quand je parle de ce sujet. Mais franchement qui utilise encore de l'ext2? La norme c'est l'ext3, or rien n'existe pour l'ext3, donc retour à la FAT32 ...
                  • [^] # Re: intéressant

                    Posté par . Évalué à  6 .

                    Il me semble que l'ext3 c'est de l'ext2 avec un journal.
                    Le journal n'a pas d'utilité réelle sur une clef USB par exemple.
                    De plus une partition ext3 peut être lue en tant que partition ext2.

                    Bon, après il y a sûrement des problèmes, ça ne peut pas être si simple ^^


                    Yth.
                    • [^] # Re: intéressant

                      Posté par . Évalué à  2 .

                      sur une clé de 512Mo sûrement pas mais sur un disque externe de 500Go je pense que oui! On peut effectivement lire de l'ext3 en utilisant de l'ext2 mais pas écrire. Or quand je parle de partager des données ce n'est pas à sens unique.
                    • [^] # Re: intéressant

                      Posté par . Évalué à  2 .

                      Non, il n'y a pas de problème : c'est juste qu'on ne profite pas de la journalisation. C'est très bien expliqué sur le site de je-ne-sais-plus-quel-pilote-EXT2-pour-Windows.

                      En fait si, il y a un gros problème : EXT? n'est pas installé par défaut sous Windows... Très ballot, si on veut une clé USB universelle ! Ou alors, il faut garder une partition FAT32 pour le pilote EXT2 pour Win.

                      Sinon, il reste NTFS (ntfs3g sous Linux). Mais ça n'est pas installé sous MacOSX...
                      • [^] # Re: intéressant

                        Posté par . Évalué à  2 .

                        Et le mélange entre accès journalisés et accès non-journalisés au final ça ne risque pas de faire des trucs bizarres?
                        • [^] # Re: intéressant

                          Posté par . Évalué à  3 .

                          j'ai déjà essayé le prg pour accéder à ext2 ou ext3 sous windows, apparememnt on pouvait lire et écrire sans pb sur du ext3. Après, à long terme je ne sais pas ce que cela donne.
                          Je suis avant tout pour un système communs aux unix, après, pour windows, cela sera à microsoft de s'adapter s'ils veulent l'interoperabilité...

                          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

                          • [^] # Re: intéressant

                            Posté par . Évalué à  3 .

                            Mes disques externes sont tous en ext3 et je n'ai pas eu de problème en presque une année d'utilisation...Je le monte depuis des machines linux, bsd et windows.

                            Sous windows, j'utilise le driver Ext2fsd :
                            http://ext2fsd.sourceforge.net/
                            Cela étant dit, en dehors du filesystem lui-même, il est impossible de partager un FS entre des machines big-endian et little-endian. Je n'ai pas encore trouvé de solution à ce problème (monter sur une machine sparc un disque formaté sur une i386 par exemple).
                            • [^] # Re: intéressant

                              Posté par . Évalué à  2 .

                              à ton avis, un répertoire linux /home en ext3, monté également en /home sous freebsd, c'est jouable ou c'est risqué ? Le module pour ext3 sous freebsd est-il facilement installable ?

                              J'ai le même répertoire /home pour les différents linux qui sont sur ma machine et cela fonctionne plutôt bien, mais j'aimerais également installer freebsd dessus. C'est plutôt pas mal de se retrouver sur le même bureau avec les même paramètres.

                              Question subsidiaire : et sous Solaris ?


                              Par contre il y a un module pour monter du ext3 sous Mac OS X, et il a salement tendance à faire des kernel panic lors de la copie de fichiers...

                              Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

                              • [^] # Re: intéressant

                                Posté par . Évalué à  3 .

                                pour le /home je n'ai jamais osé le faire, je dirais que c'est risqué au niveau de tes fichiers de conf des applis si celles-ci ne sont pas à la même version. J'ai toujours stocké les données que je partage dans une partition séparée de /home. Mon home ne me sert globalement qu'à stocker mes configs justement.

                                Sous solaris il existe un driver développé par SCO qui est fourni avec lxrun (un emulateur linux) mais il ne monte pas les partitions en écriture :
                                http://developers.sun.com/solaris/articles/lxrun/
              • [^] # Re: intéressant

                Posté par . Évalué à  6 .

                ZFS a une bonne tête, mis à part, son problème de licence
                problème de licence ?
                Zfs est sous licence libre.
                Alors que ce soit pas compatible avec la gplv2 mais avec la gplv3 (mais est ce que la gplv3 est compatible gplv2 ? ) c'est vrai, mais c'est pas le probleme de zfs la, c'est plutot le probleme de la licence du noyau linux qui n'accepte pas la licence de zfs.

                Et puis on l'a déja sous fuse, et il devrais etre aussous sous freebsd. donc le probleme de licence n'est pas si grand.

                Y a meme des entreprises qui font des modules propriétaires , donc c'est tout a fait possible d'avoir un module a part pour mettre zfs.

                Alors Monsieur Sun un petit effort?
                Celui qui doit faire l'effort c'est pas tant sun que les gens du noyau linux pour passer en gplv3 , si il le veule bien entendu.

                On a une entreprise qui fourni un OS complet sous licence libre, et on trouve que c'est nul, qu'il faut que ce soit forcément sous gplv2 ou bsd ?
                • [^] # Re: intéressant

                  Posté par . Évalué à  3 .

                  >c'est vrai, mais c'est pas le probleme de zfs la, c'est plutot le probleme de la licence du noyau linux qui n'accepte pas la licence de zfs.

                  Le noyau Linux était sous licence GPLv2 bien avant que ZFS existe, donc dire que c'est un problème du noyau est absurde.

                  >On a une entreprise qui fourni un OS complet sous licence libre, et on trouve que c'est nul, qu'il faut que ce soit forcément sous gplv2 ou bsd ?

                  Les incompatibilités entre les licences sont regrettables car cela fragmente la base de code utilisable, certes le probleme existait deja entre la GPLv2 et la BSD mais la c'est une difference de philosophie qui sépare les deux licenses, pas une incompatibilité volontaire entre deux licenses équivalentes..
                  • [^] # Re: intéressant

                    Posté par . Évalué à  1 .

                    Le noyau Linux était sous licence GPLv2 bien avant que ZFS existe, donc dire que c'est un problème du noyau est absurde.
                    Zfs a pas été concu pour le noyau linux, donc dire que la licence de zfs est nulle parce que pas gplv2 est tout aussi absurde.

                    Les incompatibilités entre les licences sont regrettables
                    C'est compatible gplv3 !
                    (et si on peut passer le noyau en gplv3 par un systeme d'acceptation tacite, comme ce fait les brevets américains: on dis publiquement qu'on souhaite le passer en gplv3. Si au bout de n moi personne ne s'est manifesté (et/ou que les gens qui ce sont manifesté on a réécris leurs code) alors on peut passer en gplv3.
                    Le probléme est plus politique qu'autre chose.

                    pas une incompatibilité volontaire entre deux licenses équivalentes.
                    C'est bien connu, sun a RIEN distribuer de libre et quand ils distribuent ils en veulent particulièrement à la gpl ... mais seulement à la V2, pas à la v3...

                    Le libre c'est respecter les 4 libertés.
                    La licence de sun EST libre, n'en déplaise aux aficionados de la gpl.
                    On rale quand on dis 'ouais si tu veux pas de la gpl ben tu réécris le code !' . Ben eux ils l'ont fait !
                    Et la on rale en disant 'ah euh oui mais non en fait il faut que vous utilisiez la gplv2'.

                    Sun a l'interdiction d'utiliser autre chose que la v2 parce que linus l'a décidé ?
                    Faut arreter la déconnade.

                    Quand on veut avancer, il faut pas que ce soit toujours la meme partie qui fasse tout le chemin. Les kernels hackers ne veulent pas de zfs ? Soit. Mais qu'on arrete de dire que c'est forcément un probleme de licence et que sun 'ce sont des gros méchants'. C'est un des plus gros contributeurs de code libre, mais ce sont encore de gros méchants ?
            • [^] # Re: intéressant

              Posté par . Évalué à  3 .

              Ce genre de fonctionnalités date des années 80. De nombreux systèmes tolérants aux fautes utilisent ça depuis longtemps... Ce genre de chose était utilisé sur des gros ordinateurs avec de la redondance partout et des systèmes mémoire+disque ad hoc.

              1978:
              http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1455(...)

              1975:
              http://portal.acm.org/citation.cfm?id=390016.808467
  • # IPoT

    Posté par (page perso) . Évalué à  10 .

    Couplé avec l'IPot ça peut devenir un outil surpuissant pour prévoir les intrusions futures et les éviter.

    ext3cow couplé à IPoT, quelques scripts pour régler à la volée le firewall : je crois qu'on a là une protection ultime :)
    • [^] # Re: IPoT

      Posté par (page perso) . Évalué à  1 .

      L'IPot est un concept en passe d'être dépassé.
      Suffit de lire cet article :
      http://www.lemonde.fr/web/article/0,1-0%402-3244,36-905871%4(...)

      pourquoi "prévoir" quand on peut directement lire les pensées des "intruseurz"?

      Hein?
    • [^] # Re: IPoT

      Posté par . Évalué à  4 .

      En plus, ça permet de mettre en taule les pirates de contenus "culturels" en saisissant leur disque avant même qu'ils ne commettent le délit de contrefaçon !

      (tiens, j'ai déjà vu ça quelque part... )
  • # mouai

    Posté par (page perso) . Évalué à  2 .

    dont le fait qu'il référence des versions à n'importe quelle date dans le temps et pas par des identifiants de version


    Ce ne sont peut etre pas des identifiants de version, mais quand je vois ça

    cat foo.txt@1057845484


    pour moi, ce numéro est tout aussi cryptique qu'un simple numéro de version. Je doute en effet que la majorité des utilisateurs savent faire de tête des conversions de date en nombre de secondes depuis 01/01/70..

    Bref, je ne vois pas en quoi c'est un avantage par rapport à un simple numéro de serie (pour l'utilisateur j'entend).

    À moins qu'on puisse indiquer une vraie date genre foo.txt@2006-04-21_12h35
    (oui, j'ai pas lu la doc, la flemme d'ouvrir tout ces pdf)
    • [^] # Re: mouai

      Posté par (page perso) . Évalué à  5 .

      Comme expliqué dans la documentation, justement, tu peux utiliser la commande suivante pour avoir les numéros en question :
      ls fichier@

      Par ailleurs, ce numéro est le nombre de secondes écoulées depuis le 1er Janvier 1970, soit un nombre « epoch » ou temps Unix.
      En outre, d'après la FAQ, les développeurs envisagent de créer des « macro » comme @yesterdayday ou @lastweek.

      The time-shifting interface doesn’t look very intuitive. What’s up with that?
      The way you access files in the past is with the ‘@’ token followed by an epoch number. We fondly refer to the ‘@’ token as “The Flux Capacitor” for various, non-trademark-infringing reasons. This token is customizable. The epoch number is the number of seconds passed since The Epoch (00:00:00 UTC, January 1, 1970); see the gettimeofday() man page. This may seem a little non-intuitive at first, but we believe any fancier syntax should be supported by the shell, not the file system. This approach is similar to how access and creation time is handled. Take a look at Time-Traveling File Manager if you’re interested in a GUI interface to ext3cow. That being said, we are looking at supporting some common macros in a future version, for example: @yesterday, @lastweek, @lastmonth, etc.
      • [^] # Re: mouai

        Posté par . Évalué à  0 .

        En outre, d'après la FAQ, les développeurs envisagent de créer des « macro » comme @yesterdayday ou @lastweek.

        C'est totalement bidon comme argument.
        Le même genre de "macros" serait tout aussi possible avec des numéros de révisions, puisqu'en général on stocke tout de même la date correspondant au numéro de révision, n'est-ce pas :)
        (par exemple Subversion, Mercurial & co permettent de récupérer une révision par date)
        • [^] # Re: mouai

          Posté par . Évalué à  1 .

          on va la refaire : c'est plus simple et c'est mieux pour tout le monde d'avoir des dates que des numéros de version (1, 2, 3 ...)

          parce qu'une date ca veut dire quelque chose mais un numero de version, rien. ils ont un ordre ? les dates aussi. c'est plus lisible ? seulement quand tu auras 3-4 versions, pas plus.

          en particulier avoir 37 numéros de versions de ton CV, une créée à chaque correction, ne veut rien dire. par contre une date derriere, oui.

          quand tu auras plusieurs dizaines de fichiers différents, chacun avec sa rimbambelle de versions, ca sera plus facile de reperer les fichiers remontant à une date précise d plutot que d'interroger chaque version cv.txt,1 cv.txt,2 cv.txt,3 ... cv.txt,42 pour retrouver la bonne. par exemple le 9 mai 2006 ta bio.txt en sera à la version 4 et ton experience.txt en sera à la version 12 : pas très parlant si tu veux raisonner par date.

          (quelque part je rappelle que c'est juste une question de présentation)


          maintenant, si tu cherchais un système de fichiers qui te garde automatiquement l'ancienne version des fichiers que tu modifies au fur et à mesure, ben ext3cow n'est pas fait pour ça.
          • [^] # Re: mouai

            Posté par . Évalué à  2 .

            on va la refaire : c'est plus simple et c'est mieux pour tout le monde d'avoir des dates que des numéros de version (1, 2, 3 ...)

            Je répète puisque tu as l'air un peu malcomprenant : l'identifiant de révision interne n'est pas obligé de refléter la donnée affichée à l'utilisateur, ni celle que l'utilisateur doit entrer.

            Maintenant d'un point de vue informatique il est évident qu'utiliser des identifiants séquentiels comme identifiants internes a beaucoup plus de sens. Ne serait-ce que parce que si l'utilisateur change l'heure de son système, le versionnage part en couille.

            en particulier avoir 37 numéros de versions de ton CV, une créée à chaque correction, ne veut rien dire.

            Bien sûr que si. Non seulement je sais immédiatement qu'il y a 37 versions (numérotées de 1 à 37), mais je sais aussi que la révision précédant immédiatement la numéro 37 est la numéro 36 (ce qui me permet par exemple, si je me rends compte que j'ai fait une erreur, de retrouver la version juste avant), et ainsi de suite.
            Ce sont des informations tout à fait utiles.

            (évidemment au bout de 8317 révisions sur un dépôt SVN ça commence à être un peu futile, mais la plupart des gens n'accumulent pas 8317 révisions de leurs petits documents à eux)

            (quelque part je rappelle que c'est juste une question de présentation)

            Ha, l'argument initial c'est bien que la date est utilisée comme identifiant interne à la place d'un numéro de révision (ce qui serait, aux dires de l'auteur de la dépêche, un véritable avantage).

            Je suis d'accord que c'est juste une question de présentation, et c'est pour ça que l'argument initial est foireux (la couche présentation n'est pas dans le noyau et encore moins dans le filesystem, enfin j'espère).

            pas très parlant si tu veux raisonner par date

            Oui, si on veut raisonner par date, il est préférable d'utiliser des dates : merci de la tautologie.
            • [^] # Re: mouai

              Posté par . Évalué à  3 .

              > Je répète puisque tu as l'air un peu malcomprenant : l'identifiant de révision interne n'est pas obligé de refléter la donnée affichée à l'utilisateur, ni celle que l'utilisateur doit entrer.

              chic. dans 5 minutes tu vas m'expliquer qu'on utilise les noms de fichiers et non pas les inodes pour travailler tous les jours ? j'espère que tu ne me traiteras pas de nazi mangeur de caca au passage, j'aurais trop trop honte :(

              > Maintenant d'un point de vue informatique il est évident qu'utiliser des identifiants séquentiels comme identifiants internes a beaucoup plus de sens. Ne serait-ce que parce que si l'utilisateur change l'heure de son système, le versionnage part en couille.

              euh... non. déjà, seul root peut changer l'heure du système sur un système décement configuré, ça va peut-être te donner un indice sur le fait qu'on ne la change pas comme ça juste pour s'amuser. et les systèmes distribués de gestion de versions te demandent d'être à l'heure, merci.

              et que tu ressortes tes identifiants séquentiels montre bien que tu confonds avec d'autres systèmes : là c'est le système de fichiers qui est versionné, pas chaque fichier un par un. la date de snapshot d'un fichier a sûrement cent fois plus de sens qu'un "identifiant interne" qui ne veut rien dire pour le système ni pour toi et surtout qui ne voudra rien dire par rapport à un autre fichier avec un historique différent. et en terme de stockage, 64 bits ca tiendra encore longtemps.

              tu peux t'accrocher à une vision de numéros de version qui veulent dire quelque chose comme pour mon exemple de cv.txt,1 cv.txt,2 cv.txt,3 mais comme tu ne feras pas toi-même à la main de snapshot à chaque fois que tu auras modifié un fichier (parce que c'est vite bien relou) tu risques d'utiliser ça comme un undelete du pauvre, comme une sauvegarde imparfaite de tes fichiers si tu lances une tache cron genre toutes les heures pour faire ces snapshots. tu n'auras pas tout perdu, mais il risque de te manquer des modifs. je pense que ca peut etre utile mais ce n'est pas le meilleur usage possible de ext3cow.

              le fonctionnement (et le but) de ext3cow ne te convient peut-être pas parce qu'il ne remplit pas TON besoin ou ce que tu espérais trouver. je te rassure, j'ai été déçu les 2-3 fois où je retombais dessus en cherchant sûrement la même chose que toi, de quoi garder automatiquement des cv.txt,1 cv.txt,2 cv.txt,3 (...) chaque fois que j'éditais mon cv.txt

              (il y a d'autres systèmes qui font ça très bien depuis 20 ans, hein, par exemple VMS : http://en.wikipedia.org/wiki/OpenVMS_filesystem#Disk_organiz(...) : il va gérer les ,1 ,2 ,3 tout seul parce que lui n'a pas besoin d'un système de snapshot)

              > > en particulier avoir 37 numéros de versions de ton CV, une créée à chaque correction, ne veut rien dire.

              > Bien sûr que si. Non seulement je sais immédiatement qu'il y a 37 versions (numérotées de 1 à 37)

              quel génie. malheureusement tu vas vite supprimer, archiver des versions intermédiaires pour des raisons X ou Y comme garder des bonnes versions et faire de la place. donc ton max_version = nombre_de_versions il va en prendre un coup.

              et c'est toi qui parle de tautologie quand tu m'apprends que la révision précédant immédiatement la numéro 37 est la numéro 36 ?

              si tu as des difficultés pour classer 1178850314 11788683145 1181850222, je te rassure, ton ordinateur est là pour t'aider comme iil t'aidera déjà pour classer 35 36 37 sans que tu t'en rendes compte.

              > évidemment au bout de 8317 révisions sur un dépôt SVN

              ding-dong : on ne parle définitivement pas d'un dépot SVN ou équivalent.
              • [^] # Re: mouai

                Posté par . Évalué à  1 .

                déjà, seul root peut changer l'heure du système sur un système décement configuré

                Et ? La plupart des utilisateurs ont l'accès root sur leur ordinateur perso.

                Qu'il faille un mot de passe pour changer l'heure ne change rien au fait qu'on peut la changer, et donc que baser un versionnage sur les timestamps est une connerie.

                D'ailleurs il n'y a même pas besoin d'une bourde de l'utilisateur : il suffit d'une couille quelconque de NTP ou toute autre affre liée à la complexité des systèmes Linux contemporains.

                je pense que ca peut etre utile mais ce n'est pas le meilleur usage possible de ext3cow.

                Je suis bien d'accord, à mon avis ça ne remplace pas un système étudié pour comme Mercurial ou SVN. Maintenant c'est bien sous cet angle-là que c'est présenté ici, donc...

                malheureusement tu vas vite supprimer, archiver des versions intermédiaires pour des raisons X ou Y comme garder des bonnes versions et faire de la place

                Je ne me suis jamais amusé à supprimer des versions intermédiaires dans un système de gestion de versions...
                Quant au fait d'archiver, c'est par construction indépendant des usages évoqués ici.

                et c'est toi qui parle de tautologie quand tu m'apprends que la révision précédant immédiatement la numéro 37 est la numéro 36 ?

                C'est précisément parce que c'est une tautologie que c'est un point fort de la numérotation séquentielle.
                (d'ailleurs, ce n'est pas une tautologie au sens d'une proposition logique vraie par construction, mais une vérité mathématique triviale)
  • # A quand la versionnalisation du future?

    Posté par . Évalué à  6 .

    [user@time-machine] echo "This is the original foo.txt" > foo.txt
    [user@time-machine] snapshot
    Snapshot on . 1057845484
    [user@time-machine] echo "This is the new foo.txt." > foo.txt
    [user@time-machine] cat foo@1057845487
    This is the future foo.txt.


    Ca serait bien j'aurais plus qu'a faire un "cat these.tex.01012009" pour avoir ma these :p
    • [^] # Re: A quand la versionnalisation du future?

      Posté par (page perso) . Évalué à  9 .

      Le soucis est que toute manière pour que ton these.tex@01012009 ne soit pas le même que these.tex@now tu vas devoir l'écrire entre temps...

      Ensuite même si tu pouvais récupérer dès aujourd'hui cette these en faisant un saut dans le futur tu aurais des problèmes divers...

      1 - tu devras écrire cette thèse de toute manière et acquérir les connaissances (parce que dans une boucle il faut apporter le résultat a un moment)

      2 - certaines idées et concepts te paraîtrons incompréhensible ou absurde (car tu n'auras pas encore fait les expériences)

      Bref, le saut dans le futur et dans le passé ça implique pas mal de conséquences...

      Un autre problème est que tu devras choisir de quelle réalité tu prends la thèse, car j'imagine que l'univers a une certaine logique :
      Action => Conséquence

      Et que pour que on ai :
      Conséquence => Action

      Il faut que la conséquence appartienne a un univers 1 et l'action a un univers 2 parallèle et clone du premier...

      Comme quoi même si on arrive a inventer le saut dans le temps on va avoir des soucis de cohérence a se taper si l'univers ne s'en charge pas pour nous.
  • # en mieux

    Posté par . Évalué à  5 .

    pour disposer de ce genre de fonctions sans avoir besoin de dépendre de ext3 ou de patcher son kernel (et qui utilise FUSE donc un peu plus multi-os) :
    http://wayback.sourceforge.net/
    http://n0x.org/copyfs/
    (entre autres)
  • # snapshot

    Posté par . Évalué à  7 .

    [user@machine] echo "This is the original foo.txt" > foo.txt
    [user@machine] snapshot
    Snapshot on . 1057845484


    Arf, c'est qu'un système de snapshot, moi qui croyait qu'a chaque modif du fichier (open/close ?) une version était crée...
    • [^] # Re: snapshot

      Posté par (page perso) . Évalué à  4 .

      Il y a peut être un moyen de mettre une daemon utilisnt inotify sur le coup et qui te créra tes snapshots ... Note que je n'en sais rien.
  • # Intérêt ?

    Posté par . Évalué à  3 .

    Avec ma (dé)formation de dévelopeur je me suis imaginé un système où il fallait entrer un descriptif pour chaque modification :)

    Suis-je le seul à penser que les bons vieux backup de dino sont les seules solutions *fiables* pour garder une trace/l'historique des modifications faites sur un système de fichiers ?

    Et puis quand je lis que le système consomme peu de ressources de stockages (entre 5 et 15%), je me gausse. 15%, ça commence à se chiffrer pour un truc qui in fine, ne servira que rarement. Où alors je n'ai pas bien saisi l'utilité de la chose.

    P.S: au fait, Emacs fait ça depuis des années, c'est simple, il laisse trainer des fichiers partout, du coup je retrouve facilement les X dernières versions de chaque fichier modifié sans me gratter la tête
    • [^] # Re: Intérêt ?

      Posté par (page perso) . Évalué à  1 .

      Je ne pense pas qu'il faille voir ext3cow comme une solution de remplacement d'une solution CVS, SVN ou SVK pour stocker les modifications apportés à des fichiers de configuration. Par contre, c'est plus approprié pour gérer des fichiers binaires comme les bases de données bdb ou autres.
      • [^] # Re: Intérêt ?

        Posté par . Évalué à  5 .

        question idiote, ca se passe comment sur les fichiers ouverts au moment du snapshot ? :]
        • [^] # Re: Intérêt ?

          Posté par . Évalué à  2 .

          et les copies de fichier ? (l'historique suit?)
          et d'une partition a une autre (clef usb formaté en ext3cow) ?
          et quand on supprime le fichier ?
          et je pense que si on fais un tar et que l'on détar dans un autre repertoire on dois perdre l'histo aussi...
          • [^] # Re: Intérêt ?

            Posté par (page perso) . Évalué à  1 .

            Je vous conseille à tous deux de lire le document PDF pour en savoir plus mais ayant lu discussion du journal d'IsNotGood à ce sujet, les snapshots sont atomiques au niveau du système de fichiers.
            Je ne pense pas que l'historique puisse suivre à moins de ne faire un dump d'ext3 (et encore). De même pour tar/détar et je pense qu'il vaut mieux faire soi-même des tests. Quand on supprime un fichier, son historique est conservé.
            Je précise que je ne suis pas du tout spécialiste des systèmes de fichiers.
    • [^] # Re: Intérêt ?

      Posté par (page perso) . Évalué à  3 .

      Le gros intérêt de ce genre de système, c'est que c'est activable pour un sysadmin, sans que les utilisateurs n'aient à s'en occuper. Par exemple, il y a des systèmes ou une restauration de backup se fait avec un truc du genre

      $ cd .snapshot/hourly/12
      $ cp machin-truc ~/la/ou/ca/devait/etre/avant

      C'est très pratique pour réparer des erreurs. Par exemple, essayes « rm -fr .git/ », ou d'autres trucs plus vicieux genre « find . -quelquechose -exec perl -pi -e 's/mahin/truc/' » qui te corromp les fichiers de ton gestionnaire de versions, ou une connerie sur du code pas (encore) commité, ...

      Par exemple, j'ai déjà eu à utiliser le système ci-dessus en arrivant en temps que formateur sur un site. Bon, tout est installé comme convenu dans le répertoire machin/bidule. Sauf qu'il y avait un cron job qui faisait rm -fr machin/bidule/ toutes les nuits :-(.

Suivre le flux des commentaires

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