Yosemite : trim enabler ou pas trim enabler, pour finir ?

El lobo

Membre junior
9 Septembre 2014
52
1
Amérique centrale & sud
Bonjour tout le monde,

rapidement, et sans rentrer dans les détails, car ya de la matière sur ce forum pour ça, même beaucoup de problèmes, solutions, conseils, etc etc ....

Mais pour finir, sur Yosemite avec les SSD, il faut installer le Trim Enabler ou Garbage Collector ou rien ?

Car sur le forum, les conversations sont très technique, plein d'infos super intéressantes, plein de liens, de solutions a chaque problèmes, mais pour finir qu'en est il avec Yosemite, faut installer quoi ? (si besoin d'installer qql choses, sur ce nouveau OS X ??)

Je vais passer sur un ssd Crucial & instal clean de Yosemite, et malgré tout ce que j'ai lu, je suis pas très au clair, sur Yosemite, et ses options Trim.

J'ai pas besoin d'une réponse technique, ça j'ai trouver sur le forum, je veux juste savoir ce qu'il faut installer pour que ça fonctionne, et assurer une bonne longévité a mon ssd.

Donc TRIM ENABLER ou GARBAGE COLLECTOR ou RIEN car ce new OS X gère tout ?

Merci pour vos avis.
Cordialement.
Lobo
 

Locke

What am I doing here?
Modérateur
Club MacG
20 Juillet 2011
36 959
4 757

El lobo

Membre junior
9 Septembre 2014
52
1
Amérique centrale & sud
Hola tout le monde,

merci pour toute vos réponses, et les liens, c'est chouette.

En effet, ya de quoi discuter des heures sur ce sujet .... et comme ça suffit pas, notre ami Subsole, rajoute le Chameleon .... :rateau:

Pas évident de prendre LA bonne décision, il semble que ces logiciel de Trim sont tous bon, avec leur qualité et défauts certes, mais tous fonctionne, ce qui aide pas au choix.

Il y en pas un de vous si utilise, l'un d'eux ? Et, qui va me dire qu'il est facile d'usage, facile a comprendre, facile a manipuler, que c'est celui-la qu'il faut que je prenne, et point ? Vous vous mouillez pas beaucoup, lol .... :love:

Bon, je crois qu'il me faut plus de lecture sur ce sujet .... Merci encore pour vos avis Messieurs.

(Cela dit, le forum est bien remplis sur ce sujet, comme quoi ... je ne suis pas seul dans cette situation ... cool.)

Cordialement.
Lobo
 

Locke

What am I doing here?
Modérateur
Club MacG
20 Juillet 2011
36 959
4 757
Le fond du problème n'est pas la qualité des logiciels, ni de leur utilisation, mais de la modification d'un fichier système OS X qui risque de bloquer n'importe quel Mac sous Yosemite.

Connaissant le problème et sachant que chez Crucial le Garbage Collector est actif, le jeu en vaut-il la chandelle ?

Avec les autres OS X aucun problème pour activer/désactiver le Trim, même après avoir utilisé la commande PRAM.
 

Locke

What am I doing here?
Modérateur
Club MacG
20 Juillet 2011
36 959
4 757
A titre perso, si je devais installer Yosemite aujourd'hui, je n'activerai pas le Trim.

Sur mes 2 SSD Crucial, ce n'est plus activé. Reste à voir dans le temps ce que ça donne, mais je ne me fais pas de souci.
 

Ibiscus

Membre confirmé
30 Avril 2005
428
12
Si vous lisez tout ce qui a été écrit à ce sujet, Garbage Collector est un traitement complémentaire, mais qui ne remplace en aucun cas le TRIM.

Pour Sly54 : je vis dangereusement depuis plusieurs semaines :D

Pour info : attention à Onyx, plusieurs opérations mènent à la catastrophe. J'ai demandé sur le site Titanium à l'auteur de mettre un avertissement. Voir à ce sujet la démonstration de Macomaniac dans son style unique et érudit :
http://forums.macg.co/showpost.php?p=12809941&postcount=131
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
81 483
24 679
Forêt de Fontainebleau
Dans la toute dernière livraison d'«Onyx» (la version 2.9.1), l'auteur a judieusement édité les options par défaut des 2 panneaux devenus problématiques de son logiciel :

Automation

353230_original.png


Nettoyage

353495_original.png

Je trouve cette démarche particulièrement opportune --> sachant, en effet, qu'un certain nombre d'utilisateurs sont amenés à opérer - périodiquement ou en cas d'urgence - "un coup d'«Onyx" (selon leur expression qui m'a toujours paru une énigme intellectuelle, jusqu'à ce que je m'avise qu'ils entendaient par là l'exécution successive des options cochées par défaut des panneaux Nettoyage & Automation :D) ; et comme chez un nombre notable d'entre eux doit se rencontrer la combinaison des 3 facteurs : OS «Yosemite» instruisant le kext_signing x SSD de Tierce-Partie x activation de «Trim Enabler» - alors l'exécution de la suppression des caches-système proposée par défaut dans les versions antérieures d'«Onyx» n'aurait pas manqué de planter leur Mac devant le panneau d'interdiction de stationner (je reviens plus bas sur la raison de cet 'effet' que j'avais déjà essayé de décortiquer ici [TRIM] Yosemite et son bridage au message #131 et qui avait alerté le développeur d'«Onyx» : voir son message #140).

Il ne serait pas souhaitable, en effet, que la réputation du logiciel «Onyx», qui est grande, vienne à être entachée de soupçons de dangerosité, parce que telle option de Nettoyage ou d'Automation proposée par défaut conduirait à un plantage d'un certain nombre de Macs. L'avertissement explicite, affiché par l'auteur en regard de l'option de suppression des caches-système non cochée désormais par défaut, ne peut qu'inciter les utilisateurs ayant activé «Trim Enabler » à y regarder à deux fois avant de cocher la case fatidique et à en exécuter l'option. Ils ne pourront s'en prendre qu'à eux-mêmes si leur Mac plante.

♤

J'aurais juste une dernière petite question avant de prendre congé ("Inspecteur Columbo, sors du corps de macomaniac!" :D) : comme je l'ai souligné dans une annotation en vert de ma capture du panneau Nettoyage/Système d'«Onyx», j'ai un doute raisonnable concernant l'option demeurée cochée par défaut : Supprimer les fichiers Cache : Démarrage.

En effet, dans mon esprit du moins, le cache de Démarrage n'est autre que le kernelcache (dit : "prelinkedkernel" : kernel pré-associé) qui se trouve à l'adresse : /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache) --> comme l'indique le dossier parent Startup (= "démarrage"), il s'agit bien du cache de démarrage du Système.

Car le fichier démarreur de l'OS exécuté par l'EFI au boot : le Boot_Loader : boot.efi (at: /System/Library/CoreServices) ne charge pas le kernel isolé (at: /System/Library/Kernels/kernel), lequel kernel aurait à se débrouiller tout seul comme un grand pour aller chercher les kexts (extensions du noyau) natives Apple une à une (at: /System/Library/Extensions) pour les vérifier avant de les charger (fichtrement long, le démarrage dans ces conditions!) ; mais ce que charge au démarrage le boot.efi, c'est le kernelcache, fichier qui 'mâche' la tâche du kernel, en solidarisant à l'avance (prelink) le code intégral du kernel - son clone exact ici - avec l'enveloppe globale des kexts offerte à être chargée en bloc selon l'argument de cache : All_Loaded = "toutes chargées en bloc certifié conforme".

Sous «Yosemite», qui comporte par défaut l'argument de boot en NVRAM de vérification d'intégrité des kexts natives Apple (kext_signing), «Trim Enabler» modifie cet argument de boot en lui substituant celui dédié aux développeurs : boot-args=kext-dev-mode=1. Je me figure que cet argument de boot qui transite au démarrage jusqu'au kernel revient à l'instruction : "charge-moi en bloc sans discuter l'enveloppe des kexts Apple présentée en cache dans le kernelcache et tant qu'il n'y a pas de blocage-système en retour, laisse faire" :D. Si le kernelcache est supprimé, c'est le kernel solidaire qui est chargé, et n'ayant pas d'enveloppe de kexts certifiée conforme à charger en bloc, il va passer la revue des extensions Apple natives une à une, tâche pour laquelle l'instruction du boot-args=kext-dev-mode=1 ne fait plus sens et donc saute, en étant overriden par l'instruction par défaut : "Vérifie au compte-goutte l'intégrité de chaque extension Apple". Et donc, parvenu à la kext litigieuse (bidouillée par «Trim Enabler) : IOAHCIFamily.kext - le kernel suspend le chargement --> panneau d'interdiction de stationner.

J'ai essayé de fournir une représentation (à mes risques et périls) de la raison pour laquelle la suppression du kernelcache (qui lie le kernel à une tâche de chargement d'un "bloc d'extensions garanti") va planter les Macs cactérisés par le triple critère : SSD de Tierce-Partie x Trim Enabler x Yosemite, malgré la modification de l'argument de boot en NVRAM à boot-args=kext-dev-mode=1. Et donc pour résumer mon sentiment : laisser la case du fichier cache : Démarrage (= kernelcache dans le dossier parent Startup) cochée par défaut dans le panneau Nettoyage/Système, c'est laisser la porte ouverte à un plantage programmé des Macs concernés par l'équation ci-dessus.

♧
 
Dernière édition:
  • J’aime
Réactions: subsole

subsole

Vénérable sage
Club MacG
16 Octobre 2010
11 142
3 521
Dans la toute dernière livraison d'«Onyx» (la version 2.9.1), l'auteur a judieusement édité les options par défaut des 2 panneaux devenus problématiques de son logiciel :

Automation

353230_original.png


Nettoyage

353495_original.png

Je trouve cette démarche particulièrement opportune --> sachant, en effet, qu'un certain nombre d'utilisateurs sont amenés à opérer - périodiquement ou en cas d'urgence - "un coup d'«Onyx" (selon leur expression qui m'a toujours paru une énigme intellectuelle, jusqu'à ce que je m'avise qu'ils entendaient par là l'exécution successive des options cochées par défaut des panneaux Nettoyage & Automation :D) ; et comme chez un nombre notable d'entre eux doit se rencontrer la combinaison des 3 facteurs : OS «Yosemite» instruisant le kext_signing x SSD de Tierce-Partie x activation de «Trim Enabler» - alors l'exécution de la suppression des caches-système proposée par défaut dans les versions antérieures d'«Onyx» n'aurait pas manqué de planter leur Mac devant le panneau d'interdiction de stationner (je reviens plus bas sur la raison de cet 'effet' que j'avais déjà essayé de décortiquer ici [TRIM] Yosemite et son bridage au message #131 et qui avait alerté le développeur d'«Onyx» : voir son message #140).

Il ne serait pas souhaitable, en effet, que la réputation du logiciel «Onyx», qui est grande, vienne à être entachée de soupçons de dangerosité, parce que telle option de Nettoyage ou d'Automation proposée par défaut conduirait à un plantage d'un certain nombre de Macs. L'avertissement explicite, affiché par l'auteur en regard de l'option de suppression des caches-système non cochée désormais par défaut, ne peut qu'inciter les utilisateurs ayant activé «Trim Enabler » à y regarder à deux fois avant de cocher la case fatidique et à en exécuter l'option. Ils ne pourront s'en prendre qu'à eux-mêmes si leur Mac plante.

♤

J'aurais juste une dernière petite question avant de prendre congé ("Inspecteur Columbo, sors du corps de macomaniac!" :D) : comme je l'ai souligné dans une annotation en vert de ma capture du panneau Nettoyage/Système d'«Onyx», j'ai un doute raisonnable concernant l'option demeurée cochée par défaut : Supprimer les fichiers Cache : Démarrage.

En effet, dans mon esprit du moins, le cache de Démarrage n'est autre que le kernelcache (dit : "prelinkedkernel" : kernel pré-associé) qui se trouve à l'adresse : /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache) --> comme l'indique le dossier parent Startup (= "démarrage"), il s'agit bien du cache de démarrage du Système.

Car le fichier démarreur de l'OS exécuté par l'EFI au boot : le Boot_Loader : boot.efi (at: /System/Library/CoreServices) ne charge pas le kernel isolé (at: /System/Library/Kernels/kernel), lequel kernel aurait à se débrouiller tout seul comme un grand pour aller chercher les kexts (extensions du noyau) natives Apple une à une (at: /System/Library/Extensions) pour les vérifier avant de les charger (fichtrement long, le démarrage dans ces conditions!) ; mais ce que charge au démarrage le boot.efi, c'est le kernelcache, fichier qui 'mâche' la tâche du kernel, en solidarisant à l'avance (prelink) le code intégral du kernel - son clone exact ici - avec l'enveloppe globale des kexts offerte à être chargée en bloc selon l'argument de cache : All_Loaded = "toutes chargées en bloc certifié conforme".

Sous «Yosemite», qui comporte par défaut l'argument de boot en NVRAM de vérification d'intégrité des kexts natives Apple (kext_signing), «Trim Enabler» modifie cet argument de boot en lui substituant celui dédié aux développeurs : boot-args=kext-dev-mode=1. Je me figure que cet argument de boot qui transite au démarrage jusqu'au kernel revient à l'instruction : "charge-moi en bloc sans discuter l'enveloppe des kexts Apple présentée en cache dans le kernelcache et tant qu'il n'y a pas de blocage-système en retour, laisse faire" :D. Si le kernelcache est supprimé, c'est le kernel solidaire qui est chargé, et n'ayant pas d'enveloppe de kexts certifiée conforme à charger en bloc, il va passer la revue des extensions Apple natives une à une, tâche pour laquelle l'instruction du boot-args=kext-dev-mode=1 ne fait plus sens et donc saute, en étant overriden par l'instruction par défaut : "Vérifie au compte-goutte l'intégrité de chaque extension Apple". Et donc, parvenu à la kext litigieuse (bidouillée par «Trim Enabler) : IOAHCIFamily.kext - le kernel suspend le chargement --> panneau d'interdiction de stationner.

J'ai essayé de fournir une représentation (à mes risques et périls) de la raison pour laquelle la suppression du kernelcache (qui lie le kernel à une tâche de chargement d'un "bloc d'extensions garanti") va planter les Macs cactérisés par le triple critère : SSD de Tierce-Partie x Trim Enabler x Yosemite, malgré la modification de l'argument de boot en NVRAM à boot-args=kext-dev-mode=1. Et donc pour résumer mon sentiment : laisser la case du fichier cache : Démarrage (= kernelcache dans le dossier parent Startup) cochée par défaut dans le panneau Nettoyage/Système, c'est laisser la porte ouverte à un plantage programmé des Macs concernés par l'équation ci-dessus.

♧
ET tout ça avant 8h du Matin. :up:
Que penses tu de Chameleon, dans une configuration Yosemite/OnyX/SSD nonApple &TRIM ?
 

rbart

Membre émérite
22 Avril 2013
654
52
Chameleon ou Trim enabler ou une commande maison, au final, ça fait pareil avec exactement le même principe.
Ils utilisent tous le même mécanisme et ont tous le même effet et les mêmes problèmes.
Finalement, il n'y a rien de dangereux, il suffit de garder sous la main les quelques commandes à taper en cas de souci en mode Recovery.
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
81 483
24 679
Forêt de Fontainebleau
ET tout ça avant 8h du Matin. :up:
Que penses tu de Chameleon, dans une configuration Yosemite/OnyX/SSD nonApple &TRIM ?

Je pense que bompi dans cet autre fil : [TRIM] Yosemite et son bridage (message #158) a répondu sur l'essentiel :

Dans une autre discussion j'ai trouvé cela :qu'en pensez-vous ? est-ce que ça résout le problème ?
J'en pense qu'il faudrait commencer par lire la FAQ du produit (un clic en haut à droite de la page d'accueil).

J'ai consulté la FAQ du site de «Chameleon» auquel pointe le lien et les risques encourus par l'usage de «Chameleon» s'avèrent les mêmes que ceux induits par l'usager de «Trim Enabler» puisque les 2 logiciels bidouillant la kext native Apple : IOAHCIFamily.kext, ils exposent semblablement leurs utilisateurs au même risque de plantage du Mac sous «Yosemite» à cause du kext_signing (vérification d'intégrité des extensions natives Apple). Et leur parade me paraît la même : désactiver le kext_signing en NVRAM et reconstruire le kernelcache après re-synchronisation du dossier des extensions par la commande touch.

Je ne connais pas «Chameleon», ne m'en étant pas servi, mais à part des différences d''interface graphique d'utilisateur, je soupçonne qu'en coulisses il y a analogie des procédés : même patch de la même kext et même type de parade contre le kext_signing. Tout aussi exposée l'une que l'autre à un reset de la NVRAM (qui fait sauter l'argument de substitution : boot-args=kext-dev-mode=1 et rétablit l'argument du kext_signing), un démarrage sans extensions (qui supprime les caches-système dont le cache de démarrage kernelcache) ou encore l'usage intempestif d'un logiciel de maintenance qui aurait conservé l'option "supression des caches-système" cochée par défaut dans un panneau dédié au 'nettoyage global' (ce qui revient à l'effet sur les caches d'un démarrage sans extensions).

Je m'aperçois en terminant ma réponse que rbart :coucou: a déjà répondu exactement dans le même sens. Comme lui, j'utilise «Trim Enabler» sans complexe sur mon Mac qui a un SSD «Crucial» et supporte «Yosemite», parce que, ayant déjà planté volontairement mon Mac à fins expérimentales une dizaine de fois à coup de reset_Nvram, de démarrages sans extensions ou de suppression de caches système dans la GUI de logiciels de maintenance, je sais que je m'en sortirais par le «Terminal» de la «Recovery HD», voire à toute dernière extrémité, par une Ré-installation de la version synchrone d'OSX. Je veille simplement désormais à éviter les options de démarrage périlleuses ou les options de maintenance inopportunes - et je reste tant soit peu méfiant dans la perspective d'une mise-à-jour système...​
 

bompi

El Moderador
Modérateur
Club MacG
12 Février 2004
41 936
3 169
On finit par avoir deux fils sur le même sujet (c'était couru d'avance).

Puisqu'on en est à se répéter : les quelques commandes à passer peuvent parfaitement être regroupées dans un script que l'on gardera dans un dossier du disque système ou de la partition de secours. Ou en deux scripts (un pour le mode debug dans la NVRAM et l'autre pour le rétablissement de la situation (restauration du cache des extensions etc.)
 

subsole

Vénérable sage
Club MacG
16 Octobre 2010
11 142
3 521
Je pense que bompi dans cet autre fil : [TRIM] Yosemite et son bridage (message #158) a répondu sur l'essentiel :



J'ai consulté la FAQ du site de «Chameleon» auquel pointe le lien et les risques encourus par l'usage de «Chameleon» s'avèrent les mêmes que ceux induits par l'usager de «Trim Enabler» puisque les 2 logiciels bidouillant la kext native Apple : IOAHCIFamily.kext, ils exposent semblablement leurs utilisateurs au même risque de plantage du Mac sous «Yosemite» à cause du kext_signing (vérification d'intégrité des extensions natives Apple). Et leur parade me paraît la même : désactiver le kext_signing en NVRAM et reconstruire le kernelcache après re-synchronisation du dossier des extensions par la commande touch.

Je ne connais pas «Chameleon», ne m'en étant pas servi, mais à part des différences d''interface graphique d'utilisateur, je soupçonne qu'en coulisses il y a analogie des procédés : même patch de la même kext et même type de parade contre le kext_signing. Tout aussi exposée l'une que l'autre à un reset de la NVRAM (qui fait sauter l'argument de substitution : boot-args=kext-dev-mode=1 et rétablit l'argument du kext_signing), un démarrage sans extensions (qui supprime les caches-système dont le cache de démarrage kernelcache) ou encore l'usage intempestif d'un logiciel de maintenance qui aurait conservé l'option "supression des caches-système" cochée par défaut dans un panneau dédié au 'nettoyage global' (ce qui revient à l'effet sur les caches d'un démarrage sans extensions).

Je m'aperçois en terminant ma réponse que rbart :coucou: a déjà répondu exactement dans le même sens. Comme lui, j'utilise «Trim Enabler» sans complexe sur mon Mac qui a un SSD «Crucial» et supporte «Yosemite», parce que, ayant déjà planté volontairement mon Mac à fins expérimentales une dizaine de fois à coup de reset_Nvram, de démarrages sans extensions ou de suppression de caches système dans la GUI de logiciels de maintenance, je sais que je m'en sortirais par le «Terminal» de la «Recovery HD», voire à toute dernière extrémité, par une Ré-installation de la version synchrone d'OSX. Je veille simplement désormais à éviter les options de démarrage périlleuses ou les options de maintenance inopportunes - et je reste tant soit peu méfiant dans la perspective d'une mise-à-jour système...​
:)
Merci beaucoup pour ce résumé de la situation, dont j'avais bien besoin.

Je suis encore pour quelques jours sur 10.8.5,( ne souhaitant utiliser 10.9.x) mais le K5 que je dois recevoir sera sous Yosemite.
 

Ibiscus

Membre confirmé
30 Avril 2005
428
12
Macomaniac, merci pour toutes tes informations toujours bien documentées et dans un style très clair.
Pour ceux qui ne pratiquent pas la console, comme moi, pourrais-tu nous concocter le ou les petits scripts que propose Bompi, à lancer depuis Recovery HD. Avec une adresse pour le/les télécharger bien sûr. Merci d'avance :zen:
En passant j'ai pas compris à quoi servirait le 2ème script "pour le mode debug dans la NVRAM" ? Mais c'est peut-être que je connais pas la différence entre P-RAM et NVRAM :confused:
 

bompi

El Moderador
Modérateur
Club MacG
12 Février 2004
41 936
3 169
Macomaniac, merci pour toutes tes informations toujours bien documentées et dans un style très clair.
Pour ceux qui ne pratiquent pas la console, comme moi, pourrais-tu nous concocter le ou les petits scripts que propose Bompi, à lancer depuis Recovery HD. Avec une adresse pour le/les télécharger bien sûr. Merci d'avance :zen:
En passant j'ai pas compris à quoi servirait le 2ème script "pour le mode debug dans la NVRAM" ? Mais c'est peut-être que je connais pas la différence entre P-RAM et NVRAM :confused:
De mémoire : c'était PRAM à l'époque des processeurs PowerPC, NVRAM avec les processeurs Intel. Mais c'est grosso modo la même chose.

Sur le site de Cindori, on trouve tout indiqué (ici, regarder la section "Recovering from stop sign on boot screen").

Il est conseillé de procéder en deux étapes :
a) repasser la NVRAM en mode debug, ce qui désactive la vérification de la signature des extensions
---- on redémarre ----
b) refaire la modification de l'extension et mettre à jour le cache
 

El lobo

Membre junior
9 Septembre 2014
52
1
Amérique centrale & sud
Bonjour tout le monde,

wouahhhh ... il y a des questions a ne pas poser sur le forum, sous risque de devoir retourner a l'école pour comprendre les réponses :p ;) ...

(Je sais que vous êtes des bêtes en la matière, mais pas tout le monde a cette chance, et cette passion, je suis un usager basique, et vos réponses sont pointue, termes utilisés d'informaticien, il me faut du temps et comprendre d'autres choses pour pouvoir comprendre votre logique, et vos réponses. Et, en même temps, vos réponses donnent "peur" de monter un SSD, car si il faut votre niveaux pour comprendre son Mac, et pas le planter avec une fausse manipulation, ou MaJ, je jette l'éponge, lol, je n'est pas vos qualités, et je n'est pas d'appuis ici en cas de plantage sérieux de mon mac ...)

Mais, un énorme "Merci a vous tous", pour votre participation, aide, conseils, c'est super chouette.

Bien vu le détails d'Onyx, mais je comprend pas ce qu'il viens faire dans ma question initiale, ou bien au contraire, il modifie aussi le Trim, ou a un lien direct avec, donc je doit aussi en tenir compte ? (Mais dans ce cas, il faut ouvrir un autre topic, car la je peine déjà a tout suivre ...)

J'ai demander a Crucial, leur point de vue, c'est quand même eux qui conseillent, intègrent Garbage Collector a leur SSD. La réponse :

Concernant la commande TRIM permet aux systèmes d’exploitation d’éviter que les performances d’un disque dur SSD ne se dégradent avec le temps. Par défaut, la commande TRIM n’est pas activée dans Mac OS X (sauf si vous achetez un ordinateur qui embarque un SSD installé par Apple). De plus en plus tous nos disques durs SSD embarquent nativement une fonction (le Garbage Collector) qui remplit la même fonction que la commande TRIM. Le Garbage Collection (récupérateur de mémoire) est un type de gestion de la mémoire libérant les secteurs qui ne s’utilisent plus, et ce afin qu'ils puissent être facilement accessible à nouveau. Avec les SSD, ce procédé fait partie du contrôleur et fonctionne durant les temps inactifs afin de ne pas affecter les performances, mais permet un accès plus rapide aux secteurs relibérés.

Dois-je comprendre, que si on utilise un autre logiciel Trim, on va faire des doublettes et plantage ? Qu'il est, selon Crucial, inutile d'utiliser un autre logiciel ? (Ou, j'ai vraiment rien compris au Trim, ça c'est autre choses.)

En même temps, en lisant certaines réponses, je découvre que qql'un a certainement la réponses a tout ces problèmes, ou du moins il a la solution :

Finalement, il n'y a rien de dangereux, il suffit de garder sous la main les quelques commandes à taper en cas de souci en mode Recovery.

On pourrait pas commencer par une explications de ces fameuses commande, Don Rbart, s'il te plait ?

Faites, par qql'un qui connais et utilise cette option, et non par mr Google ou autre FaQ a lire dans tout les sens. Je te sens tout relax face a ce problème, Don Rbart, donc j'en déduis que tu a peut être une solution a nous partagé ?

Il y a eux des longues, très longues réponses pour Onyx, (qui je crois n'a rien a faire dans mes réponses) donc on pourrait pas avoir une longue réponses sur ces commandes,et le Recovery, histoire de nous tranquillisé, et partager une bonne solution, qui je crois, je ne suis pas le seul a désirer ... (Ou, tu va nous diriger vers Google ? Dans ce cas, plus besoin d'un forum avec des pro, si Google remplace tout, lol ....)

Bueno, je vais continuer mes recherches.

Bonne continuation a tous, et encore merci pour votre aide.
Cordialement.
Lobo