Soit un MB13 de 2006 (Core duo 1,83 Ghz) sous Snow Leopard tout juste
installé de neuf avec juste iphoto 9.2.3 + de quoi lire des epubs (adobe
digital editions 2.0).
Qu'il ventile comme un malade quand il répertorie les visages au 1er
lancement de iphoto, je veux bien car dès le second lancement, j'ai la
paix.
mais quand il ventile à donf dès le lancement du MB alors que rien n'est
lancé au démarrage, je trouve ça bizarre.
Et comme je suis infichue de lire ce qui apparaît dans la console...
Tiens, j'ai un autre truc : Les boutons fonction F pour la lumière ne fonctionnenet pas. Et quand je vais en veille profonde*, si le disque remonte bien et que je vois au travers que le bureau est bien réveillé, j'ai plus de lumière, je dois rebooter. J'ai déjà vu ça, mais j'ai le cerveau en bouillie concernant Snow. * : je ne suis plus sur le SSD, j'ai la place, j'ai réactivé sleepimage.
Tiens, j'ai un autre truc :
Les boutons fonction F pour la lumière ne fonctionnenet pas.
Et quand je vais en veille profonde*, si le disque remonte bien et que
je vois au travers que le bureau est bien réveillé, j'ai plus de
lumière, je dois rebooter.
J'ai déjà vu ça, mais j'ai le cerveau en bouillie concernant Snow.
* : je ne suis plus sur le SSD, j'ai la place, j'ai réactivé sleepimage.
Tiens, j'ai un autre truc : Les boutons fonction F pour la lumière ne fonctionnenet pas. Et quand je vais en veille profonde*, si le disque remonte bien et que je vois au travers que le bureau est bien réveillé, j'ai plus de lumière, je dois rebooter. J'ai déjà vu ça, mais j'ai le cerveau en bouillie concernant Snow. * : je ne suis plus sur le SSD, j'ai la place, j'ai réactivé sleepimage.
mv
michele n'a pas hésité à écrire :
Alors, j'y vais,
Merci. Cordialement -- Michel VAUQUOIS - http://michelvauquois.fr
michele <michele@inaccessible.org> n'a pas hésité à écrire :
Alors, j'y vais,
Merci.
Cordialement
--
Michel VAUQUOIS - http://michelvauquois.fr
Merci. Cordialement -- Michel VAUQUOIS - http://michelvauquois.fr
pehache
Le 08/04/2019 à 20:59, michele a écrit :
MV wrote:
Je n'ai pas la moindre idée de ce que ça peut signifier.
Alors, j'y vais, en espérant ne pas dire de c*nnerie. un SSD lit les données par bloc. Donc, quand il doit lire/écrire des petits paquets de 512 octets, il relit et réécrit la page entière au lieu du seul petit bloc modifié.
Le problème n'est pas là, car ce que tu décris ne diffère pas vraiment de ce qui se passe sur un HDD (si tu veux écrire un seul octet, il faut que le contrôleur lise le secteur de 512 octets qui contient l'octet, modifie l'octet, et réécrive le secteur). Sur un SSD : - le bloc élémentaire de lecture/écriture est plus gros (genre 4ko) - le contrôleur doit d'abord effacer un bloc avant de l'écrire - le bloc élémentaire d'effacement est encore plus gros (genre 128ko)
Pas gênant. Sauf que OS X, par défaut, mémorise la date d'accès des fichiers. Sur les SSD, y'a des chances que ça augmente le nombre d'écritures et ralentisse le SSD. Or, j'avais cliqué l'option "calculer toutes les tailles" dans les fenêtres de mac os pour quasiment chaque dossier. Et il me semble que le fait de demander au finder d'afficher la taille des dossiers provoque aussi des réécritures de dernier temps d'accès... qui ferait pédaler le finder à donf + chauffer le SSD et donc provoquer de la ventilation en réaction. Si je coche dans Chameleon l'option no atime (y'a une commande pour le terminal qui fait ça, mais je ne la connais pas), y'aura plus de mise à jour des dates. Donc, plus faire pédaler le finder et donc réduire le besoin de ventilation.
Mouais, j'ai quelques doutes. Déjà la taille d'un fichier est une métadonnée, donc simplement lire la taille ne devrait pas modifier la date d'accès au fichier lui-même (ou alors le Finder s'y prend comme un manche).
Le 08/04/2019 à 20:59, michele a écrit :
MV wrote:
> Je n'ai pas la moindre idée de ce que ça peut signifier.
Alors, j'y vais, en espérant ne pas dire de c*nnerie.
un SSD lit les données par bloc. Donc, quand il doit lire/écrire des
petits paquets de 512 octets, il relit et réécrit la page entière au
lieu du seul petit bloc modifié.
Le problème n'est pas là, car ce que tu décris ne diffère pas vraiment
de ce qui se passe sur un HDD (si tu veux écrire un seul octet, il faut
que le contrôleur lise le secteur de 512 octets qui contient l'octet,
modifie l'octet, et réécrive le secteur).
Sur un SSD :
- le bloc élémentaire de lecture/écriture est plus gros (genre 4ko)
- le contrôleur doit d'abord effacer un bloc avant de l'écrire
- le bloc élémentaire d'effacement est encore plus gros (genre 128ko)
Pas gênant. Sauf que OS X, par défaut, mémorise la date d'accès des
fichiers. Sur les SSD, y'a des chances que ça augmente le nombre
d'écritures et ralentisse le SSD.
Or, j'avais cliqué l'option "calculer toutes les tailles" dans les
fenêtres de mac os pour quasiment chaque dossier.
Et il me semble que le fait de demander au finder d'afficher la taille
des dossiers provoque aussi des réécritures de dernier temps d'accès...
qui ferait pédaler le finder à donf + chauffer le SSD et donc provoquer
de la ventilation en réaction.
Si je coche dans Chameleon l'option no atime (y'a une commande pour le
terminal qui fait ça, mais je ne la connais pas), y'aura plus de mise à
jour des dates. Donc, plus faire pédaler le finder et donc réduire le
besoin de ventilation.
Mouais, j'ai quelques doutes. Déjà la taille d'un fichier est une
métadonnée, donc simplement lire la taille ne devrait pas modifier la
date d'accès au fichier lui-même (ou alors le Finder s'y prend comme un
manche).
Je n'ai pas la moindre idée de ce que ça peut signifier.
Alors, j'y vais, en espérant ne pas dire de c*nnerie. un SSD lit les données par bloc. Donc, quand il doit lire/écrire des petits paquets de 512 octets, il relit et réécrit la page entière au lieu du seul petit bloc modifié.
Le problème n'est pas là, car ce que tu décris ne diffère pas vraiment de ce qui se passe sur un HDD (si tu veux écrire un seul octet, il faut que le contrôleur lise le secteur de 512 octets qui contient l'octet, modifie l'octet, et réécrive le secteur). Sur un SSD : - le bloc élémentaire de lecture/écriture est plus gros (genre 4ko) - le contrôleur doit d'abord effacer un bloc avant de l'écrire - le bloc élémentaire d'effacement est encore plus gros (genre 128ko)
Pas gênant. Sauf que OS X, par défaut, mémorise la date d'accès des fichiers. Sur les SSD, y'a des chances que ça augmente le nombre d'écritures et ralentisse le SSD. Or, j'avais cliqué l'option "calculer toutes les tailles" dans les fenêtres de mac os pour quasiment chaque dossier. Et il me semble que le fait de demander au finder d'afficher la taille des dossiers provoque aussi des réécritures de dernier temps d'accès... qui ferait pédaler le finder à donf + chauffer le SSD et donc provoquer de la ventilation en réaction. Si je coche dans Chameleon l'option no atime (y'a une commande pour le terminal qui fait ça, mais je ne la connais pas), y'aura plus de mise à jour des dates. Donc, plus faire pédaler le finder et donc réduire le besoin de ventilation.
Mouais, j'ai quelques doutes. Déjà la taille d'un fichier est une métadonnée, donc simplement lire la taille ne devrait pas modifier la date d'accès au fichier lui-même (ou alors le Finder s'y prend comme un manche).
