Defragmenter

Un des intérêts de Mac OS X est qu'il ne fragmente que très peu, ainsi, une défragmentation devient inutile. D'ailleurs, Apple préconise plutôt de simplement redémarrer l'ordinateur! Mais si tu y tiens vraiment, tu peux regarder sur ce site:
http://www.osxfacile.com Tu y trouveras bcp d'info sur Mac OS, très bien détaillée.
Pour un lien direct vers la page concernée:
http://www.osxfacile.com/rub_optimiser.html

Arcank

Merci beaucoup arcank! ce site est plein d'infos!
merci encore!

+ 1 les systémes Unix (dont mac os x fait parti) et Linux ne se fragmentent pas, donc pas de défragmenteur d'installé. Cet utilitaire n'est utile que sous windows..

sous OS X les fichiers ne se fragmentent pas càd qu'il restent écrit sur des bloc contigus du disque. Par contre le disque se fragmente en laissant des espaces libres entre les fichiers.

Et si tu lances Classic ? Ce n'est pas OS X. S'il n'était pas utile de défragmenter, à quoi peuvent bien servir tout ces utilitaires qui optimisent : Onyx, Xtools, Cocktail, TechTools Pro, Drive10, etc. ? Il ne faut pas ergoter sur ce qu'est la fragmentation sur OS X, il faut optimiser.

classic fonctionne dans OS X comme une application OS X. D'autre part Onyx, cocktails xtools ne défragmentent pas ! l'optimisation du système dont ils proposent l'option concerne le prebinding. Effectivement TechTool et drive 10 optimisent le disque dur, c e qui correspond à la seconde partie de mon message précédent. Je n'ai jamais dit qu'il était inutile de défragmenter, j'ai éclairci 2 notions de fragmentation différentes aux yeux des utilisateurs.

j'ai éclairci 2 notions de fragmentation différentes aux yeux des utilisateurs

Je pense m'y connaître comme tu dis, mais je ne suis pas omniscient alors voici une explication sur ce qu'est le prebinding. C'est un vieil article du site Cuk.ch, une référence pour les mac users (il y en a d'autres). Attention c'est assez long.

Qu'est-ce que le prebinding ?

Afin de comprendre le prebinding, il s'agit de comprendre comment fonctionne une application ou n'importe quel programme informatique.

De nos jours, un programme repose sur une série de bibliothèques (Library) qui lui fournissent des fonctions. Par exemple, Apple met à disposition des programmeurs la bibliothèque Cocoa. Grâce à cela, le programmeur peut facilement afficher une fenêtre au look MacOS X, sans devoir la programmer, il peut créer un menu, un bouton et son action, etc. Tout cela sans effort, mais en utilisant des fonctions mises à disposition par Apple. De même, Apple met à disposition une bibliothèque WebKit sur laquelle repose Safari et que les programmeurs d'Omniweb ou de Shiira ont pu très simplement utiliser (nous l'avons même fait dans cet article).

En tout, Apple met à disposition plus de 150 bibliothèques bourrées de fonctions et d'objets que les programmeurs pourront utiliser.

Mais lorsque le programmeur créé son application, il ne va pas y copier intégralement toutes les bibliothèques qu'il utilise, cela augmenterait considérablement la taille de l'application et votre disque dur serait vite rempli d'applications utilisant les mêmes bibliothèques, ces dernières seront donc dupliquées inutilement. Cette méthode, appelée static linking n'est pas une bonne solution.

La chose raisonnable à faire est ce qu'on appelle le dynamic linking. Les bibliothèques sont installées avec le système et un programme désirant utiliser une bibliothèque va faire un lien vers le fichier système correspondant.

Si vous êtes curieux, vous pouvez allez voir ces bilibothèques en vous rendant dans le menu "Aller" du Finder, puis en sélectionnant "Aller au dossier..." et en entrant ceci:

/System/Library/Frameworks

Vous y trouverez quelques noms connus: Cocoa, Carbon, WebKit, Quicktime, etc.

Ce système de lien dynamique a de très gros avantages. Tout d'abord, lorsqu'Apple fournit une mise à jour du système vos programmes utilisent automatiquement les nouvelles versions des bibliothèques, sans devoir recompiler. J'en veux pour preuve que lorsque Panther a amené un nouveau look de fenêtre (sans les rayures) vos applications ont automatiquement bénéficié de ce nouvel aspect.

Le deuxième avantage est de taille. Si vous lancez cinq applications qui utilisent une même bibliothèque de fonctions, la première application chargera la bibliothèque en mémoire, mais les quatre autres n'auront plus besoin de le faire et partageront la zone mémoire contenant la bibliothèque. Le temps de lancement de ces quatre applications sera donc réduit.

Mais revenons à nos moutons, qu'est-ce que le prebinding vient faire là dedans ?

Comme je l'ai dit, une bibliothèque fournit une série de fonctions ou d'objets. Lorsqu'une application se lance, elle charge les bibliothèques et doit alors y trouver les objets qu'elle désire utiliser afin d'y faire un lien depuis son propre code.

Ceci étant fait, l'application peut utiliser ces objets comme si elle lui appartenait. Ce processus s'appelle le binding et il peut prendre beaucoup de temps. En effet, il peut y avoir des milliers d'objets à lier, car l'application doit faire le lien vers les objets dont elle a besoin, mais ces objets doivent également faire des liens vers d'autres objets dont ils ont besoin.

Vous comprendrez donc qu'éviter ce processus raccourcirait significativement le temps de lancement des applications.

C'est là qu'intervient (enfin !) le prebinding. En faisant un prebinding on anticipe le processus de binding en plaçant dans le programme un fichier contenant tous les liens dont il a besoin. Ainsi, lorsque l'application est lancée elle ira chercher l'information dans ce fichier et pourra se passer du processus de binding.

Bien entendu, à chaque fois qu'une bibliothèque est modifiée ou mise à jour, le fichier contant les liens deviendra obsolète et il faudra refaire le prebinding.

Lorsque vous faites une mise à jour du système ou l'installation d'un logiciel via le programme Installation, la dernière phase s'intitule "Optimisation du Système", en réalité il fait là le prebinding.

Le ralentissement qu'observait François était donc simplement dû à un mauvais prebinding. Or, en défragmentant le disque, son logiciel relançait une procédure de prebinding, ce qui donnait cette impression de vitesse accrue.

Pour tout vous avouer, je ne suis pas tout à fait certain de la raison pour laquelle il faut refaire le prebinding de temps en temps. J'imagine qu'à force d'installer et de désinstaller des programmes (comme François le fait certainement) il se peut que l'information de binding soit perdue, allez savoir. Toujours est-il qu'un coup de balai de temps en temps ne fait pas de mal, d'autant plus que c'est vite fait avec le logiciel Onyx. Dans l'onglet "Maintenance" il faut cocher la case "Optimiser les performances du système". Pour vraiment faire une optimisation complète il faut choisir "Optimisation complète".

On peut également le faire simplement en ligne de commande avec:

sudo update_prebinding -root / -force

Il faut noter que seules les applications se trouvant sur le disque de démarrage peuvent profiter du prebinding.

Même si la nécessité du prebinding reste un peu mystérieuse, son utilité est beaucoup plus avérée que celle d'une défragmentation. Comme de plus la défragmentation est beaucoup plus périlleuse, longue et aléatoire que le prebinding, je ne peux que vous encourager à vous contenter d'un petit coup de Onyx de temps en temps.

La bataille fut rude...mais la défragmentation a été vaincue.

Si vous voulez plus d'informations techniques sur le prebinding vous pouvez lire cette page chez Apple.

Très intéressant, merci beaucoup.
Mais donc, si je comprends bien, la dégragmentation ne sert qu'à effacer les trous entre les différents fichiers. Elle peut donc être considérée comme utile puisqu'elle devrait accélérer l'accès à ces fichiers. Le tout est de trouver la manière et il est certain qu'une copie conforme du contenu d'un volume vers une autre, suivi d'un éventuel rapatriement après formatage est la meilleure méthode.

Dernièrement, j'ai tout de même défragmenté avec TechTool Pro, son interface graphique représentant des bulles est assez semblable à celle de Drive 10, également de Alsoft. Seulement, là où Drive 10, sur un volume non-journalisé (Mac OS X.2.x ET Mac OS 9.x) m'affichait des trous, mais aussi des fichiers fragmentés, TechTool Pro ne m'affiche plus que les vides d'un volume journalisé (Mac OS X.4.2 SANS OS 9 ni Classic) et me signale que du fait de cette journalisation, il ne peut totalement défragmenter.

Tu aurais un éclaircissement ?

attention ! je ne suis pas certain de la compatibilité de drive 10 et techtool avec Tiger.

J'ai testé TechTool 4.04 depuis son CD sur Mac OS X.4.2 , sans anicroches, et il y a une MàJ en 4.05 disponible. Je n'ai plus testé Drive 10, son CD est obsolète, sans doute juste bon pour Jaguar.

Je me serais bien fait un CD de TechTool 4.05, mais la compatibilité de BootCD fait défaut désormais. Or c'est ce que Tri-Edre conseille. Leur CloneX ne fonctionne pas pour ça, c'est vraiment étrange. J'ai bien essayé, mais sans succès.

Merci Merci Merci !!!

J'ai installé OnyX apres la lecture de ce topic.
Je suis passé de 15Go disponibles à 202 !!

Merci beacoup !!

les disques durs sous Mac OSX ne se fragmentent pas... Il vaut mieux lire ça que d'être aveugle !