Comment activer trim pour yosemite 10.10.5

kaul128

Membre junior
3 Décembre 2006
98
0
Bonjour, je viens d'installer un ssd en complément du disque dur et j'aimerais savoir quelle est le moyen le plus efficace d'activer le trim pur un SSD samsung 850 pro 512 GB?
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
71 599
21 482
Forêt de Fontainebleau
Salut kaul.

À partir de la MÀJ 10.10.4 de «Yosemite», Apple a fait le geste (longtemps attendu), d'introduire dans les ressources natives d'OS X une extension intitulée : AppleDataSetManagement.kext ("kext" comme kernel_extension en abrégé) spécialement dédiée à la gestion du TRIM sur tout SSD de tierce-partie installé après coup par un utilisateur en remplacement (ou en addition) du HDD équipant un Mac à l'origine. Ce qui vaut aussi pour le futur OS «El Capitan 10.11» actuellement en chantier (d'après les versions "bêta" disponibles).

Comme l'OS «Yosemite (10.10.4 ou >)» est supporté, soit par des Macs récents équipés nativement par Apple d'un SSD sur lesquel le TRIM est géré par l'extension native IOAHCIFamily.kext (la même que patchait le logiciel «Trim Enabler» pour la rendre compatible avec des SSD de tierce-partie), soit par des Macs anciens ayant toujours leur HDD à plateaux d'origine, il s'ensuit que la nouvelle extension Apple "TRIM => SSD tiers" n'avait pas à se trouver activée par défaut sur tout Mac, mais au contraire optionnellement sur les seuls Macs équipés après coup d'un SSD de tierce partie par l'utilisateur.

Cela explique l'état de choses concernant cette récente extension Apple : AppleDataSetManagement.kext -->

- a) Son original n'est pas contenu par défaut dans le dossier /System/Library/Extensions d'OS X comme les autres kexts Apple, parce que toute extension recelée dans ce dossier des Extensions-Système se trouve a priori injectée dans le kernel au démarrage du Mac ; mais il est recelé dans un dossier de "réserve" où l'extension reste inactive aussi longtemps qu'elle y réside : le /System/Library/Filesystems --> je t'invite à aller graphiquement à cette adresse dans ton OS pour vérifier la présence de cet original : AppleDataSetManagement.kext en état de "latence" de la nouvelle extension Apple.

- b) Pour activer cette extension "TRIM => SSD tiers" si et seulement s'il y a lieu (donc), les ingénieurs d'Apple ont mis au point un petit programme intitulé trimforce ("forcer le trim") résidant à l'adresse : /usr/bin/trimforce. Il suffit par suite de se rendre at: Applications/Utilitaires et de lancer le «Terminal» et de saisir la commande :

Bloc de code:
sudo trimforce enable
et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande) --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ --> cette commande, qui sollicite le programme trimforce avec le verbe enable (= "activer"), se borne purement & simplement à opérer une recopie à partir de l'original intouché : /System/Library/Filesystems/AppleDataSetManagement.kext dans le dossier d'accueil des extensions-système Apple --> /System/Library/Extensions/AppleDataSetManagement.kext (comme une inspection graphique du dossier : /System/Library/Extensions permet de le vérifier suffisamment) --> il suffit de re-démarrer le Mac et le TRIM est désormais activé sur le SSD de tierce-partie (par injection automatique au démarrage dans le kernel de la copie de la kext recelée dans le dossier des Extensions). Il est possible de s'assurer de cette activation en allant at: Menu /À propos de ce Mac/Rapport Système.../Matériel/SATA_SATA Express --> dans le champ d'information de droite, sélectionner le SSD tiers (ligne subalterne, en alinéa) et dans le tableau d'informations inférieur, regarder à la rubrique : Prise en charge du TRIM : --> la mention devrait être : "Oui".​

--------------------
NB-1. Il est possible, pour quelqu'un qui souhatierait désactiver le TRIM (car ?...), de passer la commande inverse dans le «Terminal» :

Bloc de code:
sudo trimforce disable
dont l'action consiste purement et simplement à supprimer la copie de la kext AppleDataSetManagement.kext du répertoire : /System/Library/Extensions, tout en préservant intact l'original inactif at: /System/Library/Filesystems/AppleDataSetManagement.kext (ce qui peut être vérifié graphiquement après la commande).

--------------------​

NB-2. La nouvelle extension étant signée Apple, elle passe sans problème le protocole du kext_signing (vérification de l'intégrité des extensions-Système au démarrage) mis-en-place à partir de «Yosemite» --> le reset_NVRAM aussi bien que le démarrage en "safe mode" (qui vide les caches-Système de démarrage notamment) sont donc supportés de nouveau sans plantage du Système, à la différence de ce qui se passait en recourant à «Trim Enabler» qui, en bidouillant une kext Apple, rendait le dispositif sensible au plantage à la suite des manœuvres susdites.

--------------------
NB-3. Par anticipation et concernant la future version d'OS X : «El Capitan» : cet OS comportera, comme boot-args (argument de boot dans la mémoire statique NVRAM de la Carte-Mère dont le Programme Interne du Mac = l'EFI charge les instruction au démarrage pour les passer via le au boot_loader: boot.efi au kernel) - un argument "rootless=1" équivalant à une limitation des droits root sur le Système une fois démarré. Il s'ensuit logiquement que la commande évoquée ci-dessus : sudo trimforce enable, sous l'effet de la limitation "rootless", ne pourra pas se trouver exécutée par interdiction de modifier l'architecture des dossiers-Système - dont ici le dossier concerné : /System/Library/Extensions par ajout d'un répertoire de kext (en cas de "Clean Install" - bien entendu, l'installation d'«El Capitan», en mode mise-à-niveau d'un «Yosemite» préalable, préservera la kext additionnelle du dossier des Extensions si elle y avait été copiée antérieurement, et le TRIM continuerait d'être géré dans ce cas-là).

Il faudra donc (dans le cas d'une "Clean Install" de 10.11 sur un Mac avec SSD tiers), démarrer par ⌘R sur la partition de récupération «Recovery HD 10.11» et lancer le nouvel utilitaire (barre supérieure des menus, menu : Utilitaires) intitulé : Security Configuration.app (Configuration de Sécurité) pour lui demander de désactiver le protocole restrictif "rootless" en décochant la case de la rubrique : "Enforce System Integrity Protection" ("Activer le SIP") --> re-démarré sur «El Capitan», il sera alors possible de modifier le dossier des Extensions-Système en y injectant par la commande : sudo trimforce enable une copie de la AppleDataSetManagement.kext, ce qui assurera la gestion du TRIM après re-démarrage. Libre à l'utilisateur de laisser désactivé le protocole "rootless", ou de re-démarrer encore sur la «Recovery HD» pour le réactiver via l'utilitaire : Security Configuration.app...

--------------------​
 
Dernière édition:

kaul128

Membre junior
3 Décembre 2006
98
0
Je te remercie de ta réponse macomaniac ,
sudo trimforce enable à bien marché sur mon ssd.
Je vais bien profiter de mon sdd.
 

Lutins14

Nouveau membre
20 Août 2015
1
0
52
Bonjour,
je possède un macbook pro mi 2009 sous OSX 10.10.5 et j'ai installé un SSD Samsung EVO 850 500 go.
Je n'arrive pas à utiliser la commande sudo trimforce enable dans le terminal, j'obtiens systématiquement le message d'erreur "
sudo: trimforce: command not found"
est ce que vous pouvez m'aider à activer le trim
Merci d'avance
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
71 599
21 482
Forêt de Fontainebleau
Vacances de la déduction : petit exercice "holmésien"


Salut Lutins.

Pour passer avec succès la commande : sudo trimforce enable dans le «Terminal» (de manière à activer le TRIM sur un SSD tiers selon le nouveau procédé ©Apple), il faut que 2 ressources soient présentes a priori dans l'OS :

-a) le binaire UNIX trimforce à l'adresse : /usr/bin/trimforce

- b) l'original de la nouvelle extension du noyau dédiée au TRIM sur SSD tiers à l'adresse : /System/Library/Filesystems/AppleDataSetManagement.kext

Je t'invite à faire cette vérification en mode graphique, en pressant dans le Finder la combinaison de touches : ⌘⇧G (cmd maj G) qui commande l'affichage du panneau "Aller à..." pour coller dans le champ de saisie l'adresse :

Bloc de code:
/usr/bin
et presse le bouton "Aller" --> une fenêtre s'ouvre, affichant l'espace du dossier invisible bin dans le répertoire usr --> vérifie si, à la lettre T, tu tombes bien sur l'icône rectangulaire anthracite (avec un petit exec vert inscrit) du binaire : trimforce.

Ferme la fenêtre et ressaisis la combinaison de touches ⌘⇧G pour coller dans le champ de saisie l'adresse :
Bloc de code:
/Système/Bibliothèque/Filesystems
et presse le bouton "Aller" --> une fenêtre s'ouvre derechef, affichant l'espace du dossier Filesystems relevant de la Bibliothèque-Système de l'OS --> vérifie si tu vois bien l'objet : AppleDataSetManagement.kext qui est l'original de l'extension, dont la commande : sudo trimforce enable se borne à effectuer une copie conforme dans le dossier /System/Library/Extensions afin qu'elle soit injectée dans le kernel au démarrage et que le TRIM soit donc pris en charge sur un SSD tiers.

--------------------​

A priori, ton OS installé étant la version : «Yosemite 10.10.5», les 2 ressources que je viens d'évoquer sont nécessairement présentes à leurs emplacements règlementaires (ce que tu as dû vérifier) et, par suite, la commande : sudo trimforce enable devrait s'exécuter sans obstacle dans le «Terminal», puisque son outil (le programme trimforce) et son objet (l'original AppleDataSetManagement.kext) existent dans l'OS.

Et pourtant ta commande achoppe, avec le message en retour :

Bloc de code:
sudo: trimforce: "command not found"
ce qui constitue un joli petit problème. Procédons par élimination : le blocage ne peut pas provenir de ce que tu n'aurais pas le droit de passer une commande sudo, étant dans une session standard, parce que dans ce cas tu obtiendrais le message en retour :

Bloc de code:
Sorry, user lutins14 [ton username] is not allowed to execute '/usr/bin/trimforce enable' as root on MacBook Pro.
Le blocage ne peut pas provenir de l'absence de l'objet de références (/System/Library/Filesystems/AppleDataSetManagement.kext), parce que tu obtiendrais un message en retour du style :

Bloc de code:
/System/Library/Filesystems/AppleDataSetManagement.kext:  No such file or directory
Reste un blocage concernant l'outil invoqué par la commande, ce que le message :

Bloc de code:
trimforce: "command not found"
paraît bien spécifiquement pointer : impossibilité d'exécuter la commande, car le programme invoqué trimforce n'est pas trouvé. Or, étant sous «Yosemite 10.10.5», le programme trimforce doit forcément exister à son adresse de référence : /usr/bin/trimforce ; et ta recherche dans le panneau "Aller à..." du Finder a dû te confirmer la présence de ce binaire à l'endroit attendu. Alors ?

--------------------​

Alors je ne vois qu'une explication à tes déboires : ce qui permet à un utilisateur d'invoquer directement, en en-tête de commandes dans le «Terminal», tel ou tel binaire UNIX fourni nativement dans OS X sans faire précéder cette citation du programme par son adresse dans tel ou tel autre "répertoire à binaires" du Système, c'est l'effet de raccourci produit par ce qu'on appelle la variable d'environnement $PATH qui recèle la liste des adresses aux "dossiers à binaires", chacune séparée de la suivante par un ":", constituant le domaine inclusif des programmes directement invocables par l'utilisateur sans adresse spécifique. Il suffit que le binaire invoqué soit présent dans un des dossiers référencés par la variable $PATH pour qu'il soit trouvé et son action commandée.

Je conjecture que le répertoire à binaires /usr/bin (pour une raison que j'ignore) ne fait pas partie de la liste d'adresses de référence de ta variable d'environnement $PATH, ce qui fait que, quand tu l'invoques ex abrupto dans le «Terminal», il n'est pas trouvé. Première vérification de cette conjecture --> fais dans le «Terminal» un copier-coller direct de la commande :

Bloc de code:
sudo /usr/bin/trimforce enable
et ↩︎ --> logiquement, le binaire trimforce devant être présent à l'adresse indiquée («Yosemite 10.10.5» oblige) et l'adresse absolue à ce programme étant mentionnée (/usr/bin/trimforce), plus question de "command not found" mais --> une demande de password (commande sudo) --> tape ton mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ --> après re-démarrage de ta bécane, le TRIM devrait être activé sur ton SSD (vérification dans les Infos Système de "À propos de ce Mac").

Contre-vérification : dans le «Terminal», tu saisis ce coup-ci :

Bloc de code:
echo "$PATH"
et ↩︎ --> cette commande demande l'affichage "en écho" de la liste d'adresses spécifique de ta variable d'environnement $PATH. Voici par exemple la mienne :

Bloc de code:
/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Applications/Server.app/Contents/ServerRoot/usr/bin:/Applications/Server.app/Contents/ServerRoot/usr/sbin:/usr/texbin
--> tu noteras que l'agglutination des adresses à la queue-leu-leu avec pour simple séparatif le ":" ne rend pas la séquence très lisible. Mais focalise-toi à la lecture sur les ":" comme marquant des séparateurs absolus, ce qui te permettra de "scander" ta lecture. Si tu inspectes la liste de ma $PATH, tu noteras à la 4è place l'adresse :/usr/bin: où se trouve précisément contenu le binaire trimforce. Je n'ai par suite aucun problème à invoquer trimforce en direct dans le «Terminal», puisque le dossier qui contient ce binaire fait partie du domaine de référence de mes invocations possibles sans adresse obligée (ce qui est fort commode, tu le reconnaîtras : qui se souviendrait de toutes les adresses spéciales de tous les binaires invocables ?). Si tu inspectes la liste de ta $PATH - eh bien ! tu ne devrais voir nulle part l'adresse : :/usr/bin: ce qui expliquerait que le programme invoqué dans la commande ne soit pas trouvé "automatiquement" quand tu te bornes à l'énoncé simple de son nom.

Si ma conjecture est exacte, tu peux éditer ta variable d'environnement $PATH de manière à inclure dans la liste de ses adresses de répertoires à binaires le : /usr/bin. Il existe plusieurs procédés plus ou moins commodes pour cette édition --> je te propose le plus simple, qui consiste à créer un fichier mentionnant l'adresse /usr/bin dans le dossier invisible : /etc/path.d ce qui rendra l'adresse en question valide pour la variable $PATH de tous les utilisateurs possibles de l'OS. Fais donc un copier-coller dans la fenêtre du «Terminal» de :

Bloc de code:
sudo -s 'echo "/usr/bin" > /etc/paths.d/bin'
et ↩︎ --> password à l'aveugle et ↩︎ --> re-démarre impérativement ton Mac pour que la nouvelle ressource soit chargée par le Système et retourné dans ta session, si tu repasses dans le «Terminal» un :

Bloc de code:
echo "$PATH"
tu devrais ce coup-ci voir mentionné à un point donné de la chaîne d'adresses --> :/usr/bin:

[NB. S'il s'avérait qu'une des 2 ressources précitées (trimforce ou AppleDataSetManagement.kext) manquât à l'adresse de référence de l'OS --> une application de la ☞OS X Yosemite 10.10.5 Combo Update☜ ou carrément une "Ré-installation d'OS X" à partir d'un démarrage sur la partition de récupération «Recovery HD» règlerait le problème en restaurant les ressources déficientes...]

 
Dernière édition:

Spring

Nouveau membre
26 Février 2012
6
0
Lausanne Suisse
Bonjour à tous,

tout d'abord merci @macomaniac pour tes explications très claires.

J'ai un MacMini mi 2011 avec OSX 10.10.5 sur lequel j'ai installé un SSD Crucial MX100 de 256Gb. Le trim enable a fonctionné à la perfection.

J'ai utilisé cette configuration depuis 8 mois sans le trim enable. Dois-je prévoir une opération de maintenance dessus? ou les bénéfices du trim sont instantanés.?

Merci d'avance.
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
71 599
21 482
Forêt de Fontainebleau
Salut Spring.

Pfuiii ! Tu es tombé sur un de mes billets spécialement "carabinés" (du genre : devoir de vacances)


Pour la question qui te tracasse (SSD utilisé 8 mois sans gestion du TRIM - à moins que tu n'aies utilisé «Trim Enabler» avant la commande trimforce ?), personnellement, je ne me tracasserais pas à partir de l'idée suivante : l'extension va faire le ménage en tâche de fond récurrente avec une continuité d'action de nettoyage des cellules bénéficiaire par rapport aux actes discontinus de nouvelles écritures au disque --> au bout d'un "certain temps", le "retard" de nettoyage devrait être rattrapé...
 

Spring

Nouveau membre
26 Février 2012
6
0
Lausanne Suisse
Hello @macomaniac,

Merci beaucoup pour ta réponse rapide et tes précisions . En fait j'avais rien fait quand j'ai mis mon SSD... je m'en suis rendu compte quand j'ai lu récemment l'article sur le fait que depuis 10.10.4 les packages pour faire le "TrimForce Enable" étaient compris dans l'OS.
 

barytonlyrique

Nouveau membre
19 Octobre 2008
3
0
Salut kaul.

À partir de la MÀJ 10.10.4 de «Yosemite», Apple a fait le geste (longtemps attendu), d'introduire dans les ressources natives d'OS X une extension intitulée : AppleDataSetManagement.kext ("kext" comme kernel_extension en abrégé) spécialement dédiée à la gestion du TRIM sur tout SSD de tierce-partie installé après coup par un utilisateur en remplacement (ou en addition) du HDD équipant un Mac à l'origine. Ce qui vaut aussi pour le futur OS «El Capitan 10.11» actuellement en chantier (d'après les versions "bêta" disponibles).

Comme l'OS «Yosemite (10.10.4 ou >)» est supporté, soit par des Macs récents équipés nativement par Apple d'un SSD sur lesquel le TRIM est géré par l'extension native IOAHCIFamily.kext (la même que patchait le logiciel «Trim Enabler» pour la rendre compatible avec des SSD de tierce-partie), soit par des Macs anciens ayant toujours leur HDD à plateaux d'origine, il s'ensuit que la nouvelle extension Apple "TRIM => SSD tiers" n'avait pas à se trouver activée par défaut sur tout Mac, mais au contraire optionnellement sur les seuls Macs équipés après coup d'un SSD de tierce partie par l'utilisateur.

Cela explique l'état de choses concernant cette récente extension Apple : AppleDataSetManagement.kext -->

- a) Son original n'est pas contenu par défaut dans le dossier /System/Library/Extensions d'OS X comme les autres kexts Apple, parce que toute extension recelée dans ce dossier des Extensions-Système se trouve a priori injectée dans le kernel au démarrage du Mac ; mais il est recelé dans un dossier de "réserve" où l'extension reste inactive aussi longtemps qu'elle y réside : le /System/Library/Filesystems --> je t'invite à aller graphiquement à cette adresse dans ton OS pour vérifier la présence de cet original : AppleDataSetManagement.kext en état de "latence" de la nouvelle extension Apple.

- b) Pour activer cette extension "TRIM => SSD tiers" si et seulement s'il y a lieu (donc), les ingénieurs d'Apple ont mis au point un petit programme intitulé trimforce ("forcer le trim") résidant à l'adresse : /usr/bin/trimforce. Il suffit par suite de se rendre at: Applications/Utilitaires et de lancer le «Terminal» et de saisir la commande :

Bloc de code:
sudo trimforce enable
et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande) --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ --> cette commande, qui sollicite le programme trimforce avec le verbe enable (= "activer"), se borne purement & simplement à opérer une recopie à partir de l'original intouché : /System/Library/Filesystems/AppleDataSetManagement.kext dans le dossier d'accueil des extensions-système Apple --> /System/Library/Extensions/AppleDataSetManagement.kext (comme une inspection graphique du dossier : /System/Library/Extensions permet de le vérifier suffisamment) --> il suffit de re-démarrer le Mac et le TRIM est désormais activé sur le SSD de tierce-partie (par injection automatique au démarrage dans le kernel de la copie de la kext recelée dans le dossier des Extensions). Il est possible de s'assurer de cette activation en allant at: Menu /À propos de ce Mac/Rapport Système.../Matériel/SATA_SATA Express --> dans le champ d'information de droite, sélectionner le SSD tiers (ligne subalterne, en alinéa) et dans le tableau d'informations inférieur, regarder à la rubrique : Prise en charge du TRIM : --> la mention devrait être : "Oui".​

--------------------
NB-1. Il est possible, pour quelqu'un qui souhatierait désactiver le TRIM (car ?...), de passer la commande inverse dans le «Terminal» :

Bloc de code:
sudo trimforce disable
dont l'action consiste purement et simplement à supprimer la copie de la kext AppleDataSetManagement.kext du répertoire : /System/Library/Extensions, tout en préservant intact l'original inactif at: /System/Library/Filesystems/AppleDataSetManagement.kext (ce qui peut être vérifié graphiquement après la commande).

--------------------​

NB-2. La nouvelle extension étant signée Apple, elle passe sans problème le protocole du kext_signing (vérification de l'intégrité des extensions-Système au démarrage) mis-en-place à partir de «Yosemite» --> le reset_NVRAM aussi bien que le démarrage en "safe mode" (qui vide les caches-Système de démarrage notamment) sont donc supportés de nouveau sans plantage du Système, à la différence de ce qui se passait en recourant à «Trim Enabler» qui, en bidouillant une kext Apple, rendait le dispositif sensible au plantage à la suite des manœuvres susdites.

--------------------
NB-3. Par anticipation et concernant la future version d'OS X : «El Capitan» : cet OS comportera, comme boot-args (argument de boot dans la mémoire statique NVRAM de la Carte-Mère dont le Programme Interne du Mac = l'EFI charge les instruction au démarrage pour les passer via le au boot_loader: boot.efi au kernel) - un argument "rootless=1" équivalant à une limitation des droits root sur le Système une fois démarré. Il s'ensuit logiquement que la commande évoquée ci-dessus : sudo trimforce enable, sous l'effet de la limitation "rootless", ne pourra pas se trouver exécutée par interdiction de modifier l'architecture des dossiers-Système - dont ici le dossier concerné : /System/Library/Extensions par ajout d'un répertoire de kext (en cas de "Clean Install" - bien entendu, l'installation d'«El Capitan», en mode mise-à-niveau d'un «Yosemite» préalable, préservera la kext additionnelle du dossier des Extensions si elle y avait été copiée antérieurement, et le TRIM continuerait d'être géré dans ce cas-là).

Il faudra donc (dans le cas d'une "Clean Install" de 10.11 sur un Mac avec SSD tiers), démarrer par ⌘R sur la partition de récupération «Recovery HD 10.11» et lancer le nouvel utilitaire (barre supérieure des menus, menu : Utilitaires) intitulé : Security Configuration.app (Configuration de Sécurité) pour lui demander de désactiver le protocole restrictif "rootless" en décochant la case de la rubrique : "Enforce System Integrity Protection" ("Activer le SIP") --> re-démarré sur «El Capitan», il sera alors possible de modifier le dossier des Extensions-Système en y injectant par la commande : sudo trimforce enable une copie de la AppleDataSetManagement.kext, ce qui assurera la gestion du TRIM après re-démarrage. Libre à l'utilisateur de laisser désactivé le protocole "rootless", ou de re-démarrer encore sur la «Recovery HD» pour le réactiver via l'utilitaire : Security Configuration.app...

--------------------​
Bonsoir,
Merci pour les tuyaux
Ma config est un macbook pro que j'ai équipé avec un ssd 500Gb et j'ai gardé mon ancien disque dur avec un adaptateur à la place du lecteur cd
Je l'ai installé aujourd'hui et quand j'active la sudo trimforce enable, j'ai un message qui fait un peu flipper:

IMPORTANT NOTICE: This tool force-enables TRIM for all relevant attached
devices, even though such devices may not have been validated for data
integrity while using TRIM. Use of this tool to enable TRIM may result in
unintended data loss or data corruption. It should not be used in a commercial
operating environment or with important data. Before using this tool, you
should back up all of your data and regularly back up data while TRIM is
enabled. This tool is provided on an “as is” basis. APPLE MAKES NO WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTIES OF
NON-INFRINGEMENT, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE,
REGARDING THIS TOOL OR ITS USE ALONE OR IN COMBINATION WITH YOUR DEVICES,
SYSTEMS, OR SERVICES. BY USING THIS TOOL TO ENABLE TRIM, YOU AGREE THAT, TO THE
EXTENT PERMITTED BY APPLICABLE LAW, USE OF THE TOOL IS AT YOUR SOLE RISK AND
THAT THE ENTIRE RISK AS TO SATISFACTORY QUALITY, PERFORMANCE, ACCURACY AND
EFFORT IS WITH YOU.

Are you sure you wish to proceed (y/N)?


Et du coup j'ai pas osé valider tant que j'avais pas un avis là dessus
c'est risqué d'activer cette fonction ?
D'avance merci pour la réponse
Bonne soirée
Arnaud
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
71 599
21 482
Forêt de Fontainebleau
Salut barytonlyrique

C'est le baratin qui accompagnait la publication par Apple de la nouvelle extension du noyau destinée à gérer le TRIM sur les SSD de tierce-partie - extension fournie en mode optionnel seulement à partir de la version 10.10.4 de «Yosemite».

Cette extension optionnelle est la : AppleDataSetManagement.kext que tu trouves at: /System/Library/Filesystems/AppleDataSetManagement.kext. La commande sudo trimforce enable > pour l'essentiel exécute une copie de cette extension dans le dossier /System/Library/Extensions > avant de re-démarrer le Mac > ce qui fait que cette extension copiée dans le dossier des Extensions sera injectée dans le kernel à chaque démarrage.

=> tu peux valider la commande sans état d'âme : l'extension AppleDataSetManagement.kext a fait largement ses preuves sans anicroche.