Journal Zfs sous linux

Posté par  .
Étiquettes : aucune
0
14
jan.
2007
Le 26 décembre, Ricardo Correia annoncait sur son blog [1] la sortie d'une alpha de zfs sous fuse.
Force est de constater que c'est assez prometteur :

La compilation est aisé il suffit de :
- avoir un noyau avec le support de fuse
- récupérer les sources [2]
- installer fuse-utils, les librairies de développement de fuse, et scons.
- aller dans le répertoire des source et tapé scons puis su -c 'scons install' .
Et voila c'est fait.

Ensuite pour se servir de zfs il suffit d'aller dans le répertoire zfs-fuse (qui est dans le répertoire des sources) et de lancer ./run.sh
Il ne faut pas oublié de mettre fuse dans le noyau si on l'a compilé en module : modprobe fuse

et voila on peut utiliser les commandes de zfs.

Si on ne veut pas abimer ses dd, on peut le tester sur des fichiers (15 petit disques dur pour tester ;) ):

for i in `seq 1 15`; do dd if=/dev/zero of=/zfs/zfs0 bs=1M count=128; done


l'avantage de zfs est de gérer les disques dur directement. Pas besoin d'avoir un lvm et ou de gérer le raid à coté.
On peut créer un pool de stockage de façon extremement simplement, y compris en se basant sur du raidz2 (comme du raid5 mais avec 2 disques de redondances, et pas le write hole du raid5 qui obligeait à utiliser de la nvram).
zpool create test raidz2 /zfs/zfs{1,2,3,4,5}
(il faut donner le chemin complet, sinon il cherche dans /dev je crois )
et on peut observer que tout est bien pris en compte avec un zpool list . On voit que le pool de stockage test a bien été crée. (La taille indiqué est la taille physique et ne tient pas compte de la redondance crée par le raidz2. Voir plus loin comment l'avoir ;) )
si plus tard on veut rajouter des disques dur on peut faire
zpool add test raidz2 /zfs/zfs{6,7,8,9,10}
et comme on est prévoyant, on décide de mettre 5 disques en spare pour le pool de stockage :
zpool add test spare /zfs/zfs{11,12,13,14,15}

on regarde ce qui est disponible avec un petit zpool status
on peut créer plusieurs files systems dans ce pool (il faut voir qu'il est aussi simple de faire un fs qu'un répertoire avec zfs. Ils sont un peu plus difficile a gérer en ce qui concerne le renommage (il faut passer par zfs) mais permettent d'attribuer la réservation, quota, snapshot etc... facilement)
Supposons qu'on ai deux utilisateur : miu et shigure (private joke)
donc on peut créer leurs répertoires utilisateurs :

zfs create test/users
zfs create test/users/miu
zfs create test/users/shigure


zfs list permet de savoir si les fs sont bien monté, leurs statut etc...
A noter , supposons que j'avais déjà fait zfs test/users mais que je l'ai démonté (avec zfs umount ) , lorsque je crée le home de miu, zfs va me monter automatiquement users pour pouvoir créer et monter miu.

Bien entendu on peut ajouter quelques caractéristiques aux différents fs

zfs set compression=on test/users #active la compression
zfs set checksum=on test/users #active les sommes de controles
zfs quota=60M test/users/shigure
zfs quota=120M test/users
zfs list

On constate qu'il ne change pas la taille disponible. Mais si je fais:

zfs reservation=60M test/users/miu
zfs list

La il prend bien en compte la reservation.

Faire un snapshot est aussi très aisé :

zfs snapshot test/users/miu@snap1

voila c'est fait !

récupérer d'un snapshot est aussi très simple : il suffit d'utiliser la commande rollback zfs rollback test/users/miu@snap1

Bon on vois que l'administration d'un tel système est pas franchement compliqué. Et que tout est centralisé en deux commande (plus d'options sont disponibles avec zfs help ou zpool help , ou simplement regarder la documentation [3])

Maintenant supposons que l'on ai écris quelquechose sur une partition , et qu'un problème disque survienne ... par exemple :

shred /zfs/zfs4

un premier zpool status ne détecte rien (pas de lecture sur le disque).
Mais si on essaie de lire par exemple find test -type f alors, bien que les données soient toujours correct , un zpool status nous informe des problèmes (et de quel type de problème ), ainsi que le mode de fonctionnement (online , dégradé, unavailable, ...).
On peut bien entendu utiliser les spares avec un simple zpool replace test /zfs/zfs4 /zfs/zfs11 . Il s'occupe de tout .
Après que le resilver soit bien fait, un zpool offline -t test/zfs/zfs4
ensuite (je suis même pas sur qu'on ai besoin de mettre offline si le disque est marqué unavail) on peut changer le disque dur (refaire un dd zero sur /zfs/zfs4) .
puis un

zpool online test /zfs/zfs4
zpool detach test /zfs/zfs11

permet de remettre le disque spare dans l'ensemble de disque de spare, et de conserver zfs4. (note , j'avais des problèmes de checksum après cela, mais normalement après un changement de dd , zfs le remarque et agis en conséquence. C'est peut etre que je me suis trompé , ou alors qu'il a des problèmes avec les fichiers à la place des dd. Pour réparé ce problème un simple zpool scrub test permet de tout resynchroniser)

Si bien entendu on souhaite conserver le spare dans le nouveau raidz2 et ne plus entendre parlé de /zfs/zfs4 on peut faire zpool detach test /zfs/zfs4
Il enlevera /zfs/zfs11 de l'ensemble de spare pour qu'il reste tout le temps dans le raidz2 ayant des problème

enfin une fois que tout est fait un petit zpool clear test permet de supprimer les erreurs .

Il y a un guide d'adminitration bien fait pour zfs en [3].

Ce que j'en ai pensé , bien que je n'ai pas vraiment pu testé les performance, j'ai trouvé
- ce projet est vraiment bien avancé, bien que certains bugs subsistent (on ne peut pas lancé un executable sous fuse ou quelquechose comme ca) , le code , lors de mon test, était très stable, bien plus que le code de 'pre release' de certains projets.
- le fait de pouvoir ajouté du raidz,du raidz2 , des miroir (raid1) , ou de simple disque au même pool (en gros de faire un raid0 par dessus) , et ce de facon dynamique m'a bien plus (je n'ai jamais toutefois touché au raid , donc ce n'est pas du tout pour comparer avec les solution actuelles)
- l'intuitivité des commandes : les deux commandes utilisé sont bien pensé. L'aide est facilement accessible (zpool help , zfs help. voir par exemple pour rajouter des caractéristiques : zfs set help etc... ) , et la doc sur le site de sun [3] bien faite aussi je trouve.

Bref, amha, c'est quelquechose a suivre ;)


[1] http://zfs-on-fuse.blogspot.com/
[2] http://developer.berlios.de/project/showfiles.php?group_id=6(...)
[3] http://opensolaris.org/os/community/zfs/docs/

  • # perf

    Posté par  . Évalué à 2.

    Et niveau perf ca donne quoi ?

    Parce que avec fuse on est obligé de faire des aller retour user/kernel : user (appli qui veut ecrire) -> kernel (fuse) -> user (fs fuse) -> kernel (operation sur le support physique).

    • [^] # Re: perf

      Posté par  . Évalué à 7.

      Je cite : Performance sucks right now, but should improve before 0.4.0 final, when a multi-threaded event loop and kernel caching support are working (both of these should be easy to implement, FUSE provides the kernel caching).
      Traduction approximative :
      Les performances sont lamentables actuellement, mais devraient s'améliorer avant la version 0.4.0 finale, quand une boucle d'évènements multi-threads et le support du cache seront fonctionnels (ils devraient être simples à implémenter, FUSE fournissant le cache)

    • [^] # Re: perf

      Posté par  . Évalué à 3.

      j'ai pas testé car j'ai pas de dd libre. J'ai testé sur des fichiers la.
      Mais je pense que le commentaire au dessus de moi à raison ;)

      Il y a quelques benchs de fait avec l'utilisation de fuse si ca t'intéresse:

      http://www.csamuel.org/2006/12/30/zfs-on-linux-works/

      http://www.csamuel.org/2007/01/01/zfs-disk-mirroring-stripin(...)

      ;)

      • [^] # Re: perf

        Posté par  . Évalué à 3.

        on parle des performances là, mais au niveau robustesse, est-ce que c'est bon ?
        Je présume que zfs sur solaris, cela doit être au top, en plus que c'est sans doute parfaitement intégré.
        Là c'est en dehors du noyau, est-ce que cela ne risque pas d'être moins fiable (sous entendu, parce que cela ajoute une couche d'abstraction supplémentaire) ? Est-ce qu'à terme c'est prévu d'être dans le noyau ?
        Car vu ce que cela gère, c'est plutôt ultra critique et pointu comme utilisation...

        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: perf

          Posté par  . Évalué à 6.

          au fait, je n'ai pas pensé à dire : félicitation pour ce journal très complet !

          Et également une autre question, est-ce qu'à terme il serait envisageable d'utiliser zfs en système de fichiers principal, comme sous solaris ? Car si cela arrive dans bsd, linux, et macosx, cela permettrait de pouvoir travailler plus facilement sur des partitions issues d'OS différents (sur une même machine bien entendu)

          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: perf

            Posté par  . Évalué à 4.

            au fait, je n'ai pas pensé à dire : félicitation pour ce journal très complet !

            Merci beaucoup :)


            est-ce qu'à terme il serait envisageable d'utiliser zfs en système de fichiers principal, comme sous solaris ?
            Actuellement zfs n'est pas utilisable en tant que fs principal , en tout cas pour le boot, car grub ne peut pas encore lire de partition zfs.
            En plus tant qu'il sera en fuse , je ne crois pas qu'on ne pourras l'utiliser réelement en tant que partition principale.
            Mais il est sans doute possible d'avoir une partition / minimaliste qui sert juste à lancé init , le daemon zfs , et ensuite à monter la véritable partition. Enfin on y est pas encore ;)

            En tout cas pour l'instant :
            le portage sur bsd est en cours de meme que celui de linux ;).
            Macos le portage semble etre déja fait :
            http://loop.worldofapple.com/archives/2006/12/17/zfs-file-sy(...)
            solaris ... ben on sait déja :D

            Sans oublier que le chiffrement du fs est en cours, et une version HA devrait peut etre voir le jour (la version HA devrait permettre d'utiliser , à ce que j'en ai compris, plusieurs ordinateur sur les memes disques dur (un SAN , et plusieurs NAS raccordé au SAN pour équilibrer la charge) ).

            • [^] # Re: perf

              Posté par  . Évalué à 3.

              > Actuellement zfs n'est pas utilisable en tant que fs principal , en tout cas pour le boot, car grub ne peut pas encore lire de partition zfs.

              J'ai entendu dire que même sous Solaris, on ne pouvait pas booter sur ZFS, et qu'il avait donc besoin d'un /boot dans un autre système de fichiers. Ce qui ne pose pas vraiment de problème, en fait : mon répertoire /boot est toujours sur une petite partition en ext2,ro, elle n'a pas besoin d'être protégée comme le reste du système, et c'est facile à restaurer en cas de problème.

        • [^] # Re: perf

          Posté par  . Évalué à 2.

          Pour la fiabilité intrinsèque :
          zfs permet de faire du checksum sur chaque stripe, cad que meme les modifications , jusqu'à présent silencieuse, peuvent être détecté.
          (c'est partis du constat qu'on utilisait des mémoires ECC mais pas de fs ECC ;))

          Par rapport au rajout d'une couche, je ne pense pas que ce soit intrinsèquement moins sur (mais je ne suis pas un expert non plus ;))

          Quand à l'inclusion dans le noyau, je ne pense pas qu'elle arrivera de sitot, en tout cas pas tant que le code est sous CDDL et pas gplv2.

          • [^] # Re: perf

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

            > (c'est partis du constat qu'on utilisait des mémoires ECC mais pas de fs ECC ;))

            Pas vraiment je crois.

            Les disque durs ont depuis longtemps des codes de correction d'erreur en hardware, mais le constat de départ de ZFS, c'est plutôt que ces checksums n'étaient pas suffisants, et qu'il fallait que l'OS y mette aussi son grain de sel.

            • [^] # Re: perf

              Posté par  . Évalué à 2.

              ils ont des codes correcteurs d'erreur ... sur les données dans les disques ???
              c'est la première fois que j'entend ca (mais j'ai jamais dis que je savais tout ;) )
              (le fameux coup du rayon cosmique qui touche le plateau et transforme un 1 en 0 il marche plus ?
              )
              En tout cas dans une de leurs présentations ils font clairement le parallèle :

              No defense against silent data corruption
              Any defect in disk, controller, cable, driver, or firmware can

              corrupt data silently; like running a server without ECC memory

              • [^] # Re: perf

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

                En fait le problème est simple.

                Ton disque dur est stupide...

                Il peux faire trois choses :
                - se planter de positionnement de la tête => corruption collatérale
                - écrire n'importe comment (coupure de courant, etc) => corruption
                - avoir des soucis de surface => perte de donnée (puisque le secteur sera seulement repositionné)

                Dans les deux premiers cas le disque dur sera incapable de récupérer les données perdues, il faut donc que quelqu'un se charge de rattraper sa connerie...
                Dans le troisième cas le disque dur y peux pas grand chose, il peux juste repositionner le secteur défectueux...

                Bref, le but de ZFS est de partir du principe que la corruption arrivera pas forcément en même temps, et qu'avec un pool de disque dur tu limite les risque
                (bien que tu sois soumis au paradoxe des anniversaires et que les chances d'avoir deux problème sont tout de même grande)

                L'intérêt que je vois dans ce système serait d'agglomérer tes disque dur en raid5 de manière transparente avec tes spares et compagnie.
                La seule différence par rapport a maintenant est que tu ne te prend plus la tête avec les agrandissement de système de fichiers et réduction de ces derniers vu que ZFS te rend ceci bien facile.
                (genre tu est samedi matin, tu a plus de spare, une application critique a pas perdre, tu a la place d'au moins un des disque dans le système de fichier, hop tu retire le disque en question de l'espace dispo et tu le met en spare ;)

                Bon l'intérêt serait que le système de fichier devienne natif, parce que bon un tel système de fichier non natif a un intérêt proche de zero
                (vu que tu va toujours devoir te taper une chaîne de chargement qui ne sera pas protégée par ton raid5/ZFS ou similaire ???raidz2???)

              • [^] # Re: perf

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

                > ils ont des codes correcteurs d'erreur ... sur les données dans les disques ???

                Je ne suis pas absoluement sur de moi, mais il me semble bien que oui. Mais ça ne te protège que contre un nombre limité d'erreur, et en particulier pas celles dues au contrôleur.

  • # Circonspect

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

    Franchement, ZFS je sais pas trop si c'est propre : j'ai l'impression qu'ils lient beaucoup trop de fonctionalité dans le système de fichier... c'est bien quand on veut n'en supporter qu'un mais sinon c'est de la duplication de code.

    D'autant plus qu'il viennent avec leur outil spécifique (zpool) qui sert à en administrer les fonctionalités, incluant par exemple le RAID et des systèmes complexes de sauvegarde.
    Ça peut avoir l'air sympa, mais j'imagine mal la galère avec un utilitaire pour gérer le RAID de reiserfs qui serait diffèrent de celui de ext3.

    Et par dessus ça y'a des trucs genre
    Automatically NFS-export all home directories
    # zfs set sharenfs=rw tank/home
    qui risquent encore d'être très laids (si par exemple le système de fichier intègre un lien particulier avec NFS seulement, quid des autres ?).

    Mon impression c'est qu'on dirait vraiment du "quick and dirty", lourd à maintenir et adapté seulement au taches les plus courantes. Ceci dit j'ai pas encore zieuté le code, donc ça se trouve je me trompe du tout au tout.

    • [^] # Re: Circonspect

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

      http://blogs.sun.com/bonwick/entry/zfs_end_to_end_data
      http://www.reed.com/Papers/EndtoEnd.html
      The principle, called the end-to-end argument, suggests that functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: Circonspect

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

        Quand même, lvm c'est un gros morceau, le dupliquer dans chaque système de fichier aurais un coût réel... Mais au moins ça explique les raisons du choix, et c'est vrai qu'il est logique si on n'a et ne veut qu'un FS. Je me coucherais moins bête :-)

    • [^] # Re: Circonspect

      Posté par  . Évalué à 3.

      initialement zfs était prévu pour solaris, donc ils ont fait un truc qui correspondait à leurs besoin, en mettant tout a plat (il le dise dans leur présentation).

      Ça peut avoir l'air sympa, mais j'imagine mal la galère avec un utilitaire pour gérer le RAID de reiserfs qui serait diffèrent de celui de ext3.
      C'est que tu vois le raid comme une sous couche au fs, alors que eux ils voient,amha, le raid et le fs comme un ensemble.
      C'est une autre facon de penser, et la c'est le fs qui gere l'ensemble des disques, pas la sous couche 'raid' .

      Sans compter que tu n'as aucun support du raidz ou raidz2 dans un quelconque noyau sans passer par zpool ;)


      Le but c'est de proposer un ensemble cohérent ET portable (essaye de transférer tes dd en raid d'un amd vers un sparc (endianess différente) , je suis pas du tout sur que ca marche 'facilement'.
      alors que sous zfs tu fait 'zpool export test' sur ton amd. Tu bouge physique tes dd, puis tu tape 'zpool import test' et voila tu les a (en théorie tout du moins vu que j'ai pas testé ;))


      ensuite rien ne t'empeche de faire un raid linux, et de faire un pool sur ton /dev/md0 si tu veux ,)



      (si par exemple le système de fichier intègre un lien particulier avec NFS seulement, quid des autres ?).

      Pas compris la.
      en gros si /test/users est exporté, est ce que /test/users/miu est exporté aussi ?
      le manpage de zfs donne la réponse (ou meme un simple zfs set help : le flag INHERIT est à YES)
      'When the “sharenfs” property is changed for a dataset, the dataset and any children inheriting the property are re-shared with the new options, only if the property was previously “off”, or if they were shared before the property was changed. If the new property is “off”, the file systems are unshared.'
      donc tous les enfants sont exporté, toutefois tu peux tres bien faire :
      zfs set sharenfs=on test/users
      zfs set sharenfs=off test/shigure
      et on obtient

      zfs get sharenfs
      NAME PROPERTY VALUE SOURCE
      test sharenfs off default
      test/users sharenfs on local
      test/users/miu sharenfs on inherited from test/users
      test/users/shigure sharenfs off local


      Encore une fois, rien ne t'oblige à utiliser ca. tu peux tres bien les exporter normalement (et sur mon ordi l'export ne marche pas car visiblement j'ai pas share, qui dois etre pour l'instant sous solaris seulement ;))


      Mon impression c'est qu'on dirait vraiment du "quick and dirty", lourd à maintenir et adapté seulement au taches les plus courantes.
      Tu peux me donner comment faire simplement un snapshot avec un ext3 sans faire une copie bete et méchante ?
      ou encore un clone (cad avec du COW) ?

      ext3 est basé sur l'ext2 , qui lui est un fs qui a été fait il y a fort longtemps.
      Il est très bien, mais ce n'est pas parce que quelqu'un pense différement de ce qui est 'habituelle' que c'est forcément du quick & dirty.
      Sans compter que ne pas avoir le write hole du raid5 n'est pas quelquechose qui se fait en 'claquant des doigts' ni le fait de faire des transaction atomique.

      Je te conseille juste de tester (ca demande une recompilation de noyau si il y a pas fuse, et un peu d'espace disque pour créer des fichiers. On a pas besoin de disques dur supplémentaires pour tester ;))
      D'essayer de faire tes tache d'administration 'non courantes' , et voir si c'est compliqué ou pas, et si oui, si c'est plus compliqué que par rapport aux solutions existantes.
      (Encore une fois , une solution qui fait un snapshot en 1/2 seconde d'un dd ext3, j'en cherche)

      • [^] # Re: Circonspect

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

        C'est que tu vois le raid comme une sous couche au fs, alors que eux ils voient,amha, le raid et le fs comme un ensemble.
        Non, je ne vois pas le raid comme une sous couche du FS, je le voit comme un composant suceptible d'être partagé entre plusieurs FS et qui en tant que tel doit être maintenu séparement.
        Ça évite d'avoir le code raid de reiserfs, le code raid de ext2, le code raid de xfs... avec des interfaces et des bugs diffèrents.

        C'est une autre facon de penser, et la c'est le fs qui gere l'ensemble des disques, pas la sous couche 'raid' .
        Le FS qui gère les disques... aucun commentaire.

        Tu peux me donner comment faire simplement un snapshot avec un ext3 sans faire une copie bete et méchante ?
        ou encore un clone (cad avec du COW) ?
        Je ne critique pas les fonctionalités, ni l'interface mais le design.
        Ceci dit, ça se fait avec respectivement TONFS_copy et lvm me dit Google.

        Le but c'est de proposer un ensemble cohérent ET portable (essaye de transférer tes dd en raid d'un amd vers un sparc (endianess différente)
        Ça ne pose aucun problème. Comme monter la même paritition en x86 et x86_64 .
        Et quand bien même, c'est pas la question.

        (si par exemple le système de fichier intègre un lien particulier avec NFS seulement, quid des autres ?).

        Pas compris la.
        en gros si /test/users est exporté, est ce que /test/users/miu est exporté aussi ?
        Non.
        Ce que je me demande, c'est dans quelle mesure leur implémentation de ZFS est lié à celle de NFS. Dans l'optique de pouvoir factoriser le code lié à NFS, ou de choisir Codafs à la place sans que ça détone trop.

        Il est très bien, mais ce n'est pas parce que quelqu'un pense différement de ce qui est 'habituelle' que c'est forcément du quick & dirty.
        Je n'ai pas évoqué la différence avec les extN (que je n'aime pas).
        Ce que je trouve quick and dirty, c'est d'avoir le code raid de reiserfs, le code raid de ext2, le code raid de xfs... avec des interfaces et des bugs diffèrents.

        Je te conseille juste de tester (ca demande une recompilation de noyau si il y a pas fuse, et un peu d'espace disque pour créer des fichiers. On a pas besoin de disques dur supplémentaires pour tester ;))
        D'essayer de faire tes tache d'administration 'non courantes' , et voir si c'est compliqué ou pas, et si oui, si c'est plus compliqué que par rapport aux solutions existantes.
        Ce qui montre que tu ne comprend pas la nature de ma critique.

        (Encore une fois , une solution qui fait un snapshot en 1/2 seconde d'un dd ext3, j'en cherche)
        Je doit dire que je me demande ce qui rend inacceptable un délai un peu plus long, mais ça ne m'intéresse pas vraiment en fait. Sauf si tu parvient à montrer que c'est lié à la décision dupliquer les fonctionalité du LVM.

        Raidz serais un bien meilleur exemple, mais il doit être possible de l'implémenter diffèrement ou au moins de ne dupliquer que ça.

        • [^] # Re: Circonspect

          Posté par  . Évalué à 0.

          Le FS qui gère les disques... aucun commentaire.
          initialement ca servait bien à ca pourtant.
          FS = file system , système de fichier.
          Il s'occupe donc de placer les fichier comme il le faut sur le disque, et le retrouve sur le disque avec sa structure interne.

          Il peut éclater un fichier en des tas de petit morceau et les dispersé sur le disque si ca l'amuse (couramment nommé sous le terme de fragmentation).
          La il fait exactement ca : il le place sur le ou LES disques.
          Il éclate le fichier en petit morceau qu'il met sur un ou plusieurs disques.

          La véritable question est 'pourquoi rajouté une surcouche au fs quand le fs est capable de gérer ca tout seul comme un grand' ? pour faire comme nos grand pères ?

          Ceci dit, ça se fait avec respectivement TONFS_copy et lvm me dit Google.
          Ceci dit , comprendre le commentaire auxquel on répond à fond serait intéressant.
          (surtout quand j'ai dis 'pas avec une copie bete et méchante').
          COW = Copy On Write.
          Un exemple extrement simple de comprendre serait de prendre une image systeme.
          Je fais un clone pour mes 50 machines (un systeme ltsp par exemple).
          A partir de ce clone, ils peuvent donc configurer chacun leur machine comme ils veulent ... mais tant qu'ils ne modifient pas un fichier qui était dans le master, ca ne prend pas de place sur le dd.
          Ton copie te fait prendre toute la place dans le DD quand bien meme seulement 1% serait changé !

          Donc ca ne se fait PAS avec TONFS_copy justement.


          Comme monter la même paritition en x86 et x86_64 .
          Euhh comment dire ...
          x86 et x86_64 c'est du little endian.
          sparc c'est du big endian, amd c'est du little endian.
          donc peut etre que ca pose aucun probleme, mais c'est certainement pas comme x86 et x86_64.


          Ce que je trouve quick and dirty, c'est d'avoir le code raid de reiserfs, le code raid de ext2, le code raid de xfs... avec des interfaces et des bugs diffèrents.
          Tu n'as pas le code raid de ext2 toussa pour une raison bien simple ... ils ne gere pas ce que gere zfs.
          Zfs gere les io, fait des transaction atomiques, etc...

          En outre tu as du code raid dans zfs ... mais pas le raid que tu as dans le noyau Linux ! Ils font comment, ils demandent à la grandeur des dvp linux 'dites on fait un solaris, on utilise raidz2 , mais comme vous vous faites vos trucs différement, et qu'on est un peu maso, alors on a décidé de suivre votre exemple meme si ca apporte STRICTEMENT RIEN pour nous' ?
          il ne faut pas oublié que zfs est prévu initialement pour solaris , PAS pour Linux ni pour hurd!


          Je doit dire que je me demande ce qui rend inacceptable un délai un peu plus long, .
          Le fait que la transaction DOIT etre atomique pour etre cohérente, et que si tu bloque ton fs plus d'une seconde, tu vas commencer à entendre tous tes services faire la gueule pe ?

          mais ça ne m'intéresse pas vraiment en fait.
          Donc tu rale pour raler en gros ?
          Tu rale, et quand on essaie de te répondre (meme si je ne suis pas un expert en zfs, loin de la. Je l'ai touché la première fois ... jeudi soir ! ) en disant que zfs propose tel et tel fonctionnalité, tu dis que tu t'en fous.

          Alors dis moi qu'est ce qui t'intéresse a part le troll éculé (je sais j'en ai fais partie un moment) qui est 'jusqu'a présent on faisait le raid de cette manière. C'est donc forcément nous qui avons raison. Et surtout n'essayons pas de voir ce qui est bien chez les autres'.

          Par exemple dans un zpool , je rajoute 2 disques, je fais mon
          zpool add test mirror /dev/sdh /dev/sdz
          et hop je peux TOUT DE SUITE utilisé l'espace en plus, j'ai pas de synchro à faire ni rien, et je suis donc en raid 0+{z,z2,1,disque seul} la!
          ton raid le permet ca sans probleme ?

          Ce projet est pas encore stable sous linux, donc ne t'inquiète ps , tu pourras continuer à t'amuser avec tes md0.



          Quand à la factorisation de code différents.
          Tu demande de n'utiliser que motif sous pretexte que motif , gtk et qt ca fait la meme chose ?

          • [^] # Re: Circonspect

            Posté par  . Évalué à 5.

            La véritable question est 'pourquoi rajouté une surcouche au fs quand le fs est capable de gérer ca tout seul comme un grand' ? pour faire comme nos grand pères ?
            Ben oui apres rajouter la gestion du RAID dans les disque, je propose de rajouter la gestion des disques (PATA, SATA, SCSI, USB, SD, CF, ...) dedans.
            C'est telement mieux de faire un gros bousin monolithique que de penser une architecture modulaire qui peux beneficier a tout le monde.

            On se demande vraiement pourquoi un OS comme Linux qui tend a modulariser un max a tant de succes...

            • [^] # Re: Circonspect

              Posté par  . Évalué à 6.

              On se demande vraiement pourquoi un OS comme Linux qui tend a modulariser un max a tant de succes...

              Tu cherches à déterminer le pourcentage de hurdistes parmi les habitués de DLFP?

            • [^] # Re: Circonspect

              Posté par  . Évalué à 0.

              je te propose de regarder la présentation de zfs
              http://opensolaris.org/os/community/zfs/docs/zfs_last.pdf

              ils expliquent tous mieux que moi , avec de zoli diagramme.

              Encore une fois je ne suis PAS un expert en zfs.
              mais désolé , le placement des donnée sur un disque, c'est du ressort du fs a ce que je sache.
              Rien a voir avec la gestion du pata ou sata.
              Et le raid il fait quoi ... il place des donnée sur un disque virtuel(constitué d'un ensemble de disque) .... il fait donc le boulot d'un fs aussi.

              C'est telement mieux de faire un gros bousin monolithique que de penser une architecture modulaire qui peux beneficier a tout le monde.
              ahem ... les drivers pour etre maintenu, ils doivent etre dans un gros bousin monolithique ou au contraire on peut maintenir notre driver dans notre coin sans qu'au grand jamais il ne casse quand les autres évolue... Parce que la je crois que je me souviens plus trop de comment marche linux hein ...

              • [^] # Re: Circonspect

                Posté par  . Évalué à 3.

                mais désolé , le placement des donnée sur un disque, c'est du ressort du fs a ce que je sache.
                Rien a voir avec la gestion du pata ou sata.
                ... il place des donnée sur un disque virtuel
                Donc le fs place les données sur espace de donnée virtuel pas un disque.
                Au passage sur certaines techno (memoire usb), acces au disque physique n'est pas possible puisqu'un controlleur (ou des couches d'abstractions) se charge de faire un mapping block virtuel <-> bloque physique.

                C'est meme le cas sur les disque ATA actuel avec la gestion des secteurs defectueux.


                ahem ... les drivers pour etre maintenu, ils doivent etre dans un gros bousin monolithique ou au contraire on peut maintenir notre driver dans notre coin sans qu'au grand jamais il ne casse quand les autres évolue... Parce que la je crois que je me souviens plus trop de comment marche linux hein ...
                Si tu lissais la fin de la phrase tu verrais le mot magique : modulaire...

                PS : j'ai rien contre zfs, j'ai seulement l'impression qu'il n'a ete développé dans une optique propriétaire : on implémente tout en ne pensant qu'a nous, on se fiche de faire un truc modulaire pour que certaines briques puisse servir a d'autres (ou etre plus maintenable). Bon après j'ai pas lu leur docs et je me basse que sur les commentaires que j'ai pu lire.

                • [^] # Re: Circonspect

                  Posté par  . Évalué à 3.

                  Le portage sur FreeBSD est plus modulaire. Il est possible de mettre le système de fichiers UFS sur le gestionnaire de volumes ZFS :
                  It's integrated with FreeBSD's existing features like UFS and GEOM, thus offering the possibility of creating FreeBSD UFS file systems on ZFS volumes, and using GEOM providers to host ZFS file systems.

                  ( http://ivoras.sharanet.org/freebsd/freebsd7.html )

                  Donc je pense que cet aspect modulaire existe...

        • [^] # Re: Circonspect

          Posté par  . Évalué à 0.

          ZFS n'est pas qu'un file system, c'est assez bien résumé ici:

          ZFS is an advanced file system (actually, a combination of file system and volume manager) with many interesting features built-in: snapshots, copy-on-write, dynamic striping and RAID5, up to 128-bit file system size.

          http://ivoras.sharanet.org/freebsd/freebsd7.html

          • [^] # Re: Circonspect

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

            Enfin moi, je ne veux plus entendre parler de RAID5 mais de RAID6. Le risque est en effet assez élevé d'avoir un pépin lors d'une reconstruction d'un RAID5. Avec le RAID6, la sécurité est vraiment mieux pour pas beaucoup plus chère (je parle des baies a plus de 12 disques assez répandue maintenant).

  • # Commentaire supprimé

    Posté par  . Évalué à 4.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: FUSE

      Posté par  . Évalué à 3.

      À noter que FUSE existe sous Linux et FreeBSD. Un port vers OpenSolaris a été mentionné. Le rêve : FUSE permet de créer un pilote de système de fichier pour plusieurs OS :).

      Et même Mac OS X, maintenant (http://code.google.com/p/macfuse/ ).

    • [^] # Re: FUSE

      Posté par  . Évalué à 3.

      C'est vrai que ca serait interssant d'avoir un pilote de fs sur plusieurs os... mais pourquoi s'arreter aux fs dans ce cas ? ;)

    • [^] # Re: FUSE

      Posté par  . Évalué à 2.


      Le rêve serait de larguer gnome-vfs pour du pure fuse. Les perfs seront certainement meileur, on pourra traiter correctement un fichier (ex. les permissions de fichier via FTP). Il y a déjà des discussion à ce sujet, mais pas vraiment d'actes.

      Ça, se serait vraiment le must : plus besoin d'applications "connaissant" gnome-vfs, n'importe quelle appli fonctionnera.

      Et plus de bugs^Mfonctionnalités un peu bizarre, genre gedit qui permet d'ouvrir un fichier sur FTP mais qui peut pas le sauvegarder (supair)

      • [^] # Re: FUSE

        Posté par  . Évalué à 5.

        Pour info, il existe un FS fuse qui sert de miroir pour les KIO.
        http://kde.ground.cz/tiki-index.php?page=KIO+Fuse+Gateway

        Les KIO gèrent correctement les droits, y'a pas de problèmes pour sauvegarder sur un FTP et surtout y'en a déjà une floppée de disponibles (http, https, ftp, sftp, fish, smb...)

    • [^] # Re: FUSE

      Posté par  . Évalué à 3.

      Le problème avec Fuse, c'est que, contrairement aux translators du Hurd par exemple, tout n'est pas en espace utilisateur. Tu gardes un genre de "proxy" en espace noyau. J'avais déjà essayé de coder un FS Fuse, et j'avais fait une erreur de programmation qui avait planté mon FS. Fuse n'a pas voulu le démonter, umount non plus... Obligation de redémarrer la machine.
      Avec un système vraiment conçu pour ça, un tel problème n'existe pas.

      Les KIO et gnome vfs ne souffrent pas de ce problème en implémentant tout en espace utilisateur, mais ça pose le problème de la compatibilité avec les applications.
      De plus FUSE n'est pas forcément plus rapide que les KIO ou gnome vfs. En effet, avec FUSE, il y a des promenades entre l'espace noyau et l'espace utilisateur, qui sont très "lentes" par rapport à des communications entre processus dans l'espace utilisateur.
      On ne peut pas tout avoir :/

    • [^] # Re: FUSE

      Posté par  . Évalué à 2.

      Le rêve serait de larguer gnome-vfs pour du pure fuse.
      Y a peu de chance que ca se fasse. Cf un article sur gnome-vfs de l'epoque qui expliquait que pour certains fs (ftp, ssh, ...) il etait dur d'emuler des comportement POSIX et du coup c'etait mieux de passer par gnome-vfs (au moins les appli savent a quoi s'attendre).

Suivre le flux des commentaires

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