Re: Finder qui prend tout le CPU
Anne G
>
> 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 vois
> 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
comme largo, je crois qu'il vaudrait mieux faire suivre où de droit...
(Xpost et FU2)
Fra
> 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 vois
> 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
Les macounets sont des bricoleurs ! ;)
fu2 idoine.
--
Fra
Olivier Marti
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
Gilles Aurejac
> 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.
>
>
> 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 <olivie...@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 ?
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
???
> Pas de connexion à un serveur, à un iDisk ?
> Pas de candybar, de "haxies" unsanity,
Non
> de partage de dossier avec parallels ?
Avec Virtual Box. Mais ce dernier ne me sert quasiment jamais, il n'est
pas démarré.
> Quels sont les éléments d'ouverture dans les préférences système, rubrique
> comptes ?
iTunesHelper
LaunchBar
ClamXavsentry
MissingSyncMonitor
PopCHar
Weather Dock
Auto Mute
iController
Magic Pref
start-gpg-agent
et Radoshift Helper que j'avais essayé mais que je vais virer de ce pas.
Mais tout ces trucs apparaisent sous leur propre nom dans Moniteur
d'Activité.
> Que contiennent les dossiers "startupitems, launchagents et lauchdaemons
> du dossiers "bibliothèque" du disque dur ?
marti@Spip-~:ls /Library/LaunchAgents/
at.obdev.LittleSnitchNetworkMonitor.plist
com.machangout.glims.agent.plist
at.obdev.LittleSnitchUIAgent.plist
com.sourceforge.macgpg2.gpg-agent.plist
com.adobe.CS4ServiceManager.plist
net.culater.SIMBL.Agent.plist
com.google.keystone.agent.plist
org.freedesktop.dbus-session.plist@
marti@Spip-~:ls /Library/StartupItems/
VirtualBox/
daemonic-dbus/
marti@Spip-~:ls /Library/LaunchDaemons/
at.obdev.littlesnitchd.plist
com.adobe.versioncueCS4.plist
com.bombich.ccc.plist
com.bombich.ccc.scheduledtask.CF7ADB41-732E-4AE8-861A-6DC81490E6A3.plist
com.bresink.system.securityagent.plist
com.dilaroga.itaf_d.plist
com.eltima.ElmediaPlayer.daemon.plist*
com.google.keystone.daemon.plist
com.juicybinary.slntfsDaemon.plist
com.rogueamoeba.hermes.plist
org.freedesktop.dbus-system.plist@
org.macports.OpenSSH.plist@
org.macports.frameworks.macports.plist
>
>
> > 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"
On verra plus tard. Pour l'instant le coup de la taille des dossiers à
l'air efficace.
Olivier
Gilles Aurejac
> > 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.
--
le guide de la Ram, h�berg� sur disquette par un MacPortable de 1989 :
http://aurejac.dyndns.org
Olivier Marti
> Olivier Marti <olivie...@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"
OK. Mais je trouvais pratique de connaitre la date de dernier accès. Il
faut que j'y réfléchisse.
>
>
> > com.adobe.CS4ServiceManager.plist
> > com.adobe.versioncueCS4.plist
>
> tu t'en sers ?
>
Non !
Mais dans une version précédente d'Adobe, j'avais voulu le supprimer, et
les applications Adobe n'arrétaient pas de râler. Il faut que je trouve
la façon propre de le faire.
> > 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.
Oui, ITAF provoquait le réveil du Mac régulièrement. Pas possible de le
mettre en veille ... Je pensais avoir enlevé tous les morceaux.
>
> > > 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.
Oui, je vais faire des essais. D'autant que ça a l'air bon pour la durée
de vie du SSD.
Merci pour tout, et surtout tes très intéressants explications.
Olivier
Olivier Marti
> Olivier Marti <olivie...@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.
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 ?
Olivier
Gilles Aurejac
> 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, 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 ? tu peux faire un chmod r�cursif (chmod -R 501:501 * dans
ton dossier utilisateur) pour v�rifier... c'est bourrin !
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...
Gilles Aurejac
> 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
> Olivier Marti <olivie...@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").
Oui, j'ai clonￜ. Je vais donc nettoyer les caches. Mais aprￜs l'ￜtape
suivante.
> 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 veux parler de chown ?
J'ai une grosse 20aine de fichiers qui ne m'appartiennent pas.
marti@Spip-~:find . ! -user marti -print
./Library/Application Support/Adobe/Acrobat/SpellingDictionary0.log
./Library/Application Support/Back-In-Time 2/Alias
./Library/Application Support/Back-In-Time 2/Alias/Alias dￜsativￜs (ￜ ne
pas monter)
./Library/Application Support/Back-In-Time 2/Alias/SparseBundle Disk
Image
./Library/Application Support/Back-In-Time 2/Alias/Time Machine Disk
./Library/Application Support/Back-In-Time 2/Back-In-Time History.txt
./Library/Application
Support/Firefox/Profiles/ui7e0hlq.default/cookies.txt
./Library/Application Support/Little Snitch/rules.xpl
./Library/Application
Support/OpenOffice.org/3/user/registry/data/org/openoffice/Office/Math.x
cu
./Library/Application Support/RealNetworks/RPDLAgentHelperE
./Library/Application Support/RealNetworks/RPDLAgentHelperI
./Library/Favorites/Documents
./Library/PreferencePanes/BlueHarvest.prefPane/Contents/Resources/BlueHa
rvest.app/Contents/MacOS/BlueHarvest
./Library/PreferencePanes/BlueHarvest.prefPane/Contents/Resources/BlueHa
rvest.app/Contents/Resources/clean-tar
./Library/PreferencePanes/BlueHarvest.prefPane/Contents/Resources/BlueHa
rvest.app/Contents/Resources/count-tar-metadata
./Library/Preferences/.com.apple.dashboard.backup
./Library/Preferences/.com.apple.dock.backup
./Library/Preferences/.com.apple.finder.backup
./Library/Preferences/.com.apple.mail.backup
./Library/Preferences/.com.apple.Safari.backup
./Library/Preferences/.com.apple.Terminal.backup
./Library/Preferences/MacScan Statistics.plist
./Library/texmf/ls-R
./Pictures/iChat Icons
./Public/Logiciels/VPN/Apani Contivity VPN Client.url
La plupart appartiennent ￜ root:marti.
Je viens de faire le chown, et le Finder turbine toujour ....
> 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
Je prend note, mais j'essaye le reste d'abord, car ï¿œa peut ï¿œtre un peu
fastidieux.
> > 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...)
Merci pour toutes ces infos.
>
> cf :
> http://developer.apple.com/library/mac/#DOCUMENTATION/MacOSX/Conceptual/
> BPSystemStartup/Articles/BootProcess.html
J'avais lu ï¿œa il y a longtemps. Je vais jeter un ï¿œil de nouveau.
> 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...
OK.
Bon, je continue mes tests.
Merci mille fois de tes infos et de tes conseils.
Olivier
Olivier Marti
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
... ?????
Bon, rien de grave puisque je me passe très bien de la taille des
dossiers en général.
Mais c'est vraiment bizarre ...
Olivier
Gilles Aurejac
> 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
> ... ?????
Etrange...
tu as donc supprimé les fichiers commençant par un point ?
Tu peux éventuellement créer un nouveau dossier "library", à la volée :
renommer le dossier library (mv Library Library_old) puis en recréer un
(mkdir Library), recopier immédiatement les dossiers venant de l'ancien
dossier Library, et rajouter juste le fichier ".localized" (touch
.localized, ça c'est juste esthetique pour que le dossier soit bien
affiché "bibliothèque" dans le finder).
désolé pour ton problème, mais il est intriguant :-)
j'espère que tu profites bien du SSD quand même !
--
le guide de la Ram, hébergé sur disquette par un MacPortable de 1989 :
http://aurejac.dyndns.org
Olivier Marti
> Olivier Marti <olivie...@ensta.org> wrote:
>
> > 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
> > ... ?????
>
> Etrange...
> tu as donc supprimé les fichiers commençant par un point ?
Sauf .localized. J'ai supprimé .DStore qui s'est bien sûr recrée tout de
suite.
Je peut supprimer .localized, et le recréer (touch .localized). Ce
fichier est vide, donc ça doit suffire. Mais je voulais être sûr. Vu ce
que tu mets plus bas, je vais essayer.
> Tu peux éventuellement créer un nouveau dossier "library", à la volée :
> renommer le dossier library (mv Library Library_old) puis en recréer un
> (mkdir Library), recopier immédiatement les dossiers venant de l'ancien
> dossier Library, et rajouter juste le fichier ".localized" (touch
> .localized, ça c'est juste esthetique pour que le dossier soit bien
> affiché "bibliothèque" dans le finder).
J'ai un doute : Finder va me laisser supprimer des dossiers
"obligatoires" comme ~/Library/Assistants ou d'autres. Si je le fais à
la ligne de commande, probablement.
> désolé pour ton problème, mais il est intriguant :-)
Je me penche la dessus plus pour l'intrigue que parce que c'est vraiment
génant !!
>
> j'espère que tu profites bien du SSD quand même !
C'est un bonheur ce truc ! Le Mac est d'une fluidité dans toutes ses
tâches que je n'avais jamais vu !!!
Olivier
Olivier Marti
J'ai supprim� .localized sans succ�s ... !!
Je suis donc pass� � la phase suivante recopie du contenu de ~/Library
dans ~/Library_New, puis remplacament de Library par sa copie.
Cette fois �a marche !!!
Mais je n'ai rien compris ....
Et �a m'�nerve :-(
Tant pis ..
Et encore merci � Gilles pour cet �change.
Olivier