Journal Shake : secouez vos fichiers, c'est pour leur bien !

Posté par (page perso) .
Tags : aucun
0
14
mai
2006
Il s'agit dans ce journal de faire la promotion d'un hack que d'aucun jugerons immonde mais qui aura peut être son utilité...
Avant toutes choses, je tient à prévenir que je n'ai aucune compréhension de la manière dont gigotent les boyaux des systèmes de fichiers dont je parle. Simplement mon truc a l'air de marcher alors youpi.

Je me lance.
En fait l'idée c'est que des défragmenteurs y'en a pas tellement sous GNU/Linux, vu qu'y en a pas tellement besoin, vu que les systèmes de fichiers savent faire leur job.
Sauf que, même en faisant de son mieux, le pauvre FS peut pas anticiper 2 ans d'utilisation d'une partoche (en fait il semblerait que le simple remplissage de fichiers sparses soit déjà une source de problèmes pour reiserfs).
Du coup, après un bout de temps, certains des placements des fichiers sont plus adaptés. Et là c'est le drame.

Et c'est à ce moment qu'intervient Shake : à l'aide d'un certain nombre de critères, comme le nombre de fragments ou la distance entre deux fichiers ayant des temps d'accès proches, il essaie de déterminer quels sont les fichiers dont le positionnement est obsolète. Et il les réécrit. C'est stupide, mais ça a l'air de marcher.

En fait c'est même pas trop mal par rapport à des systèmes plus bourrins, notement ça évite pas mal d'ennuis, par exemple en cas de plantage parce que si le système de fichier est journalisé alors le secouage le sera aussi. Autre avantage : on peut ne procéder qu'au secouage d'un dossier, et ce même alors que la partition est utilisée.

C'est un projet destiné à mes profs (UE if3 à lyon1), donc normalement c'est bien commenté (en anglais de cuisine). Y'a même un dossier avec, et des schémas qui disent comment ça marche et qu'est-ce que j'ai essayé (les chapitres 2 et 3 du dossier, le reste c'est du blabla).

Ça tourne seulement sous Linux, mais je serais content si quelqu'un essayait de le porter sur le NetBSD de son moulin a poivre. J'utilise strdupa pour pas choquer ceux qui aiment pas les goto clean, et aussi getopt_long, mais je suis prêt à supprimer tout ça si ça peut aider.

Enfin, pour tester la bête il faut récupérer son tarball, faire un "make" et puis lancer ./shake --pretend -v -v un_fichier en tant que root.
Y'a une manpage, mais disons déjà que "-p ou --pretend" met le logiciel en mode lecture seule, que "-v -v" affiche des statistiques de la forme "NOM_FICHIER: start=DÉBUT_FICHIER, ideal=DÉBUT_IDÉAL, end=FIN_FICHIER, fragc=NOMBRE_FRAGMENTS, crumbc=NOMBRE, age=ÂGE_FICHIER, CULPABILITÉ" et que rajouter "-o0" permet de forcer le secouage.
"start" et "end", c'est la position du fichier sur le disque, "ideal" la position recommandée par rapport à celle des autres fichiers du dossier, "fragc" le nombre de fragments, "crumbc" le nombre de fragments minuscules et "age" le ctime. Un fichier coupable est vu comme fragmenté.

Un -v de plus affiche un message pour indiquer la situation de chaque fragment. C'est rigolo (par exemple pour voir comment reiserfs alloue les blocks, il le fait de manière franchement intelligente) et, ça au moins, ça marche.
La doc est là : http://vleu.net/shake/dossier_shake.pdf
Le code ici : http://vleu.net/shake/shake.tar.bz2

Pour l'esbroufe, je fournit une image de disque sur laquelle il est particulièrement efficace (celle citée dans le rapport -_^) : http://vleu.net/shake/disk.bin.bz2

Ah oui : je vois pas ça comme un truc qu'un particulier est censé utiliser une fois par mois... peut être une fois tout les ans ou alors en cas d'usage intensif des fichiers sparse.
Et je déconseille de l'appliquer a des fichiers sensibles dans l'immédiat. Et il marche moins bien sur les partitions reiserfs montée sans notail, à cause d'une limitation de FIBMAP, mais faut toujours utiliser notail de toutes manières.
Si y'en a que des explications par rapport à ce dont je cause dans le dossier interesse, je suis à leur disposition.
  • # ouh la !

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

    Avant toutes choses, je tient à prévenir que je n'ai aucune compréhension de la manière dont gigotent les boyaux des systèmes de fichiers dont je parle. Simplement mon truc a l'air de marcher (...)

    Euh... rien qu'en lisant ça, j'ai pas trop confiance quoi. Pourquoi essayer un programme qui fait des manipulations sur quelque chose de très bas niveau et donc de très sensible d'une personne qui dit ne pas avoir de compréhension... et qui dit "mon truc à l'air de marcher..." bon... si... pourquoi pas le tester sur une partition test... mais meme la j'aurais peur de le lancer en root, sachant que j'ai un seul disque, pas que ça me bousille mes autres partoches.

    Donc pas très rassurant tout ça. Je laisse les testeurs qui peuvent tester ça sur une partition de test, elle meme sur un disque test :D.
    • [^] # Re: ouh la !

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

      Pas rassuré ?

      Facile, laisse-moi quelques jours, je compile son truc, je rajoute une belle interface graphique programmée avec visualGambas, je fabrique une belle pochette avec plein de couleurs, je marque un truc du style « Optimisez sans risque votre disque dur, améliorez la vitesse de votre ordinateur », je colle une étiquette avec un code barre et une inscription 49,90¤, et ça paraîtra tout de suite plus rassurant.
    • [^] # Re: ouh la !

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

      Pourquoi essayer un programme qui fait des manipulations sur quelque chose de très bas niveau et donc de très sensible d'une personne qui dit ne pas avoir de compréhension... et qui dit "mon truc à l'air de marcher..."
      Hum par goût du risque ?
      Plus sérieusement, shake fait rien de très bas niveau : la partie qui manipule les fichiers le fait à coups de open/read/write/close. Au pire il est susceptible de corrompre les fichiers que tu lui donne à manger, mais pas ta partition.

      Donc pas très rassurant tout ça. Je laisse les testeurs qui peuvent tester ça sur une partition de test, elle meme sur un disque test :D.
      Sinon tu peut utiliser losetup et une partition virtuelle.
      Il te suffit de télécharger http://vleu.net/shake/disk.bin.bz2 , et de le décompresser.
      Ensuite (à faire en root)
      modprobe loop # si necessaire
      mount -o loop,notail -t reiserfs disk.bin /mnt/dossier_temporaire
      ./shake -pvv /mnt/dossier_temporaire
      ./shake -o0 /mnt/dossier_temporaire
      ./shake -pvv /mnt/dossier_temporaire

      Et tu a l'assurance que tout se passe dans le disque virtuel !
  • # Ne compile pas

    Posté par . Évalué à 3.

    La compilation ne fonctionne pas sur mon système

    gcc-4.1.0, glibc-2.4, 2.6.16-ck10 x86_64

    Voila ce que ça me donne :

    gcc -std=gnu99 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -Werror -pedantic-errors -Wconversion -Wpointer-arith -Wbad-function-cast -Wcast-align -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -O2 -DNDEBUG -c executive.c -o executive.o
    cc1: warnings being treated as errors
    executive.c: In function 'fcopy':
    executive.c:63: attention : passing argument 2 of 'ioctl' with different width due to prototype
    executive.c:145: attention : passing argument 3 of 'write' with different width due to prototype
    executive.c: In function 'shake_reg':
    executive.c:212: attention : passing argument 3 of 'fcopy' with different width due to prototype
    executive.c:226: attention : passing argument 3 of 'fcopy' with different width due to prototype
    executive.c: In function 'list_dir':
    executive.c:324: attention : passing argument 2 of 'qsort' with different width due to prototype
    make: *** [executive.o] Erreur 1


    Peut-être est-ce dû à gcc 4.1 ?
    • [^] # Re: Ne compile pas

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

      À mon avis c'est plutôt lié au fait que tu soit en 64 bit, et que je lui ai demandé de me prévenir au lieu de faire des casts implicites. Mais ça n'a pas de sens sur une version "finale", c'est plus pour le debug.
      Du coup j'ai désactivé ça.
      Merci !
  • # Enfin :)

    Posté par . Évalué à 1.

    Je vois que tu a enfin sorti ton truc sur lequel tu bossais en salle info...

    Je me porterai pas garant de son boulot, mais j'ai vu tourner une version de son soft y'a quelques mois, et ca fonctionnai tres bien!

    Je me demande quand tu sortiras un ebuild gentoo.
    Aussi tu devrais te renseigner sur les fs et aller en cours, ca pourrai t'etre utile.

    Sinon, je suis ravi que tu ai reussi a sortir ton "truc", je te suivrai avec un projet moins important d'ici quelques mois :)

    PS: je suis toujours dispo pour un jdr
    • [^] # Re: Enfin :)

      Posté par . Évalué à 1.

      Aussi tu devrais te renseigner sur les fs et aller en cours, ca pourrai t'etre utile.

      il connait mieux les fs qu'il ne laisse entendre, juste histoire d'être modeste :-)

      Aller en cours d'IF3 ? --> ahahahhaha désolé mais faut pas pousser...
    • [^] # Re: Enfin :)

      Posté par . Évalué à 4.

      Voici un ebuild vite fait, à mettre dans app-misc :

      http://matlj.free.fr/shake-17.ebuild
      • [^] # Re: Enfin :)

        Posté par . Évalué à 3.

        En fait, ça irait mieux dans sys-fs..
      • [^] # Re: Enfin :)

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

        Quelques commentaires sur l'ebuild:

        - le header n'est pas correct, il manque la dernière ligne (il faut copier exactement le contenu de /usr/portage/header.txt.
        - SRC_URI n'a pas le numéro de version dans le nom du tarball. Solution 1, renommer et héberger directement sur un miroir gentoo, solution 2, taper sur upstream (ça ne devrait pas être trop difficile dans ton cas :)).
        - le cd bla juste avant la compilation va dans src_unpack, pas dans src_compile. Du coup, tu peux faire le beaucoup plus propre S="${WORKDIR}/shake17" à côté des autres variables, et laisser le src_unpack par défaut s'en charger. Le cd de src_install est aussi inutile, tout comme le || die sur le dobin.
        • [^] # Re: Enfin :)

          Posté par . Évalué à 1.

          Wow, merci infiniment pour toutes ces précisions. C'est mon premier ebuild et je ne demande qu'à apprendre :)

          Merci encore.
  • # ...

    Posté par . Évalué à 6.

    Pourquoi une version en C ?

    Avec filefrag pour determiner le taux de fragmentation d'un fichier, cp (pour copier le fichier) et rm (pour supprimer le fichier), je te fais un petit script shell qui fait la meme chose.
    • [^] # Re: ...

      Posté par . Évalué à 4.

      Con Kolivas a fait un script dans ce genre,

      http://ck.kolivas.org/apps/defrag/
      • [^] # Re: ...

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

        Hum l'idée est là, mais l'efficacité serait celle à peu près celle de shake 0.5 .

        Pour commencer, Filefrag, à mon avis, a été crée à des fins de déboguage, et pas dans le but d'évaluer l'impact de la fragmentation sur les performances.
        Par exemple, il considère que deux "morceaux" distants d'un unique block sont des fragments, alors qu'en pratique la taille du trou peut être négligeable en terme de performances. De même, il ne tient pas compte des liens qui existent entre les fichiers ayant un atime proche, ni de la taille des fragments relativement à celle du fichier, ni de la date des fichiers.

        Ensuite, le couple cp/rm a plusieurs inconvénients. Par exemple si ton fichier "A" est hardlinké vers "B" et que tu fait un "cp A TEMP; rm A; cp TEMP A", le lien dur entre "A" et "B" sera perdu. De même, pour les éventuelles métadonnés.
        Tu me diras, un "cat A > TEMP" n'auras pas certains de ces inconvénients. C'est vrai, mais il ne géreras pas les fichiers sparses.

        Je suppose aussi qu'on pourrait en fait contourner les problèmes liés à filefrag avec un gros script (awk ? perl ?) qui en parserait la sortie et recalculerais des informations de fragmentation plus utilisables. De meme, on pourrait effectivement utiliser ls pour trier les fichier par atime, puis réutiliser les informations extraites par le script parsant filefrag pour calculer (comme je le fait) la position idéale et ainsi de suite.

        Les difficultés liées à cp me paraissent plus difficilement contournables... et il faudrais encore s'occuper de la gestion des erreurs, penser à éviter les liens symboliques etc.

        Déjà à ce stade, je pense que le code serait beaucoup plus lourd et complexe que celui de shake, tout en ayant des performances moindre, et (au choix) le problème des fichiers sparses ou des métadonnées. Et il resterais encore à tenir compte du coût lié à la copie de gros fichiers, de la différence d'atime dans le calcul des corrélations entre les fichiers... sans parler du fait qu'aparement filefrag soit destiné à Linux uniquement (bon, shake aussi actuellement, mais pas à terme).

        Alors que, finalement, shake c'est juste trois fichiers de 300 lignes en C, qui se veulent propres, abondament commentées et documentées dans un joli PDF.
        En plus shake vient avec des routines spécialisées, notement un système de copie des fichiers sparse qui essaie de tenir compte d'une évaluation de la lecture anticipée de la plupart des disques, une routine pour modifier le ctime et un joli mode verbose.

        Et j'en ai mis un coup à mon /usr/bin sans même le casser !
        Mangez-en !

        Ceci dit, en toute honnêteté, je doit dire que le choix du langage était aussi guidé par le fait que l'UE soit intitulée "Programation en C" -_^. Il reste que je suis sincère quand j'affirme penser que le langage était adapté.
  • # Fragmentation

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

    En cherchant un peu plus d'informations concernant la fragmentation des fichiers sous ReiserFS je suis tombé sur un petit script permettant d'éstimer le taux de fragmentation des différents fs.

    Je vous invite donc à faire des tests, avant et après avoir secoué vos fs ;)

    http://forums.gentoo.org/viewtopic-p-3081971.html
    • [^] # Re: Fragmentation

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

      Hum, sauf qu'il utilise filefrag, qui à mon avis n'est pas vraiment adapté (comme je l'ai dit un peu plus haut).
  • # shake shake shake...

    Posté par (page perso) . Évalué à -6.

    shake shake shake...

    shake your bootie.
  • # meuh

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

    Ça tourne seulement sous Linux, mais je serais content si quelqu'un essayait de le porter sur le NetBSD de son moulin a poivre. J'utilise strdupa pour pas choquer ceux qui aiment pas les goto clean, et aussi getopt_long, mais je suis prêt à supprimer tout ça si ça peut aider.

    Justement vu son besoin de _GNU_SOURCE est-ce que "strdupa" est utilisable sous *BSD ? (et note que selon la manpage d'alloca (utilisé par strdupa) il faut pas l'utiliser, c'est le Mal) (c'est dommage parces que c'est fantastique et là je te rejoins)

    Corollaire, est-ce que memmem est utilisable sous *BSD[1] ?

    [1] C'est pour un projet secret de serveur de jeu secret écrit en C.
    • [^] # Re: meuh

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

      strdupa(3) n'existe pas sous *BSD mais en C99 c'est un peu inutile puisqu'on peut utiliser des tableaux de taille inconnue à la compilation sur la pile (il fait l'alloca(3) tout seul).

      memmem(3) n'existe que sous FreeBSD.

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

    • [^] # Re: meuh

      Posté par . Évalué à 0.

      Corollaire, est-ce que memmem est utilisable sous *BSD[1] ?

      strstr() est C ISO et fait quasiment la même chose; pourquoi ne pas l'utiliser ? POSIX doit aussi définir des fonctions de recherche de chaînes, il me semble, mais je ne les ai pas en tête.
      • [^] # Re: meuh

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

        parce que lors du transport réseau on dispose de la longueur des messages envoyés, pas besoin donc d'une part de transporter un octet terminateur supplémentaire, et d'autre part les fonctions sur les chaines sont plus couteuses que les fonctions sur taille fixe vu qu'elles doivent detecter la fin de la chaine qui est à une position indéterminée.
        • [^] # Re: meuh

          Posté par . Évalué à 0.

          Ok. Evidemment, si tu ne travailles pas sur des chaînes terminées par '\0', ça a plus de sens.

          Au passage, une rapide recherche me dit que memmem() a été ajoutée à la libc de NetBSD 3.0 (http://netbsd.gw.com/cgi-bin/man-cgi?memmem+3+NetBSD-3.0 ) et qu'elle existe dans celle de FreeBSD (par contre, pour connaître la version de FreeBSD à partir de laquelle elle a été implémentée, je te laisse chercher).
          • [^] # Re: meuh

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

            merci des infos. pour freebsd, j'ai plus vite fait d'internaliser memmem() ;p (ce qui est déjà fait, du coup)
  • # XFS

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

    Juste pour info y a un outil dans xfsprogs qui fait un peu pres le meme genre de choses à priori (apparement il est spécifique à xfs quand même, enfin voir le code source), qui est xfs_fsr
    • [^] # Re: XFS

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

      Ui je suis tombé dessus grâce a son pdf et ça marche rudement bien (faut penser a bien garder de la place libre > taille maxi du plus gros fichier).

      J'ai même gagné un bon Go sur un dd de 300Go, ça fait très plaisir ;)

      pensez a quand même bien faire un sync a la sortie et démonter/remonter la partition pour forcer la remise a zero du journal de "replay".
      (ça éviter de faire oups tout est perdu suite a une coupure de courant)
      • [^] # Re: XFS

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

        Ça doit être une spécifité d'XFS, m'enfin comment une défragmentation fait-elle gagner de la place ???
        • [^] # Re: XFS

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

          Ça doit être une spécifité d'XFS, m'enfin comment une défragmentation fait-elle gagner de la place ???
          Grâce aux fichiers sparse ! Lis ma doc, Shake le gère aussi, sur tout les FS.
          • [^] # Re: XFS

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

            C'est tout bête, le XFS est conçu pour les perfs, donc il écris là où il y a des block libre, et parfois il écris pas vraiment de manière optimale, quelques blocks avant, d'autre après, etc...
            Quand tu supprime un fichier par exemple, il ré-écris les données suivant directement sur l'emplacement de l'inode supprimé (ce qui explique la récupération impossible de fichiers)

            De même les inodes sont a taille variable si mes souvenir son bon (128/256bit par défaut), donc tu peux passer d'un inode de quelque octet a un inode dans un block de 4Ko selon la disposition des blocks de ton fichier...
            (fait le calcul, en refaisant ça sur tout le dd, ben ça en fait de la place perdue...)

            petit détail, si vous voullez utiliser du selinux sur une partition en XFS vous devez créer la partition avec isize=512 (pour avoir la place de mettre les attribut selinux dans l'inode)
  • # Chapeau bas ./..

    Posté par . Évalué à 1.

    C'est bizare : ça marche pas sous Windows :)

    Non, sinon, c'est un super projet dont la lecture apprend beaucoup de choses à un petit newbie tel que moi ...

    En espérant que ce petit projet d'IF3 deviendra grand et qui sait, peut être qu'il sera bientôt intégré à KDE (genre KDefrag ou KShake) ou à GNOME (gnomefrag, gsnake).

    En tout cas, chapeau ...

    Ca me fait penser à une p'tite idée de sites de rencontres pour développeurs tout ça :)

    C'est ainsi que je m'éclipse, ni vu, ni connu ...

Suivre le flux des commentaires

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