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 Nicolas Blanco (site web personnel) . Évalué à 7.
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 ccomb (site web personnel) . Évalué à 10.
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 un_brice (site web personnel) . Évalué à 10.
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.
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 matlj . Évalué à 3.
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 un_brice (site web personnel) . Évalué à 3.
Du coup j'ai désactivé ça.
Merci !
[^] # Re: Ne compile pas
Posté par matlj . Évalué à 2.
# Enfin :)
Posté par lndark . Évalué à 1.
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 abc . Évalué à 1.
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 matlj . Évalué à 4.
http://matlj.free.fr/shake-17.ebuild
[^] # Re: Enfin :)
Posté par matlj . Évalué à 3.
[^] # Re: Enfin :)
Posté par Zakath (site web personnel) . Évalué à 3.
- 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 matlj . Évalué à 1.
Merci encore.
# ...
Posté par M . Évalué à 6.
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 matlj . Évalué à 4.
http://ck.kolivas.org/apps/defrag/
[^] # Re: ...
Posté par un_brice (site web personnel) . Évalué à 10.
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 Ludovic F (site web personnel) . Évalué à 3.
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 un_brice (site web personnel) . Évalué à 2.
# shake shake shake...
Posté par Uld (site web personnel) . Évalué à -6.
shake your bootie.
[^] # Re: shake shake shake...
Posté par Krunch (site web personnel) . Évalué à 1.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# meuh
Posté par gc (site web personnel) . Évalué à 2.
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 Krunch (site web personnel) . Évalué à 3.
memmem(3) n'existe que sous FreeBSD.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: meuh
Posté par alf . Évalué à 2.
Les tableaux de longueur variable (ou variable-length arrays, VLA) sont en effet une nouvelle fonctionnalité du C99, mais il faut noter que le support de GCC pour cette fonction est broken, dixit http://gcc.gnu.org/gcc-4.1/c99status.html . A utiliser avec prudence, donc...
Si l'implémentation de malloc() est telle que les perf sont mauvaises, pourquoi ne pas utiliser un gestionnaire de mémoire intermédiaire ? La glibc implémente "obstacks" ( http://www.gnu.org/software/libc/manual/html_node/Obstacks.h(...) ). Une recherche rapide ("memory pool C") me donne aussi http://www-128.ibm.com/developerworks/linux/library/l-memory(...) qui donne plein de liens, dont la bibliothèque Apache http://apr.apache.org/docs/apr/group__apr__pools.html . Ca serait sûrement beaucoup plus portable que alloca ou strdupa().
[^] # Re: meuh
Posté par alf . Évalué à 0.
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 gc (site web personnel) . Évalué à 2.
[^] # Re: meuh
Posté par alf . Évalué à 0.
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 gc (site web personnel) . Évalué à 2.
# XFS
Posté par Ph Husson (site web personnel) . Évalué à 2.
[^] # Re: XFS
Posté par Raphaël G. (site web personnel) . Évalué à 2.
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 Sufflope (site web personnel) . Évalué à 2.
[^] # Re: XFS
Posté par un_brice (site web personnel) . Évalué à 1.
[^] # Re: XFS
Posté par Raphaël G. (site web personnel) . Évalué à 2.
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 tristanleboss . Évalué à 1.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.