# [ASTUCE] Défragmentez vos fichiers avec ShaKe

## 98111

Je vais ici présenter ShaKe, un logiciel libre (dont je suis l'auteur) qui met à disposition de tous les GNU/Linuxiens le plaisir de la défragmentation.

Principe de fonctionnement

Une bonne introduction au principe de ShaKe est cet article qui argumente que Linux n'a pas besoin de défragmentation http://geekblog.oneandoneis2.org/index.php/2006/08/17/why_doesn_t_linux_need_defragmenting .

Effectivement dans la quasi-totalité des cas le système de fichier sait se débrouiller tout seul.  ShaKe vise précisement à déceler les seuls cas où le système de fichier échoue.

Il y en a au moins trois :

Premièrement, le cas où le disque est trop plein. Lors de la présentation à mes profs (à la base c'est un projet d'étude à Lyon1), j'avais fourni une image de filesystem qui faisait bien ressortir le problème : http://vleu.net/shake/disk.bin.bz2 . Sur cet exemple (très artificiel), les fichiers "gros" (un méga si je me rappelle bien) passaient d'un millier de fragments à quelques uns. Le cas de ce Gentooïste montre que ça arrive aussi dans la vraie vie.

Ensuite, les "fichiers sparses". Quand un programme Linux accède par exemple au 60ème méga octet d'un d'un fichier qui n'en fait que 5, le système de fichier ne génère pas un fichier plein de zéros pour "remplir le trou" mais "saute par dessus". On a alors systématiquement deux fragments. C'est une fonctionalité très intéressante puisqu'elle fait gagner une quantité non négligeable d'espace disque. Mais les logiciels de peer to peer (notament) lui causent problèmes car il reçoivent les morceaux dans un ordre plus ou moins aléatoire, ce qui cause de nombreux sauts et une fragmentation importante. ShaKe détecte ces sauts injustifiés, mais aussi ajoute des sauts dans le cas où il seraient utiles.

Enfin, il y a le problème de l'évolution de la taille et de l'usage des fichiers. ReiserFS (extN aussi je suppose) semble s'arranger pour placer les fichiers d'un même dossier ensemble, et dans l'ordre d'écriture. Mais aussi intelligent soit-il, le système ne peut pas anticiper deux ans d'utilisation, et si par exemple un dossier se voit ajouter une centaine de fichiers après être longtemps resté intact, ou si un fichier grossit sans cesse longtemps encore après avoir été crée, il seras bien obligé de fragmenter.

Il y a aussi d'autres choses, comme le fait que l'ordre d'écriture ne soit pas nécessairement l'ordre de lecture (shake réécrit les fichiers éloignés les un des autres dans l'ordre de lecture) et le fait que de nombreux fichiers restent "sur place" longtemps, fragmentant l'espace libre car le FS ne va pas de lui même les déplacer (shake les réécrit aussi).

Pour résumer : il y a des cas (rares) où les hypothèses que le système de fichier avait fait sur l'utilisateur, ou sur l'usage des fichiers sont fausses. ShaKe notifie le problème au système de fichier simplement en lui intimant l'ordre de les réécrire. L'efficacité du système de fichier sous jascent est donc justement ce qui fait marcher ShaKe et cet article va dans mon sens.

Par contre, s'il est donc susceptible d'être utile, ce n'est bel et bien pas au quotidien car ces cas sont rares. 

L'installation

Comme le bug pour intégrer ShaKe à portage se traîne depuis un certain temps, il faudras utiliser un overlay.

```
mkdir -p /usr/local/portage/sys-apps/shake

cd  /usr/local/portage/sys-apps/shake

wget http://download.savannah.nongnu.org/releases/shake/shake-0.27.ebuild
```

Il reste encore à ajouter les options "noatime" à la partition

```
mount -o remount,noatime /
```

si la partition est de type reiserfs3, il convient de rajouter également l'option notail.

```
mount -o remount,notail,noatime /
```

Avant de finalement ordonner le merge de shake.

```
emerge -av sys-apps/shake
```

Principe d'utilisation

Pour déceler les cas à problèmes, ShaKe utilise un jeu de critères visant à estimer le coût réel de la fragmentation, pour évaluer si la défragmentation est rentable.

En premier lieu, il cherche les "amis" du fichier. Par défaut ce sont les fichiers du même dossier ayant un atime proche.

Ensuite il exprime des exigences, notamment le nombre maximal de fragments, le nombre maximal de "miettes" (minuscules fragments qui font faire des déplacements consécutifs à la tête de lecture), et la distance vis à vis des amis (utile pour des programmes comme dpkg, make ou portage qui manipulent de nombreux fichiers d'un même dossier).

 Ces exigences sont exprimées sous formes de seuils que les statistiques du fichier ne doivent pas dépasser.

 Après cela, il examine la taille des fichiers et les classe en trois catégories : ceux qui sont petits et qui correspondent surtout à une fragmentation de l'espace libre (typiquement un fichier de configuration), ceux qui sont énormes (typiquement un film), et les autres.

 À chacune de ces catégories il associe une tolérance, qui multiplie les seuils.

 Enfin, il prends sa décision.

L'utilisation proprement dite

Armé de toute ces connaissances, il suffit de choisir un mode de parcours, parmis deux qui sont :

 - parcourir les fichiers d'un sous dossier, en plaçant cote à cote les fichier proches dans l'ordre lexical

 - parcourir les fichiers d'une liste, en plaçant cote à cote les fichier proches dans l'ordre lexical

Et éventuellement de régler les paramètres précédemment cités. Le site web et la page du projet donnent quelques informations à ce sujet.

Dans le cas le plus courant, ça correspond en pratique à exécuter 

```
shake DOSSIER
```

.

Pour conclure, voici quelques exemples, extraits de la manpage :

Voir la fragmentation d'un dossier : 

```
shake --pretend --verbose --verbose DOSSIER
```

Examiner tous les MP3 des sous-dossiers, en conseillant de placer cote à cote ceux qui sont proches dans l'ordre lexical : 

```
find -type f -iname '*.mp3' | sort | shake
```

Au passage, il y a actuellement un module python pré alpha qui expose un début d'API pour l'utiliser depuis une interface externe.

Et si vous avez des suggestions, n'hésitez pas !

----------

## GentooUser@Clubic

Sympa je teste tout de suite   :Very Happy: 

Ne pas oublier un petit 

```
ebuild shake-0.27.ebuild digest
```

avant emerge -av sys-apps/shake

----------

## Trevoke

Sympa sympa! J'essaye un peu partout. J'ai du reiserfs, du xfs, du jfs, du reiserfs.. Ca devrait m'aider au moins un chouia  :Smile: 

----------

## Trevoke

reiser4 .... *GROWL*

shake: /usr//src/linux-2.6.15-nitro3/drivers/acpi/utilities/.utinit.o.cmd: failed to set position time, check user_xattr: Operation not supported

C'est un probleme de FS je suppose?

On dirait que reiser4 n'est pas defragmentable (en meme temps, je sais pas s'il se fragment vraiment..)

----------

## Kangourou

 *Trevoke wrote:*   

> reiser4 .... *GROWL*
> 
> shake: /usr//src/linux-2.6.15-nitro3/drivers/acpi/utilities/.utinit.o.cmd: failed to set position time, check user_xattr: Operation not supported
> 
> 

 

Ça m'a fait pareil avec du ext3, il m'a suffit de monter la partoche avec l'option user_xattr, et ça marche  :Smile: 

Par contre elle est vraiment trop pleine, je peux pas la defrag   :Embarassed: 

----------

## SanKuKai

Argh !

J'ai lancé un :

```

# shake /

```

Ce qui a eu pour effet de freezer mon système au bout de quelques secondes. 

J'ai alors tenté de rebooter mais le redémarrage a échoué apparemment à cause d'une bibliothèque endommagée de la libc... J'ai alors essayé de chrooter ma partition depuis un LiveCD pour réémerger la glibc mais le chroot a échoué (toujours le problème de bibliothèque corrompue !)   :Evil or Very Mad: 

Par chance j'ai pu restaurer un backup datant de mi septembre (après le passage à gcc-4.1.1 ouf !   :Laughing:  ).

Ai-je fais une boulette en lançant shake depuis mon système en marche ? Peut-être est-il plus prudent de lancer shake depuis un Live CD ?   :Confused: 

----------

