Journal Journalisation de fichier

Posté par  .
Étiquettes : aucune
0
28
fév.
2007
ext3cow : http://www.ext3cow.com/

Exemple (pris de la doc) :
Fig. 1. Creating snapshots and accessing data in the past in ext3cow.
[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.
Fig. 2. Creating distinguished (named) snapshots in ext3cow.
[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

Sympa non ?
Le tout sans dégradation significative de performance. Ext3COW pour Ext3 Copy On Write. Donc ça ne bouffe pas trop de place disque.

Je n'ai pas souvenir que ext3cow ait été discuté sur linuxfr. Je voulais lui faire un peu de publicité.
Je ne l'ai pas utilisé.

Description détaillée :
http://hssl.cs.jhu.edu/papers/peterson-tos05.pdf

  • # Backups, toussa toussa

    Posté par  . Évalué à 3.

    C'est possible, idealement, d'"exporter" un snapshot sur un media amovible (dvd-rw par exemple) ?

    Parce que quand j'ai un systeme fraichement installe, je le dump sur un dvd, mais je ne me fais pas chier a refaire ca a chaque upgrade... Donc a la reinstallation, galere ! En exportant les snapshots sur un deuxieme DVD, ca pourrait etre possible de faire un DVD de mises a jour pas trop lourd.

    • [^] # Re: Backups, toussa toussa

      Posté par  . Évalué à 2.

      Tu devrais regarder du côté de la commande dump d'ext3.

      • [^] # Re: Backups, toussa toussa

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

        l'interet ici est de ne pas refaire un dump complet, mais juste des modifications depuis le dernier dump, et (à ma connaissance en tout cas) l'outil dump de ext3 ne le fait pas, pour la simple et bonne raison qu'il ne connait que la version courante.

        • [^] # Re: Backups, toussa toussa

          Posté par  . Évalué à 3.

          Lis la doc de dump et reviens en parler.
          -level#

          The dump level (any integer). A level 0, full backup, guarantees the entire file system is copied (but see also the -h option below). A level number above 0, incremental backup, tells dump to copy all files new or modified since the last dump of a lower level.

  • # ZFS

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

    Le copy-on-write est aussi ce que fait zfs, et ce qui fait la puissance de son système de snapshot.

    En ZFS, on ne ré-écrit jamais un fichier en place, on écrit toujours les nouvelles données sur de l'espace non utilisé, et on fait pointer le fichier dessus à la fin de l'écriture, et on efface l'ancienne version. Du coup, le snapshot lui-même ne coute autant dire rien. On note dans un coin que la prochaine fois qu'on fera une écriture, il faudra conserver l'ancienne version. Le paradoxe, c'est qu'une écriture coute un peu moins en temps si on est en train de faire un snapshot.

    Par contre, ce point de la todolist et les archives quasi-vides de la mailing-list me laissent penser que le projet est mort :

    * Update ext3cow for 2.6 kernel.

    • [^] # Re: ZFS

      Posté par  . Évalué à 1.

      Il y a même sur le site : "Last updated: 5/17/05"... Donc effectivement, le projet n'a pas l'air encore très actif.

    • [^] # Re: ZFS

      Posté par  . Évalué à 4.

      > Le copy-on-write est aussi ce que fait zfs, et ce qui fait la puissance de son système de snapshot.

      C'est-à-dire ce que fait lvm (rien de nouveau sous le soleil) et pourtant on ne parle pas de "la puissance de son système de snapshot" quand on parle de lvm. Zfs ne versionne pas un fichier, mais un système de fichier complet (idem pour lvm). ext3cow versionne les fichiers/répertoire. D'où sa spécificité, d'où ce journal. Il faut se rentrer dans la tête que zfs fait plein de truc. Il ne faut pas comparer zfs à ext3 par exemple, mais à ext3+dm+device-mapper+lvm.

      Décidemment le buzzword de zfs est casse pied.

      Tu parles peut-être du "copy-on-write transactional model" de zfs. Mais ça ne fait que 2 versions (l'ancienne et la nouvelle) alors ext3cow en fait autant que tu veux. De plus zfs ne peut pas versionner un répertoire complet. Le copy-on-write transactional model est coûteux en performance.

      > * Update ext3cow for 2.6 kernel.

      Bien vu. C'est bon à savoir :-)
      ext3cow a perdu beaucoup de son intérêt pour moi :-(

      • [^] # Re: ZFS

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

        Je ne suis pas si sur que zfs n'est vraiment que du buzz. Par exemple j'ai lu recemment que sur les tres gros volumes de données (datawarehouse de plusieurs teraoctets sous postgresql), ZFS/Solaris est plus robuste que ext3/linux :

        http://www.arnnet.com.au/index.php/id;413111662

        Bon c'est vrai qu'ils ne donnent pas de détails sur la nature exacte des crashs mais bon c'est un setup un peu compliqué a reproduire.

        • [^] # Re: ZFS

          Posté par  . Évalué à 2.

          > Je ne suis pas si sur que zfs n'est vraiment que du buzz.

          Je n'ai pas dit que c'est que du buzz.

          > ZFS/Solaris est plus robuste que ext3/linux :

          Mouaif. Ext3 est en production depuis des années sur des serveurs critiques et voilà que ZFS/Solaris qui est dispo depuis le 06/2006 lui explose la tronche et que ext3 est bourré de bug.

          S'il y a un bug, montres moi le ticket bugzilla sur par exemple http://bugzilla.redhat.com/ .

          Je peux t'affirmer que Red Hat prend très très très au sérieux tout bug d'ext3. Suse qui est passé à ext3 aussi.

          > http://www.arnnet.com.au/index.php/id;413111662
          Schlossnagle said during testing the large PostgreSQL data mount point suddenly went read-only on CentOS 4 (a Red Hat derivative) with the ext3 file system.

          "So, naturally, I tried to fix the problem by umounting and mounting again, all to no avail," he said. "It turns out that a reboot was required to rectify the issue.

          Le passage en ro ne se fait que si le FS et configuré pour (tune2fs -e). C'est le configuration que j'utilise (le FS passe en read-only s'il détecte une erreur).
          Si le FS est passé en read-only, alors il y a un problème. Bug ext3 : improbable. Problème hardware : très probable. Problème noyau : probable (surtout avec les gus qui installent des noyaux maisons).

      • [^] # Re: ZFS

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

        > C'est-à-dire ce que fait lvm (rien de nouveau sous le soleil)

        On peut faire un snapshot d'un répertoire quelconque avec LVM ?

        > Il ne faut pas comparer zfs à ext3 par exemple, mais à
        > ext3+dm+device-mapper+lvm.

        J'ai dit le contraire ?

        > Décidemment le buzzword de zfs est casse pied.

        Bah, y'a quand même pas mal de trucs que ZFS fait et qui m'ont l'air bigrement intéressantes. Le but de mon message n'était pas de dire que ZFS est mieux que ext3cow (enfin si, mais pour le fait que ZFS est maintenu et pas ext3cow ...). Au contraire : la conception de ZFS ne plait visiblement pas à Linus, les gens de SUN ont estimé que la séparation LVM/filesystem n'était plus d'actualité, et c'est tout le contraire chez Linux. Mais un truc comme ext3cow aurait été un bon moyen d'obtenir l'une des fonctionalités intéressantes de ZFS dans ext3. Dommage :-(.

        • [^] # Re: ZFS

          Posté par  . Évalué à 2.

          > On peut faire un snapshot d'un répertoire quelconque avec LVM ?

          Non et zfs non plus. D'où l'intérêt d'ext3cow aussi bien par rapport à lvm (en fait c'est dm qui le fait) que zfs.

          > Au contraire : la conception de ZFS ne plait visiblement pas à Linus

          J'ai dit que ça ne me plait pas ?
          J'ai dit zfs était moins bien que ext3+dm+device-mapper+lvm ?
          Non et non.
          J'ai dit que j'en ai marre de voir zfs comparé à un fs. Zfs ce n'est pas qu'un FS. La fonctionnalité snapshot de zfs ne fait pas parti de la partie FS de zfs.

          > les gens de SUN ont estimé que la séparation LVM/filesystem n'était plus d'actualité, et c'est tout le contraire chez Linux.

          Car Linux fait aussi xfs, reiserfs, vfat, etc... Comment tu fais dans ce cas ? Tu ajoutes de façon spécifique pour chaque FS un lvm+dm+device-mapper ?
          Sun estime que la sépration LVM/FS n'est pas d'actualité. Et alors ?
          Sur quoi c'est basé ?
          Qu'apporte de "fusionner" LVM et le FS ?
          Rien. Compare zfs et ext3+lvm+dm+device-mapper. Qu'apporte zfs que ne peut pas faire Linux car Linux sépare lvm et le fs. Rien.

          Sun estime que la séparation LVM/FS n'est pas d'actualité. Très bien eux, ils font comme ils veulent. Mais en quoi Sun a raison ? Je ne vois pas.
          En quoi Linux a raison ? Ben entre autre Linux offre du lvm/raid à tous les FS et il y a la crypto pour tous les FS (la clée usb en vfat, le disque en ext3, la partition raid5 en lvm, le swap). Je crois que zfs ne propose pas de crypto.

          > Mais un truc comme ext3cow aurait été un bon moyen d'obtenir l'une des fonctionalités intéressantes de ZFS dans ext3. Dommage :-(.

          Quelles fonctionnalités ? Snapshot ? Ben c'est dans lvm.
          Dommage pour quoi ?

          • [^] # Re: ZFS

            Posté par  . Évalué à 1.

            faire un snapshot d'un repertoire ? a proprement parlé, effectivement, on ne peut pas ... mais il faut repenser les FS sous ZFS ... par exemple, plutot que d'avoir un FS /export/home avec un repertoire par user, pourquoi ne pas avoir un pool /export/home un FS par utilisateur ? avantages multiples : compression par user, quota ou reservation par user, et les fameux snapshot (encore par user)....

            • [^] # Re: ZFS

              Posté par  . Évalué à 2.

              Comme lvm/dm...
              Sauf qu'en plus t'as des vrais quotas et pas un "not enought disk space".

  • # question

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

    Moi c'est le [user@machine] cat foo@1057845484 qui me fait tiquer.

    On est sensé se souvenir de ce nombre si on veut accéder au ficher précédant ?

    • [^] # Re: question

      Posté par  . Évalué à 7.

      $ ls fichier@
      => ça te donne toutes les versions.

      • [^] # Re: question

        Posté par  . Évalué à 1.

        rahhhhh sam'rapell' ben Clearcase*toussa!
        $ ls fichier@@

        est-ce que c'est un fs stable qui finira dans le noyau? Parce que ça m'intéresse beacoup... et une intégration dans nautilus pourrait vraiment devenir un must pour Mr toulemonde...

    • [^] # Re: question

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

      C'est surement pour aller avec IPoT.

      Si tu n'as pas encore commencé l'écriture du document de 250 pages que tu dois rendre demain, il suffit de faire un petit
      cp MonFichier.odt@1174390016 MonFichier.odt

      Et voilà, ta soirée est sauvée.
      Il faudra juste te souvenir de faire un snapshot à cet instant, sous peine de paradoxe incontrôlable. Ou alors utiliser la commande at.

      Blague à part, je suppose qu'il doit être possible de lister les snapshots qui sont présents pour un fichier.

  • # rdiff-backup

    Posté par  . Évalué à 1.

    moi je vois pas où se situe l'intérêt par rapport à un rdiff-backup à part que oui c'est 'achement joli de faire monfichier@monepoch

    en plus rdiff-backup tu peux lui dire facilement de virer les "snapshot" plus anciens qu'une date donnée et puis tu externalises facilement le backup sur un media différent (si ton disque en ext3cow pète tu pers la version courante + tous les snapshots.

    ah si, en relisant le journal, on peut utiliser les versions précédentes de façon transparente (ln -s). bon d'accord. mais je fais pas ça tous les jours et quand j'ai besoin de garder une version sous la main, je sais faire un cp

    • [^] # Re: rdiff-backup

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

      Le gros intérêt, c'est qu'un snapshot est fait de manière instantanée. Le snapshot ne coute rien en temps, et ne se met à couter vraiment en espace disque que si tu modifie des fichiers. Un atout de taille, c'est que c'est _vraiment_ instantané au sens de la cohérence des données. Si tu fais un "cp" ou un truc qui met du temps à copier, les derniers fichiers sont dans des versions plus récentes que les premiers sauvés, et il se peut par exemple que le dernier fichier sauvé fasse référence à un fichier qui n'existe pas dans le backup. Si le système sauvegardé contient une base de données par exemple, tu as de bonnes chances que la sauvegarde ne soit pas utilisable.

      Un système de snapshot, par exemple, c'est le genre de trucs agréable à avoir pour des backups à court termes, par exemple un snapshot toutes les heures.

      Maintenant, ça ne te dispense en rien pour un système où les backups sont vraiment importants d'avoir en plus un système de backups distants. Je n'ai jamais utilisé rdiff-backup, mais ça a l'air d'être une très bonne solution pour ça. Et si tu veux faire un backup cohérent, tu peux faire un backup d'un snapshot.

      Donc, c'est des outils différents, y'en a pas un « mieux » que l'autre.

      • [^] # Re: rdiff-backup

        Posté par  . Évalué à 1.

        Un atout de taille, c'est que c'est _vraiment_ instantané au sens de la cohérence des données. Si tu fais un "cp" ou un truc qui met du temps à copier, les derniers fichiers sont dans des versions plus récentes que les premiers sauvés, et il se peut par exemple que le dernier fichier sauvé fasse référence à un fichier qui n'existe pas dans le backup. Si le système sauvegardé contient une base de données par exemple, tu as de bonnes chances que la sauvegarde ne soit pas utilisable.

        Le snapshot ne te protège pas de l'incohérence du filesystem. Il te faut un agent qui met le filesystem dans un état cohérent, puis qui autorise la prise de la snapshot. Donc si t'as une DB, il te faut un agent capable de communiquer avec cette DB, la mettre dans un état propre pour un snap, puis lance le snap.
        En clair, c'est pas parce que c'est instantané que c'est cohérent.

        • [^] # Re: rdiff-backup

          Posté par  . Évalué à 2.

          > En clair, c'est pas parce que c'est instantané que c'est cohérent.

          Ce n'est pas faux.
          Mais si ce n'est pas cohérent, alors c'est codé avec les pieds. Tous les db doivent supporter une coupure de courant ou un freeze noyau. Lors d'une coupure de courant où d'un freeze noyau, on n'a bien un snapshot. Donc un snapshot marche parfaitement comme backup de base de donnée.

          Certains db vont plus loin. Voir par exemple db berkeley qui permet de faire des backups avec un "bête" cp sur une base active et idem pour postgresql. C'est-à-dire qu'on peut avoir un backup sans snapshot et aussi sans agent "special".

          • [^] # Re: rdiff-backup

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

            > Mais si ce n'est pas cohérent, alors c'est codé avec les pieds.

            Tout à fait. Un outil qui a besoin de cohérence de données, que ça soit une db, un gestionnaire de versions, ou n'importe quoi d'autre gère les transactions de manière atomique. En faisant un snapshot, tu conserve l'atomicité. En faisant un rsync ou autre, tu sauvegarde un état du disque qui n'a jamais existé, et l'outil ne peut rien pour toi.

            Ça n'empêche pas d'avoir un agent spécial, c'est une meilleur solution dans la plupart des cas. Mais un sysadmin typique ne sait pas forcément ce que font ses utilisateurs de son filesystem. Si j'ai une archive git, une archive bazaar, et une base berkleydb sur mon compte, je vais pas demander à mon sysadmin de faire 4 backups séparés, et pourtant, le jour où ça pête, je serai content si les données du backup sont cohérentes.

            • [^] # Re: rdiff-backup

              Posté par  . Évalué à 2.

              On est d'accord. Ça à moi que tu t'adressais ?

              > En faisant un snapshot, tu conserve l'atomicité.

              Hu ?!
              Le snapshot est une opération atomique. Mais le snapshot peut-être fait au milieu de ce que l'utilisateur (un client d'un sgbd par exemple) voir comme atomique. Le sgdb sait gérer ce cas (c-à-d qu'il fout toute la transaction à la poubelle ; ce qui est logique). Ce qui est atomique au niveau utilisateur peut impliquer de nombreuses actions au niveau du sgdb dont l'ensemble n'est pas atomique au niveau FS. Mais comme je l'ai déjà dit, le sgdb sait gérer ça (ou alors il est codé avec les pieds).

              Notons qu'ext3 vient à notre secours même en cas de coupure de courant. Un fsync() qui aboutit avec ext3 garantit que les données et les méta-données sont cohérents et écrit physiquement sur le disque.
              Typiquement le sgbd fait :
              - plein d'écritures, l'ordre d'écriture physique n'est pas garantit
              - fsync(). Tout est écrit sur le disk sauf l'info qui valide la transaction. Ici la transaction n'est pas validée même si elle est complète et le sgbd s'il est lancé à nouveau l'ignorera.
              - une écriture atomique pour valider la transaction (un bloque disque maximum, ce qui est largement suffisant).
              - fsync(). Celui-ci est optionnel. Ça dépend de ce que fait le sgdb après.

              Je suis convaincu de l'intérêt d'ext3cow. Dommage qu'il ne soit pas ou peu maintenu. Faute d'ext3cow, il faut faire avec lvm/dm (ce qui est un peu lourd par rapport à ext3cow qui ne demande qu'une partition (qui peut être classique/raid/lvm/loopback, qu'importe)).

          • [^] # Re: rdiff-backup

            Posté par  . Évalué à 1.

            Mais si ce n'est pas cohérent, alors c'est codé avec les pieds. Tous les db doivent supporter une coupure de courant ou un freeze noyau. Lors d'une coupure de courant où d'un freeze noyau, on n'a bien un snapshot. Donc un snapshot marche parfaitement comme backup de base de donnée.

            Avec les REDO LOG (pour Oracle) par exemple, oui tu devrais arriver à une situation cohérente. Mais le mieux est de mettre la bd en situation de hot backup le temps du snaphot. Et certaines sociétés (les banques par exemple) ne veulent pas de situation où le snapshot peut être cohérent, elles veulent que ce soit cohérent, point. Là ça passe par un agent intermédiare.

            Pour la DB berkeley, je ne connais pas. Faut que j'aille sur Wikipedia si elle est mentionnée. Mais un cp sur une base active qui permet de faire un backup, je reste dubitatif ... je demande à voir. Mais pourquoi pas ... Merci de l'info, je vais investiguer.

            • [^] # Re: rdiff-backup

              Posté par  . Évalué à 2.

              > Avec les REDO LOG (pour Oracle) par exemple, oui tu devrais arriver à une situation cohérente.

              Tous les sgdb qui font des transactions ont toujours un état cohérent sur le disque. C'est définitivement le cas pour PostgreSQL. Après d'une coupure de courant ou d'un freeze système, le sgdb ignore (nettoye) simplement les transactions en cours (tout ce qui n'a pas été validé par le retour de "commit", un retour d'instruction type "insert into ..."). Et il ne va surtout pas les refaires puisqu'elles sont imcompletes !

              Notes que c'est indispensable, sinon la base de donnée ne pourait pas redémarrer dans un état cohérent après une bête coupure de courrant.

              > Mais le mieux est de mettre la bd en situation de hot backup le temps du snaphot.

              Certe, mais ce n'est pas nécessaire avec un "vrai" snapshot.
              Ton snapshot c'est l'état de ta bd comme si le moteur de base de donnée recevait un "kill -9". Or les sgbd doivent supporter un "kill -9" (ou une coupure de courant).

              > Et certaines sociétés (les banques par exemple) ne veulent pas de situation où le snapshot peut être cohérent, elles veulent que ce soit cohérent, point.

              C'est cohérent, point.

              > Là ça passe par un agent intermédiare.

              Nécessaire si tu n'as pas un "vrai" snapshot (ext3cow ou lvm font des "vrais" snapshots).

              Autre chose, quand on parle de "rejouer un journal", on ne rejoue que les transactions validées (celles avec un commit/etc qui a aboutis ET qui est indiqué comme telle dans le journal).

              > Mais un cp sur une base active qui permet de faire un backup, je reste dubitatif ... je demande à voir.

              Postgresql le fait aussi :-)
              Ça été introduit dans PostgreSQL 8.0 je crois.

              • [^] # Re: rdiff-backup

                Posté par  . Évalué à 1.

                Nécessaire si tu n'as pas un "vrai" snapshot (ext3cow ou lvm font des "vrais" snapshots).
                Je ne sais pas si tu connais le logiciel IPStor de la société FalconStor (www.falconstor.com, virtualisation de baies de disques), il permet de faire de vrais snapshot, mais ils passent tout de même par un agent.

                Pour les DB et l'histoire du cp, je vais en causer avec nos spécialistes Oracle à ma boîte, pour avoir leur point de vue, ça peut être intéressant.

                Enrichissante la discussion ! Merci !

                • [^] # Re: rdiff-backup

                  Posté par  . Évalué à 2.

                  > Je ne sais pas si tu connais le logiciel IPStor de la société FalconStor (www.falconstor.com, virtualisation de baies de disques), il permet de faire de vrais snapshot, mais ils passent tout de même par un agent.

                  Je n'ai pas regardé falconstor. Mais il faut préciser ce qu'est un snapshot. Par exemple PostgreSQL avec pg_dump (l'agent pg_dump on peut dire) fait un "snapshot" de la base de donnée. Tu lances pg_dump a un instant t, et si durant le dump il y a des modifications de la base de donnée (ajout, suppression, etc) ben tu ne les as pas dans ton dump (idem pour les transactions "pendantes" à l'instant t). Tu as le "snapshot" à l'instant t.

                  http://www.postgresql.org/docs/8.2/static/app-pgdump.html
                  pg_dump is a utility for backing up a PostgreSQL database. It makes consistent backups even if the database is being used concurrently. pg_dump does not block other users accessing the database (readers or writers).


                  Sympa non ?
                  Je crois que ça a été introduit dans PostgreSQL version 7.

                  > je vais en causer avec nos spécialistes Oracle à ma boîte

                  Cause aussi de PostgreSQL si tu en as l'opportunité :-)

                  • [^] # Re: rdiff-backup

                    Posté par  . Évalué à 2.

                    > Je crois que ça a été introduit dans PostgreSQL version 7.

                    Finalement je me demande si ça n'a pas toujours existé...

                  • [^] # Re: rdiff-backup

                    Posté par  . Évalué à 1.

                    Mais il faut préciser ce qu'est un snapshot. Par exemple PostgreSQL avec pg_dump (l'agent pg_dump on peut dire) fait un "snapshot" de la base de donnée. Tu lances pg_dump a un instant t, et si durant le dump il y a des modifications de la base de donnée (ajout, suppression, etc) ben tu ne les as pas dans ton dump (idem pour les transactions "pendantes" à l'instant t). Tu as le "snapshot" à l'instant t.

                    Tout à fait, c'est la même définition du snapshot que j'ai, et c'est également comme ça qu'IPStor de FalconStor agit. C'est bien pour ça que je me dis qu'il peut y avoir incohérence du FS si tu "snapshotes" entre 2 I/O d'une transaction.

                • [^] # Re: rdiff-backup

                  Posté par  . Évalué à 1.

                  Salut Marmotte
                  Saurais tu où trouver de la doc sur IpStor ?
                  J'ai un NAS SS4000 de Intel avec IpStor installé dessus par contre il n'y a aucune doc dessus livré avec, FalconStor dit de demander a Intel , Intel dit de demander à FalconStor ;-)

                  Merci

  • # Time Machine?

    Posté par  . Évalué à 2.

    Est-ce que c'est censé permettre des trucs comme dans cette video ?

    http://www.apple.com/macosx/leopard/timemachine.html

    ça a l'air assez impressionnant. Mais je ne peux pas m'empécher de penser que les DD vont exploser...

    • [^] # Re: Time Machine?

      Posté par  . Évalué à 2.

      Non, je ne crois pas que ce soit la même chose. Rsync (rdiff-backup? + une surcouche pour rendre ça mignon) peut faire ce que fait apple.
      Je ne crois pas que ce que fait apple soit fait au niveau du FS.

      • [^] # Re: Time Machine?

        Posté par  . Évalué à 2.

        Je ne crois pas que ce que fait apple soit fait au niveau du FS.

        Peut-être que si, puisqu'ils sont manifestement en train d'intégrer ZFS à Leopard.

        • [^] # Re: Time Machine?

          Posté par  . Évalué à 2.

          Je ne vois pas en quoi zfs peut aider ici.

          Je me rappelle un thread sur lkml où zfs laissait les développeurs dans une assez belle indifférence.

          J'aimerai bien qu'un spécialiste fasse un article comparant zfs avec ext3-dm-lvm. Zfs serait problème bien démystifié.

          > Peut-être que si, puisqu'ils sont manifestement en train d'intégrer ZFS à Leopard.

          Il y a quoi dans Leopard d'équivalent à lvm-dm ou zfs ?
          Il me semble (mais je connais très peu Leopard) qui y a rien !
          Et comme lvm-dm ne peut être mise dans Leopard...

          Les limitations (zfs n'en manque pas) selon wikipedia :
          http://en.wikipedia.org/wiki/Zfs#Limitations
          - ZFS lacks transparent encryption ...
          - ZFS does not support per-user or per-group quotas. ...
          - Capacity expansion is somewhat limited with RAID-Z. ...
          - It is not possible to reduce the number of disks or slices in a ZFS file system, nor, in general, to remove a disk from the file system.
          - It is not possible to add a disk to a RAIDZ or RAIDZ2 volume.
          - Existing slices, whether they be mirror, raidz, or raidz2 cannot be grown by adding disks.


          Current implementation issues


          - A file "fsync" will commit to disk all pending modifications on the filesystem. That is, an "fsync" on a file will flush out all deferred (cached) operations to the filesystem (not the pool) in which the file is located. This can make some fsync() slow ...
          - ZFS filesystem on-the-fly compression/decompression is single-threaded. So, only one CPU is used.
          - ZFS eats a lot of CPU when doing small writes (for example, a single byte). ...
          - ZFS Copy-on-Write operation can degrade on-disk file layout (file fragmentation) when files are modified, decreasing performance. (NB : ce n'est pas du versionnement).
          - ZFS only offlines a faulty harddisk if it can't be open. Read/write errors or slow/timeouted operations are not currently used in the faulty/spare logic.


          Alors, toujours aussi sexy zfs ?

          • [^] # Re: Time Machine?

            Posté par  . Évalué à 2.

            J'aimerai bien qu'un spécialiste fasse un article comparant zfs avec ext3-dm-lvm.


            Je ne vais pas faire un article mais une brève intervention.

            ext3-dm-lvm fonctionne sous :
            - Linux

            ZFS fonctionne sous :
            - Solaris
            - Linux
            - FreeBSD
            - Mac OS X

            D'accord, c'est encore de la beta pour tous sauf Solaris, mais quand même !

            Donc pour moi le choix est rapide, avant j'utilisais lvm + ext3, j'étais coincé sous Linux. Maintenant c'est ZFS.

            Sinon, les problèmes de performance pourront être corrigé dans des versions futurs. ext3 n'était sûrement pas optimum lors de sa sortie mais au fur et à mesure des améliorations, il est probablement devenu un des FS les plus rapide pour Linux.

            • [^] # Re: Time Machine?

              Posté par  . Évalué à 2.

              zfs peut fonctionner sous Linux mais il ne peut pas être diffusé avec Linux. GPL oblige, pour le plus grand bien des droits de l'utilisateurs et leurs pérennités.

              • [^] # Re: Time Machine?

                Posté par  . Évalué à 2.

                Là on change de problème, ce n'est plus technique mais philosophique.

                De plus, il se pourrait que le code de ZFS passe un jour en GPLv3 comme l'ensemble du noyau OpenSolaris. Mais bon, j'en conviens, ce ne sont que des rumeurs.

                • [^] # Re: Time Machine?

                  Posté par  . Évalué à 1.

                  Même dans ce cas, il faudrait que le noyau linux passe lui aussi en GPLv3, ce qui n'est pas certain :/

                • [^] # Re: Time Machine?

                  Posté par  . Évalué à 2.

                  > il se pourrait que le code de ZFS passe un jour en GPLv3

                  Au moins dans ce cas j'aurai moins l'impression que Sun a choisi une licence pour faire "chier" le libre comme ça me semble le cas avec la CDDL.
                  Après on pourra dire que la balle est dans le camp de Linux :-)

                  Je ne suis pas d'humeur à critiquer Sun (alors que je l'étais avec OpenSolaris sous CDDL) depuis que Sun a mis Java en GPL. C'est une contribution gigantesque au libre. Vivement que Java soit dans les faits libre (vers mi 2007).

                  • [^] # Re: Time Machine?

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

                    > Après on pourra dire que la balle est dans le camp de Linux :-)

                    En fait, ça a toujours été le cas. Si tu fais un mélange de code CDDL et GPL, tu violes la GPL, mais pas la CDDL. C'est un peu paradoxale, mais en un sens assez bien vu de la part de SUN (oui, ça fait chier, mais en même temps, je voyais mal SUN filler tout son code à Linux, commercialement, ça serait un peu se tirer une balle dans le pied).

                    • [^] # Re: Time Machine?

                      Posté par  . Évalué à 2.

                      > En fait, ça a toujours été le cas. Si tu fais un mélange de code CDDL et GPL, tu violes la GPL, mais pas la CDDL.

                      Tu violes aussi la CDDL. La GPL interdit un droit (pour l'intérêt de l'utilisateur) que donne la CDDL.

                      Tu peux donner les droits de la GPL à la CDDL ? Non. La GPL impose qu'il n'y ait pas de taxe sur les brevets. C'est un droit que te donne la GPL. T'es sûr quand on te donne un programme sous GPL que tu ne vas pas payer de taxe. Mais la CDDL ce n'est pas le cas.
                      Tu peux donner les droits de la CDDL à la GPL ? Non. La CDDL permet de mettre des brevets dans le code, de distribuer le code (ici la GPL l'interdit), de demandé à être payé pour les brevets. C'est un "droit" que donne la CDDL (et uniquement à Sun je crois).

                      T'as un propos FUDien à la MS.
                      C'est FUDien car ça ne considère le problème que dans un sens. MS a utilisé ce type de raisonnement pour "démontrer" l'aspect "contaminant" de la GPL (qui n'a jamais rien contaminé, malheureusement).

                      GPL et CDDL sont incompatibles, ça va dans les deux sens.
                      Sun a communiqué de façon FUDienne, merci de ne pas reprendre le FUD de Sun.

                      Quand A est incompatible avec B, B est incompatible avec A.

                      • [^] # Re: Time Machine?

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

                        > Tu violes aussi la CDDL.

                        Cites-moi la clause de la CDDL que je viole, par exemple, en distribuant Linux et ZFS ensembles sous leurs licences respectives.

                        Le problème de la compatibilité est assez bien « expliqué » dans la FAQ :

                        http://www.opensolaris.org/os/about/faq/licensing_faq/#other(...)

                        (bon, en fait, ils se foutent de la gueule de la GPL, mais sans le dire ;-) ).

                        C'est là qu'ils ont joué assez fin : le but est quand même visiblement d'être incompatible GPL, mais ils utilisent une clause de la GPL elle-même pour le faire.

                        > Tu peux donner les droits de la GPL à la CDDL ? Non.

                        Bien sur que non. Mais « violer » une licence, ça n'est pas ça. Violer une licence, c'est faire un truc qui n'est pas autorisé par la licence.

                        Si tu met du code CDDL et GPL dans le même soft, tu violes la GPL, car la GPL t'interdit de distribuer l'ensemble sous une licence autre que la GPL. L'auteur du code GPL peut t'attaquer en justice si tu le distribues. Par contre, ton logiciel ne viole pas la CDDL : l'auteur du code CDDL ne peut pas t'attaquer.

                        Maintenant, si tu prend un bout de code CDDL et que tu le distribue sous GPL, là, tu violes la CDDL, tu fais un truc qu'elle ne t'autorise pas. Mais ça n'est pas la question, Linux pourrait très bien prende un bout de code CDDL, le mettre dans Linux sans changer la licence de ce bout de code.


                        Je termine par une question : tu disais qu'avec la GPLv3, la balle serait dans le camp de Linux. Tu peux nous expliquer en quoi ça serait différent ?

Suivre le flux des commentaires

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