Bonjour,
Depuis quelques jours, je constate que le Finder prend en permance 60
à
100% de CPU. Je ne pense pas que c'était le cas avant (j'ai les jauges
CPU de Menu Meter dans la barre de menu). Ce problème résiste à
plusieurs redémmarrages.
Ca ne me parait pas normal, mais je ne sais pas comment faire un
diagnostic plus précis et corriger ça.
Une idée ?
Un truc classique, c'est l'indexage. Mais il me semble que l'on voit
alors le processus mds prendre le CPU, pas le Finder lui-même.
La config : MacBook Pro, 8 Go ram, disque SSD, Mac OS X 10.6.4
Bonjour,
Depuis quelques jours, je constate que le Finder prend en permance 60
à
100% de CPU. Je ne pense pas que c'était le cas avant (j'ai les jauges
CPU de Menu Meter dans la barre de menu). Ce problème résiste à
plusieurs redémmarrages.
Ca ne me parait pas normal, mais je ne sais pas comment faire un
diagnostic plus précis et corriger ça.
Une idée ?
Un truc classique, c'est l'indexage. Mais il me semble que l'on voit
alors le processus mds prendre le CPU, pas le Finder lui-même.
La config : MacBook Pro, 8 Go ram, disque SSD, Mac OS X 10.6.4
Bonjour,
Depuis quelques jours, je constate que le Finder prend en permance 60
à
100% de CPU. Je ne pense pas que c'était le cas avant (j'ai les jauges
CPU de Menu Meter dans la barre de menu). Ce problème résiste à
plusieurs redémmarrages.
Ca ne me parait pas normal, mais je ne sais pas comment faire un
diagnostic plus précis et corriger ça.
Une idée ?
Un truc classique, c'est l'indexage. Mais il me semble que l'on voit
alors le processus mds prendre le CPU, pas le Finder lui-même.
La config : MacBook Pro, 8 Go ram, disque SSD, Mac OS X 10.6.4
Olivier Marti wrote:
> Bonjour,
>
> Depuis quelques jours, je constate que le Finder prend en permance 60
> à
> 100% de CPU. Je ne pense pas que c'était le cas avant (j'ai les jauges
> CPU de Menu Meter dans la barre de menu). Ce problème résiste à
> plusieurs redémmarrages.
>
> Ca ne me parait pas normal, mais je ne sais pas comment faire un
> diagnostic plus précis et corriger ça.
>
> Une idée ?
Tu as pas le calcul de taille de dossiers activé par défaut ?
Pas de connexion à un serveur, à un iDisk ?
Pas de candybar, de "haxies" unsanity,
de partage de dossier avec parallels ?
Quels sont les éléments d'ouverture dans les préférences système, rubrique
comptes ?
Que contiennent les dossiers "startupitems, launchagents et lauchdaemons
du dossiers "bibliothèque" du disque dur ?
> Un truc classique, c'est l'indexage. Mais il me semble que l'on voit
> alors le processus mds prendre le CPU, pas le Finder lui-même.
Exact
> La config : MacBook Pro, 8 Go ram, disque SSD, Mac OS X 10.6.4
Concernant le ssd, essaye de désactiver l'écriture des dates de dernier
accès : recherche dans Google la procédure pour modifier le montage avec
l'option "no atime"
Olivier Marti <olivier.marti@ensta.org> wrote:
> Bonjour,
>
> Depuis quelques jours, je constate que le Finder prend en permance 60
> à
> 100% de CPU. Je ne pense pas que c'était le cas avant (j'ai les jauges
> CPU de Menu Meter dans la barre de menu). Ce problème résiste à
> plusieurs redémmarrages.
>
> Ca ne me parait pas normal, mais je ne sais pas comment faire un
> diagnostic plus précis et corriger ça.
>
> Une idée ?
Tu as pas le calcul de taille de dossiers activé par défaut ?
Pas de connexion à un serveur, à un iDisk ?
Pas de candybar, de "haxies" unsanity,
de partage de dossier avec parallels ?
Quels sont les éléments d'ouverture dans les préférences système, rubrique
comptes ?
Que contiennent les dossiers "startupitems, launchagents et lauchdaemons
du dossiers "bibliothèque" du disque dur ?
> Un truc classique, c'est l'indexage. Mais il me semble que l'on voit
> alors le processus mds prendre le CPU, pas le Finder lui-même.
Exact
> La config : MacBook Pro, 8 Go ram, disque SSD, Mac OS X 10.6.4
Concernant le ssd, essaye de désactiver l'écriture des dates de dernier
accès : recherche dans Google la procédure pour modifier le montage avec
l'option "no atime"
Olivier Marti wrote:
> Bonjour,
>
> Depuis quelques jours, je constate que le Finder prend en permance 60
> à
> 100% de CPU. Je ne pense pas que c'était le cas avant (j'ai les jauges
> CPU de Menu Meter dans la barre de menu). Ce problème résiste à
> plusieurs redémmarrages.
>
> Ca ne me parait pas normal, mais je ne sais pas comment faire un
> diagnostic plus précis et corriger ça.
>
> Une idée ?
Tu as pas le calcul de taille de dossiers activé par défaut ?
Pas de connexion à un serveur, à un iDisk ?
Pas de candybar, de "haxies" unsanity,
de partage de dossier avec parallels ?
Quels sont les éléments d'ouverture dans les préférences système, rubrique
comptes ?
Que contiennent les dossiers "startupitems, launchagents et lauchdaemons
du dossiers "bibliothèque" du disque dur ?
> Un truc classique, c'est l'indexage. Mais il me semble que l'on voit
> alors le processus mds prendre le CPU, pas le Finder lui-même.
Exact
> La config : MacBook Pro, 8 Go ram, disque SSD, Mac OS X 10.6.4
Concernant le ssd, essaye de désactiver l'écriture des dates de dernier
accès : recherche dans Google la procédure pour modifier le montage avec
l'option "no atime"
> Tu as pas le calcul de taille de dossiers activé par défaut ?
Si, et en le désactivant ça à l'air d'aller beaucoup mieux. Ca me parait
bizarre : sur mon MacBook avec disque dur ça ne posait pas vraiment de
problème. J'ai tout migré sur un MacBookPro avec SSD, et ça me fait ça
???
com.adobe.CS4ServiceManager.plist
com.adobe.versioncueCS4.plist
com.dilaroga.itaf_d.plist
> Concernant le ssd, essaye de désactiver l'écriture des dates de dernier
> accès : recherche dans Google la procédure pour modifier le montage avec
> l'option "no atime"
On verra plus tard. Pour l'instant le coup de la taille des dossiers à
l'air efficace.
> Tu as pas le calcul de taille de dossiers activé par défaut ?
Si, et en le désactivant ça à l'air d'aller beaucoup mieux. Ca me parait
bizarre : sur mon MacBook avec disque dur ça ne posait pas vraiment de
problème. J'ai tout migré sur un MacBookPro avec SSD, et ça me fait ça
???
com.adobe.CS4ServiceManager.plist
com.adobe.versioncueCS4.plist
com.dilaroga.itaf_d.plist
> Concernant le ssd, essaye de désactiver l'écriture des dates de dernier
> accès : recherche dans Google la procédure pour modifier le montage avec
> l'option "no atime"
On verra plus tard. Pour l'instant le coup de la taille des dossiers à
l'air efficace.
> Tu as pas le calcul de taille de dossiers activé par défaut ?
Si, et en le désactivant ça à l'air d'aller beaucoup mieux. Ca me parait
bizarre : sur mon MacBook avec disque dur ça ne posait pas vraiment de
problème. J'ai tout migré sur un MacBookPro avec SSD, et ça me fait ça
???
com.adobe.CS4ServiceManager.plist
com.adobe.versioncueCS4.plist
com.dilaroga.itaf_d.plist
> Concernant le ssd, essaye de désactiver l'écriture des dates de dernier
> accès : recherche dans Google la procédure pour modifier le montage avec
> l'option "no atime"
On verra plus tard. Pour l'instant le coup de la taille des dossiers à
l'air efficace.
Olivier Marti wrote:
> > Tu as pas le calcul de taille de dossiers activé par défaut ?
>
> Si, et en le désactivant ça à l'air d'aller beaucoup mieux. Ca me parait
> bizarre : sur mon MacBook avec disque dur ça ne posait pas vraiment de
> problème. J'ai tout migré sur un MacBookPro avec SSD, et ça me fait ça
> ???
A mettre en corélation avec l'option "no atime".
un SSD peu lire des données par bloc, mais ne peut les écrire que par
pages. Autrement dit, on peut lire des données par paquets de 512
octets, mais chaque minuscule écriture oblige le SSD à lire la page
entière, et la réécrire toute avec le seule petit bloc modifié...
Ceci n'est pas génant dans la plupart des cas, mais MacOS X par défaut,
mémorise la date d'accès des fichiers (ce qu'on peut désactiver par
l'option noatime)
Avec les SSD ça ne fait pas bon ménage, car ça augmente terriblement le
nombres d'écritures et ralentit énormément le fonctionnement du SSD.
Je ne suis pas absolument certain de moi, mais je pense que dans une
certaine mesure le fait de demander au finder d'afficher la taille des
dossiers provoque aussi des réécritures de dernier temps d'accès...
choses qui sont à priori bien améliorées en activant le montage avec
"noatime"
> com.adobe.CS4ServiceManager.plist
> com.adobe.versioncueCS4.plist
tu t'en sers ?
> com.dilaroga.itaf_d.plist
celui-ci semble causer des soucis avec Snow leopard d'après son auteur.
même si tu te sers d'itaf il faudrait supprimer ce plist.
> > Concernant le ssd, essaye de désactiver l'écriture des dates de dernier
> > accès : recherche dans Google la procédure pour modifier le montage avec
> > l'option "no atime"
>
> On verra plus tard. Pour l'instant le coup de la taille des dossiers à
> l'air efficace.
Ok super.
Si tu peux essaye quand même l'option noatime.
J'utilise un ssd intel depuis un an, et j'ai essayé sans et avec
l'option "noatime", c'est vraiment plus rapide avec (perso j'ai beaucoup
de dossiers avec l'affichage de taille, et pas de problème d'occupation
CPU du finder)
De plus ça m'intéresse d'avoir ton retour si ça améliore les choses :-)
Enfin, je pense que cette option aide le SSD à ne pas trop user ses
"cellules" ce qui est important sur les MLC.
Olivier Marti <olivier.marti@ensta.org> wrote:
> > Tu as pas le calcul de taille de dossiers activé par défaut ?
>
> Si, et en le désactivant ça à l'air d'aller beaucoup mieux. Ca me parait
> bizarre : sur mon MacBook avec disque dur ça ne posait pas vraiment de
> problème. J'ai tout migré sur un MacBookPro avec SSD, et ça me fait ça
> ???
A mettre en corélation avec l'option "no atime".
un SSD peu lire des données par bloc, mais ne peut les écrire que par
pages. Autrement dit, on peut lire des données par paquets de 512
octets, mais chaque minuscule écriture oblige le SSD à lire la page
entière, et la réécrire toute avec le seule petit bloc modifié...
Ceci n'est pas génant dans la plupart des cas, mais MacOS X par défaut,
mémorise la date d'accès des fichiers (ce qu'on peut désactiver par
l'option noatime)
Avec les SSD ça ne fait pas bon ménage, car ça augmente terriblement le
nombres d'écritures et ralentit énormément le fonctionnement du SSD.
Je ne suis pas absolument certain de moi, mais je pense que dans une
certaine mesure le fait de demander au finder d'afficher la taille des
dossiers provoque aussi des réécritures de dernier temps d'accès...
choses qui sont à priori bien améliorées en activant le montage avec
"noatime"
> com.adobe.CS4ServiceManager.plist
> com.adobe.versioncueCS4.plist
tu t'en sers ?
> com.dilaroga.itaf_d.plist
celui-ci semble causer des soucis avec Snow leopard d'après son auteur.
même si tu te sers d'itaf il faudrait supprimer ce plist.
> > Concernant le ssd, essaye de désactiver l'écriture des dates de dernier
> > accès : recherche dans Google la procédure pour modifier le montage avec
> > l'option "no atime"
>
> On verra plus tard. Pour l'instant le coup de la taille des dossiers à
> l'air efficace.
Ok super.
Si tu peux essaye quand même l'option noatime.
J'utilise un ssd intel depuis un an, et j'ai essayé sans et avec
l'option "noatime", c'est vraiment plus rapide avec (perso j'ai beaucoup
de dossiers avec l'affichage de taille, et pas de problème d'occupation
CPU du finder)
De plus ça m'intéresse d'avoir ton retour si ça améliore les choses :-)
Enfin, je pense que cette option aide le SSD à ne pas trop user ses
"cellules" ce qui est important sur les MLC.
Olivier Marti wrote:
> > Tu as pas le calcul de taille de dossiers activé par défaut ?
>
> Si, et en le désactivant ça à l'air d'aller beaucoup mieux. Ca me parait
> bizarre : sur mon MacBook avec disque dur ça ne posait pas vraiment de
> problème. J'ai tout migré sur un MacBookPro avec SSD, et ça me fait ça
> ???
A mettre en corélation avec l'option "no atime".
un SSD peu lire des données par bloc, mais ne peut les écrire que par
pages. Autrement dit, on peut lire des données par paquets de 512
octets, mais chaque minuscule écriture oblige le SSD à lire la page
entière, et la réécrire toute avec le seule petit bloc modifié...
Ceci n'est pas génant dans la plupart des cas, mais MacOS X par défaut,
mémorise la date d'accès des fichiers (ce qu'on peut désactiver par
l'option noatime)
Avec les SSD ça ne fait pas bon ménage, car ça augmente terriblement le
nombres d'écritures et ralentit énormément le fonctionnement du SSD.
Je ne suis pas absolument certain de moi, mais je pense que dans une
certaine mesure le fait de demander au finder d'afficher la taille des
dossiers provoque aussi des réécritures de dernier temps d'accès...
choses qui sont à priori bien améliorées en activant le montage avec
"noatime"
> com.adobe.CS4ServiceManager.plist
> com.adobe.versioncueCS4.plist
tu t'en sers ?
> com.dilaroga.itaf_d.plist
celui-ci semble causer des soucis avec Snow leopard d'après son auteur.
même si tu te sers d'itaf il faudrait supprimer ce plist.
> > Concernant le ssd, essaye de désactiver l'écriture des dates de dernier
> > accès : recherche dans Google la procédure pour modifier le montage avec
> > l'option "no atime"
>
> On verra plus tard. Pour l'instant le coup de la taille des dossiers à
> l'air efficace.
Ok super.
Si tu peux essaye quand même l'option noatime.
J'utilise un ssd intel depuis un an, et j'ai essayé sans et avec
l'option "noatime", c'est vraiment plus rapide avec (perso j'ai beaucoup
de dossiers avec l'affichage de taille, et pas de problème d'occupation
CPU du finder)
De plus ça m'intéresse d'avoir ton retour si ça améliore les choses :-)
Enfin, je pense que cette option aide le SSD à ne pas trop user ses
"cellules" ce qui est important sur les MLC.
Olivier Marti wrote:
> > Tu as pas le calcul de taille de dossiers activé par défaut ?
>
> Si, et en le désactivant ça à l'air d'aller beaucoup mieux. Ca me parait
> bizarre : sur mon MacBook avec disque dur ça ne posait pas vraiment de
> problème. J'ai tout migré sur un MacBookPro avec SSD, et ça me fait ça
Ok super.
Si tu peux essaye quand même l'option noatime.
J'utilise un ssd intel depuis un an, et j'ai essayé sans et avec
l'option "noatime", c'est vraiment plus rapide avec (perso j'ai beaucoup
de dossiers avec l'affichage de taille, et pas de problème d'occupation
CPU du finder)
De plus ça m'intéresse d'avoir ton retour si ça améliore les choses :-)
Enfin, je pense que cette option aide le SSD à ne pas trop user ses
"cellules" ce qui est important sur les MLC.
Olivier Marti <olivier.marti@ensta.org> wrote:
> > Tu as pas le calcul de taille de dossiers activé par défaut ?
>
> Si, et en le désactivant ça à l'air d'aller beaucoup mieux. Ca me parait
> bizarre : sur mon MacBook avec disque dur ça ne posait pas vraiment de
> problème. J'ai tout migré sur un MacBookPro avec SSD, et ça me fait ça
Ok super.
Si tu peux essaye quand même l'option noatime.
J'utilise un ssd intel depuis un an, et j'ai essayé sans et avec
l'option "noatime", c'est vraiment plus rapide avec (perso j'ai beaucoup
de dossiers avec l'affichage de taille, et pas de problème d'occupation
CPU du finder)
De plus ça m'intéresse d'avoir ton retour si ça améliore les choses :-)
Enfin, je pense que cette option aide le SSD à ne pas trop user ses
"cellules" ce qui est important sur les MLC.
Olivier Marti wrote:
> > Tu as pas le calcul de taille de dossiers activé par défaut ?
>
> Si, et en le désactivant ça à l'air d'aller beaucoup mieux. Ca me parait
> bizarre : sur mon MacBook avec disque dur ça ne posait pas vraiment de
> problème. J'ai tout migré sur un MacBookPro avec SSD, et ça me fait ça
Ok super.
Si tu peux essaye quand même l'option noatime.
J'utilise un ssd intel depuis un an, et j'ai essayé sans et avec
l'option "noatime", c'est vraiment plus rapide avec (perso j'ai beaucoup
de dossiers avec l'affichage de taille, et pas de problème d'occupation
CPU du finder)
De plus ça m'intéresse d'avoir ton retour si ça améliore les choses :-)
Enfin, je pense que cette option aide le SSD à ne pas trop user ses
"cellules" ce qui est important sur les MLC.
J'ai trouvé les instructions complètes sur nullvision. Ca marche.
~:mount
/dev/disk0s2 on / (hfs, local, journaled, noatime)
Mais si je remet le calcul des tailles, dès qu'une fenêtre du Finder est
ouverte le CPU repart à fond ....
Je vais suivre un peu ça pour voir comment ça se comporte sur le long
terme.
Sinon il y a un mystère pour moi, dans la méthode proposée par
nullvision : pour lire un fichier, il faut que le disque soit monté.
Donc comment un fichier sur le disque peut-il affecter le montage du
disque ? Ca m'intrigue ! Il y a écriture d'information dans la PRAM
avant le redémarrage ?
J'ai trouvé les instructions complètes sur nullvision. Ca marche.
marti@Spip-~:mount
/dev/disk0s2 on / (hfs, local, journaled, noatime)
Mais si je remet le calcul des tailles, dès qu'une fenêtre du Finder est
ouverte le CPU repart à fond ....
Je vais suivre un peu ça pour voir comment ça se comporte sur le long
terme.
Sinon il y a un mystère pour moi, dans la méthode proposée par
nullvision : pour lire un fichier, il faut que le disque soit monté.
Donc comment un fichier sur le disque peut-il affecter le montage du
disque ? Ca m'intrigue ! Il y a écriture d'information dans la PRAM
avant le redémarrage ?
J'ai trouvé les instructions complètes sur nullvision. Ca marche.
~:mount
/dev/disk0s2 on / (hfs, local, journaled, noatime)
Mais si je remet le calcul des tailles, dès qu'une fenêtre du Finder est
ouverte le CPU repart à fond ....
Je vais suivre un peu ça pour voir comment ça se comporte sur le long
terme.
Sinon il y a un mystère pour moi, dans la méthode proposée par
nullvision : pour lire un fichier, il faut que le disque soit monté.
Donc comment un fichier sur le disque peut-il affecter le montage du
disque ? Ca m'intrigue ! Il y a écriture d'information dans la PRAM
avant le redémarrage ?
J'ai trouvé les instructions complètes sur nullvision. Ca marche.
~:mount
/dev/disk0s2 on / (hfs, local, journaled, noatime)
Mais si je remet le calcul des tailles, dès qu'une fenêtre du Finder est
ouverte le CPU repart à fond ....
Je vais suivre un peu ça pour voir comment ça se comporte sur le long
terme.
Sinon il y a un mystère pour moi, dans la méthode proposée par
nullvision : pour lire un fichier, il faut que le disque soit monté.
Donc comment un fichier sur le disque peut-il affecter le montage du
disque ? Ca m'intrigue ! Il y a écriture d'information dans la PRAM
avant le redémarrage ?
J'ai trouvé les instructions complètes sur nullvision. Ca marche.
marti@Spip-~:mount
/dev/disk0s2 on / (hfs, local, journaled, noatime)
Mais si je remet le calcul des tailles, dès qu'une fenêtre du Finder est
ouverte le CPU repart à fond ....
Je vais suivre un peu ça pour voir comment ça se comporte sur le long
terme.
Sinon il y a un mystère pour moi, dans la méthode proposée par
nullvision : pour lire un fichier, il faut que le disque soit monté.
Donc comment un fichier sur le disque peut-il affecter le montage du
disque ? Ca m'intrigue ! Il y a écriture d'information dans la PRAM
avant le redémarrage ?
J'ai trouvé les instructions complètes sur nullvision. Ca marche.
~:mount
/dev/disk0s2 on / (hfs, local, journaled, noatime)
Mais si je remet le calcul des tailles, dès qu'une fenêtre du Finder est
ouverte le CPU repart à fond ....
Je vais suivre un peu ça pour voir comment ça se comporte sur le long
terme.
Sinon il y a un mystère pour moi, dans la méthode proposée par
nullvision : pour lire un fichier, il faut que le disque soit monté.
Donc comment un fichier sur le disque peut-il affecter le montage du
disque ? Ca m'intrigue ! Il y a écriture d'information dans la PRAM
avant le redémarrage ?
Olivier Marti wrote:
> J'ai trouvé les instructions complètes sur nullvision. Ca marche.
>
> ~:mount
> /dev/disk0s2 on / (hfs, local, journaled, noatime)
c'est ok donc.
> Mais si je remet le calcul des tailles, dès qu'une fenêtre du Finder est
> ouverte le CPU repart à fond ....
>
> Je vais suivre un peu ça pour voir comment ça se comporte sur le long
> terme.
Ok.
Une question : tu as cloné ton système depuis l'ancien disque ?
As-tu nettoyé les fichiers caches depuis ?
Essaie soit à la main (dossier "com.apple.finder" dans le dossier
"caches").
Tu peux aussi faire un nettoyage soit avec "snow leopard cache cleaner",
soit avec Onyx :
- dans l'onglet "maintenance" cocher les caches dyld
- dans l'onglet "nettoyage", supprimer les caches system et utilisateur
redémarrer.
Est-ce que tout le contenu de ton dossier "utilisateurs" a le bon
propriétaire ?
Pour corriger, c'est un peu brutal mais tu peux faire un chmod récursif
dans ton dossier utilisateur :
chmod -R 501:501 *
(bien sûr, à supposer que 501 est bien l'uid de ton utilisateur)
Tu peux aussi ouvrir la fenêtre de ton dossier départ, décocher
"calculer toutes les tailles", définir cet option par défaut, puis
dossier par dossier, cocher "calculer les tailles" jusqu'à trouver celui
qui "emballe" le finder
> Sinon il y a un mystère pour moi, dans la méthode proposée par
> nullvision : pour lire un fichier, il faut que le disque soit monté.
> Donc comment un fichier sur le disque peut-il affecter le montage du
> disque ? Ca m'intrigue ! Il y a écriture d'information dans la PRAM
> avant le redémarrage ?
En fait lors du boot il n'y a pas besoin que le système de fichier soit
en lecture écriture dès le départ.
Lors du boot, l'EFI commence par passer le relais au bootloader
(boot-efi qui est dans le dossier coreservices), qui passe la main au
noyau qui lui même passe la main à launchd.
Jusqu'au lancement de launchd, tout se passe en lecture seule.
Le volume de boot est ensuite remonté dynamiquement en lecture /
ecriture (sous linux par init.d qui lit fstab, sous MacOS je sais
pas...)
cf :
http://developer.apple.com/library/mac/#DOCUMENTATION/MacOSX/Conceptual/
BPSystemStartup/Articles/BootProcess.html
Concernant le montage noatime, avec la méthode décrite, on ne le remonte
en lecture/ecriture avec le petit fichier daemon, avec les attributs
noatime, qu'au milieu du boot.
On pourrait tout aussi bien le faire à la fin du boot ou même deux
heures après...
Olivier Marti <olivier.marti@ensta.org> wrote:
> J'ai trouvé les instructions complètes sur nullvision. Ca marche.
>
> marti@Spip-~:mount
> /dev/disk0s2 on / (hfs, local, journaled, noatime)
c'est ok donc.
> Mais si je remet le calcul des tailles, dès qu'une fenêtre du Finder est
> ouverte le CPU repart à fond ....
>
> Je vais suivre un peu ça pour voir comment ça se comporte sur le long
> terme.
Ok.
Une question : tu as cloné ton système depuis l'ancien disque ?
As-tu nettoyé les fichiers caches depuis ?
Essaie soit à la main (dossier "com.apple.finder" dans le dossier
"caches").
Tu peux aussi faire un nettoyage soit avec "snow leopard cache cleaner",
soit avec Onyx :
- dans l'onglet "maintenance" cocher les caches dyld
- dans l'onglet "nettoyage", supprimer les caches system et utilisateur
redémarrer.
Est-ce que tout le contenu de ton dossier "utilisateurs" a le bon
propriétaire ?
Pour corriger, c'est un peu brutal mais tu peux faire un chmod récursif
dans ton dossier utilisateur :
chmod -R 501:501 *
(bien sûr, à supposer que 501 est bien l'uid de ton utilisateur)
Tu peux aussi ouvrir la fenêtre de ton dossier départ, décocher
"calculer toutes les tailles", définir cet option par défaut, puis
dossier par dossier, cocher "calculer les tailles" jusqu'à trouver celui
qui "emballe" le finder
> Sinon il y a un mystère pour moi, dans la méthode proposée par
> nullvision : pour lire un fichier, il faut que le disque soit monté.
> Donc comment un fichier sur le disque peut-il affecter le montage du
> disque ? Ca m'intrigue ! Il y a écriture d'information dans la PRAM
> avant le redémarrage ?
En fait lors du boot il n'y a pas besoin que le système de fichier soit
en lecture écriture dès le départ.
Lors du boot, l'EFI commence par passer le relais au bootloader
(boot-efi qui est dans le dossier coreservices), qui passe la main au
noyau qui lui même passe la main à launchd.
Jusqu'au lancement de launchd, tout se passe en lecture seule.
Le volume de boot est ensuite remonté dynamiquement en lecture /
ecriture (sous linux par init.d qui lit fstab, sous MacOS je sais
pas...)
cf :
http://developer.apple.com/library/mac/#DOCUMENTATION/MacOSX/Conceptual/
BPSystemStartup/Articles/BootProcess.html
Concernant le montage noatime, avec la méthode décrite, on ne le remonte
en lecture/ecriture avec le petit fichier daemon, avec les attributs
noatime, qu'au milieu du boot.
On pourrait tout aussi bien le faire à la fin du boot ou même deux
heures après...
Olivier Marti wrote:
> J'ai trouvé les instructions complètes sur nullvision. Ca marche.
>
> ~:mount
> /dev/disk0s2 on / (hfs, local, journaled, noatime)
c'est ok donc.
> Mais si je remet le calcul des tailles, dès qu'une fenêtre du Finder est
> ouverte le CPU repart à fond ....
>
> Je vais suivre un peu ça pour voir comment ça se comporte sur le long
> terme.
Ok.
Une question : tu as cloné ton système depuis l'ancien disque ?
As-tu nettoyé les fichiers caches depuis ?
Essaie soit à la main (dossier "com.apple.finder" dans le dossier
"caches").
Tu peux aussi faire un nettoyage soit avec "snow leopard cache cleaner",
soit avec Onyx :
- dans l'onglet "maintenance" cocher les caches dyld
- dans l'onglet "nettoyage", supprimer les caches system et utilisateur
redémarrer.
Est-ce que tout le contenu de ton dossier "utilisateurs" a le bon
propriétaire ?
Pour corriger, c'est un peu brutal mais tu peux faire un chmod récursif
dans ton dossier utilisateur :
chmod -R 501:501 *
(bien sûr, à supposer que 501 est bien l'uid de ton utilisateur)
Tu peux aussi ouvrir la fenêtre de ton dossier départ, décocher
"calculer toutes les tailles", définir cet option par défaut, puis
dossier par dossier, cocher "calculer les tailles" jusqu'à trouver celui
qui "emballe" le finder
> Sinon il y a un mystère pour moi, dans la méthode proposée par
> nullvision : pour lire un fichier, il faut que le disque soit monté.
> Donc comment un fichier sur le disque peut-il affecter le montage du
> disque ? Ca m'intrigue ! Il y a écriture d'information dans la PRAM
> avant le redémarrage ?
En fait lors du boot il n'y a pas besoin que le système de fichier soit
en lecture écriture dès le départ.
Lors du boot, l'EFI commence par passer le relais au bootloader
(boot-efi qui est dans le dossier coreservices), qui passe la main au
noyau qui lui même passe la main à launchd.
Jusqu'au lancement de launchd, tout se passe en lecture seule.
Le volume de boot est ensuite remonté dynamiquement en lecture /
ecriture (sous linux par init.d qui lit fstab, sous MacOS je sais
pas...)
cf :
http://developer.apple.com/library/mac/#DOCUMENTATION/MacOSX/Conceptual/
BPSystemStartup/Articles/BootProcess.html
Concernant le montage noatime, avec la méthode décrite, on ne le remonte
en lecture/ecriture avec le petit fichier daemon, avec les attributs
noatime, qu'au milieu du boot.
On pourrait tout aussi bien le faire à la fin du boot ou même deux
heures après...
J'ai vidé les caches (systèmes comme utilisateurs). J'ai corrigé le
propriétaire des fichiers dans mon dossier utilisateur.
Le problème subsiste.
Clairement, c'est ~/Library qui est en cause. Mais si j'ouvre un par un
les dossiers qui sont dedans, le problème disparait. J'ai aussi enlevé
les fichiers qui sont dans ~/Library pour voir. En affichant les
fichiers cachés pour être sûr de mon coup. Pas mieux.
Donc le soucis est dans ~/Library, mais dans aucun de ses sous-dossiers
... ?????
J'ai vidé les caches (systèmes comme utilisateurs). J'ai corrigé le
propriétaire des fichiers dans mon dossier utilisateur.
Le problème subsiste.
Clairement, c'est ~/Library qui est en cause. Mais si j'ouvre un par un
les dossiers qui sont dedans, le problème disparait. J'ai aussi enlevé
les fichiers qui sont dans ~/Library pour voir. En affichant les
fichiers cachés pour être sûr de mon coup. Pas mieux.
Donc le soucis est dans ~/Library, mais dans aucun de ses sous-dossiers
... ?????
J'ai vidé les caches (systèmes comme utilisateurs). J'ai corrigé le
propriétaire des fichiers dans mon dossier utilisateur.
Le problème subsiste.
Clairement, c'est ~/Library qui est en cause. Mais si j'ouvre un par un
les dossiers qui sont dedans, le problème disparait. J'ai aussi enlevé
les fichiers qui sont dans ~/Library pour voir. En affichant les
fichiers cachés pour être sûr de mon coup. Pas mieux.
Donc le soucis est dans ~/Library, mais dans aucun de ses sous-dossiers
... ?????