macOS Monterey To Trim or not to Trim

Statut
Ce sujet est fermé.

iDanGener

.
Club iGen
12 Mars 2011
1 485
401
Bonjour,

Je suis sous Monterey depuis quelques mois, en démarrant sur un ssd externe connecté en USB. En cherchant sur le web la façon d'activer le trim, je suis tombé sur cet article de iFixit qui signale:

«⚠️ Attention avec un SSD avec une partition APFS, l'activation de Trim n'est pas recommandée

Doit-on comprendre qu'il n'est pas recommandé d'activer le Trim si on a créé plusieurs conteneurs ou partitions sur le disque ? Mais par défaut, n'y a-t-il pas toujours plusieurs partitions (invisibles) sur un disque ?

Comment comprenez-vous ce «Attention» de iFixIt?

Merci !
 
Comment comprenez-vous ce «Attention» de iFixIt?
Bonjour,
J'en conclu que l'on peut lire des crétineries partout, y compris sur le site de iFixIt :(
D'ailleurs l'auteur de l'article (qui est un contributeur mais ne fait pas partie de l'équipe) continue son florilège dans les commentaires : "APFS gère mieux les fichiers que Trim", "TRIM est un gestionnaire de fichiers". C'est affligeant.

Après, pour tes questions, il y a eu des cas par le passé ou le Trim posait des problèmes, et comme c'est un outil d'optimisation, il était parfois préférable de s'en passer pour éviter des problèmes plus immédiats. Mais ça fait très longtemps que ces problèmes sont résolus et je n'ai pas connaissance de nouveaux.

Donc oui, aujourd'hui il est recommandé de l'activer dans tous les cas, d'autant que depuis Monterey c'est aussi actif sur (certains) disque externes USB, alors qu'avant seuls les disques internes en bénéficiaient.

Par contre, même activé au niveau du Mac, il n'est pas certain qu'il s'applique lorsque l'on démarre d'un SSD USB, je n'ai lu aucun tests sur ce cas précis, tu peux essayer de le savoir en suivant ce guide : https://www.journaldulapin.com/2021/12/24/trim-usb-monterey/
 
Merci à tous les deux pour vos retours.

Je ne crois pas (sous toute réserve !!! vous savez, l'âge, le surmenage, et tout le reste :dead:) avoir exécuté la commande au terminal pour activer le trim, et la commande «log show --predicate ...» indiqué sur le site du Journal du Lapin me retourne qu'il est activé sur le ssd externe T5 (qui n'est pas le disque de démarrage en cours); ce qui irait dans le sens de ce que tu disais @Ahiqar.

Je n'avais pas envisagé la possibilité, qu'évoque @ericse, que le comportement puisse être différent selon que le ssd soit le disque de démarrage ou non. J'ai voulu tester la commande «log show --predicate ...» pour tenter d'avoir cette info pour le ssd externe T7, qui est le disque de démarrage, en donnant la date du dernier démarrage, mais je n'obtiens à nouveau que de l'info pour le T5.

Note: Bien qu'ils soit indiqué dans les informations système que le trim est activé sur le ssd interne, la commande «log show --predicate ...» ne retourne rien après avoir démonté/monté le ssd interne et avoir utilisé la commande «log show --predicate ...» avec un temps légèrement inférieur à la date du «montage».
 
C'est un territoire un peu complexe et mal exploré, alors allons-y prudement avec les suppositions : il y a 2 façon d'executer la commande Trim, soit au fil de l'eau (à chaque modification/effacement de fichier), soit périodiquement (par exemple au branchement). La première méthode est plus performante, le seconde plus fiable.

Il me semble que macOS utilise la seconde méthode pour les disques externes (d'ou les traces dans les logs), et la première pour les internes, mais ce ne sont que des suppositions je le reconnais bien.

Ce qui laisse le cas d'un disque système externe à part, je ne sais pas ce qu'ont choisi les ingénieurs Apple dans ce cas, car le disque n'est pas ejectable et est connecté avant le boot de macOS, peut être n'y a-t-il pas de Trim dans ce cas particulier, et c'est assez difficile de le déterminer.
 
  • J’aime
Réactions: iDanGener
J'en conclu que l'on peut lire des crétineries partout, y compris sur le site de iFixIt :(
Et les forums de MacGeneration.

«⚠️ Attention avec un SSD avec une partition APFS, l'activation de Trim n'est pas recommandée
APFS comporte deux commandes assez similaires, qui font largement doublon avec la commande TRIM. L’interaction entre les deux jeux de commandes pouvait entrainer des baisses assez paradoxales de performances, notamment sur les disques externes, cela peut expliquer ce genre de remarque. J’explique le fonctionnement détaillé de la commande TRIM et des commandes APFS similaires dans cet article :


Je n’irais pas jusqu’à déconseiller d’utiliser la commande TRIM sur un volume APFS, Apple elle-même l’active sur le disque de démarrage, et la prend en charge de manière tout à fait officielle sur les disques externes reliés en USB avec un contrôleur compatible avec la commande Unmap. Ma conclusion n’a pas changé : si tu peux utiliser la commande TRIM, utilises-la, si tu ne peux pas, APFS et les contrôleurs des SSD font déjà une partie du boulot et ce n’est pas la fin du monde.
 
APFS comporte deux commandes assez similaires, qui font largement doublon avec la commande TRIM.
C'est un concept intéressant, tu as des références ?

Donc au vu de ceci... C'est préférable, non ?
Superbe illustration, tu l'as trouvée ou ?
Ca correspond tout à fait à ce que j'en avais compris, et très bien expliqué.
 
Voir mon message précédent.
Dans mon article cité dans le message précédent, justement.
Ah oupss... N'ayant pas accès je n'ai pas été voir, mais j'aurais au moins pu reconnaitre les illustration ;)

Mais ceci dit, je n'ai jamais vu d'information de référence établissant qu'un système de fichiers puisse remplacer le TRIM par autre chose, si quelqu'un a ça je suis intéressé.

Pour tout dire, je pense que les systèmes de fichiers en CoW (comme APFS) dépendent plus du TRIM que les autres car ils génèrent plus de blocs libres, mais je n'ai pas trouvé d'infos fiables la dessus.
 
Mais ceci dit, je n'ai jamais vu d'information de référence établissant qu'un système de fichiers puisse remplacer le TRIM par autre chose, si quelqu'un a ça je suis intéressé.
Déjà tu n’utilises pas forcément la commande TRIM, mais souvent la commande unmap, première imprécision commune (qui n’est grave). Ensuite les systèmes de fichiers conçus pour les SSD embarquent tout un tas de commandes qui repoussent l’utilisation de la commande TRIM, ou s’en servent dans le cadre d’opérations fort plus complexes, deuxième imprécision commune (qui est un peu plus dérangeante). Tu mélanges tout ça avec les légendes urbaines, ou plus simplement les avis mal éclairés de gens qui n’ont pas révisé leurs connaissances depuis plusieurs années alors que les technologies ont bien avancé, et ça donne les conneries que je lis à longueur de journée un peu partout, y compris sur ces forums. Ça explique que je prenne la peine d’écrire des articles sur ce genre de sujets.

N'ayant pas accès
Et là ce n’est plus une imprécision, c’est une erreur, il FAUT être abonné au Club iGen ! :D
 
Déjà tu n’utilises pas forcément la commande TRIM, mais souvent la commande unmap, première imprécision commune (qui n’est grave).
Oui et non, l'OS envoi bien un Unmap sur le Bus USB, mais uniquement parce que le mode bulk classique de l'USB est incapable de transmettre le Trim, et que les constructeur de contrôleurs USB/SATA et USB/NVMe ont eu l'ingénieuse idée d'émuler le jeu de commandes SCSI pour profiter de sa richesse (et de sa performance) via le protocole UASP.
Mais au final, ce Unmap est converti en fonction du type de disque, ce dernier recevant un Trim s'il est en SATA ou un Deallocate s'il est en NVMe.

Ensuite les systèmes de fichiers conçus pour les SSD embarquent tout un tas de commandes qui repoussent l’utilisation de la commande TRIM, ou s’en servent dans le cadre d’opérations fort plus complexes, deuxième imprécision commune (qui est un peu plus dérangeante).
Je ne doute pas qu'il soit possible d'implémenter un système de fichier de manière à aider le disque à optimiser son fonctionnement, mais je n'ai pas lu grand chose de concret là-dessus, et surtout je ne vois pas en quoi cela peut permettre de se passer de Trim/Deallocate/Unmap sans perte de performance du SSD. Mais je veux bien apprendre, si tu as des références (accessibles) ?

Par exemple j'ai du mal à déterminer si le mode CoW d'APFS est favorable au SSD, ou si ce ne serait pas plutôt le contraire, le SSD permettant d'implémenter le CoW sans perte de performance due à la fragmentation ?


Tu mélanges tout ça avec les légendes urbaines, ou plus simplement les avis mal éclairés de gens qui n’ont pas révisé leurs connaissances depuis plusieurs années alors que les technologies ont bien avancé, et ça donne les conneries que je lis à longueur de journée un peu partout, y compris sur ces forums. Ça explique que je prenne la peine d’écrire des articles sur ce genre de sujets.
C'est tout à ton honneur, et c'est ton droit d'être payé pour le faire.
De mon côté je suis plus dans l'échange gratuit d'informations mutuellement enrichissantes.

Et là ce n’est plus une imprécision, c’est une erreur, il FAUT être abonné au Club iGen ! :D
Je n'en doute pas :D
 
  • J’aime
Réactions: baron
Oui et non, l'OS envoi bien un Unmap sur le Bus USB, mais uniquement parce que le mode bulk classique de l'USB est incapable de transmettre le Trim, et que les constructeur de contrôleurs USB/SATA et USB/NVMe ont eu l'ingénieuse idée d'émuler le jeu de commandes SCSI pour profiter de sa richesse (et de sa performance) via le protocole UASP.
Merci de confirmer ce que j’ai écrit en long, en large, et en travers ces dix dernières années :D

je ne vois pas en quoi cela peut permettre de se passer de Trim/Deallocate/Unmap sans perte de performance du SSD
Ce que je n’ai jamais écrit, pour le coup, tu remarqueras.

Par exemple j'ai du mal à déterminer si le mode CoW d'APFS est favorable au SSD, ou si ce ne serait pas plutôt le contraire, le SSD permettant d'implémenter le CoW sans perte de performance due à la fragmentation ?
Je crois que tu confonds deux mécanismes qui peuvent certes avoir des interactions positives, mais ne sont pas strictement liés. (Et je ne suis pas certain de comprendre pourquoi tu opposes les deux parties de ta phrase : ce sont les deux, mon capitaine.) Le mécanisme de copy-on-write assure que les données déjà présentes sur le « disque » ne sont pas recopiées inutilement, et que des blocs sont alloués uniquement aux données modifiées. En assistant le ramasse-miettes, la commande TRIM libère plus précocement les blocs obsolètes, qui peuvent alors être utilisés pour enregistrer ces modifications. Mais le mécanisme de copy-on-write n’empêche pas qu’il faille utiliser le ramasse-miettes pour consolider des pages et marquer des blocs comme obsolètes, et n’empêche pas l’utilisation d’algorithmes de wear leveling pour répartir les données sur les cellules les moins utilisées. Au contraire : lorsqu’il doit écrire des données, APFS lui-même utilise une sorte de wear leveling, et reporte les modifications sur de nouveaux blocs en laissant au ramasse-miettes le soin de libérer les anciens blocs marqués comme obsolètes.

Je ne mentionne d’ailleurs pas le mécanisme de copy-on-write dans mon papier sur la commande TRIM : les deux sujets ne sont que très tangentiellement liés. Si l’on veut discuter de fonctions d’APFS qui sont plus intimement liées à la commande TRIM, et peuvent aider à compenser son éventuelle absence, mieux vaut parler du Space Manager et de Reaper, comme je le fais d’ailleurs dans le papier précité. Le document de référence sur APFS reste… la référence, quoique parfois elliptique et surtout très technique : https://developer.apple.com/support/downloads/Apple-File-System-Reference.pdf Howard Oakley a écrit quelques bons articles sur le sujet, mais ils sont assez chevelus, j’essaye de faire plus accessible dans les miens. Pierre Dandumont a probablement écrit quelques articles sur APFS aussi.

(Mais on s’éloigne un tantinet de la question originale, à laquelle j’apporte une réponse simple à la fin de ma réponse #6. À la fin on se fait des nœuds au cerveau pour pas grand-chose : la commande TRIM est maintenant disponible dans la plupart des cas, et lorsqu’elle est disponible, elle est utilisée à bon escient par le système de fichiers. La question « to TRIM or not to TRIM » doit mourir.)
 
Merci de confirmer ce que j’ai écrit en long, en large, et en travers ces dix dernières années :D
Ce que je n’ai jamais écrit, pour le coup, tu remarqueras.
Répéter la bonne parole ne peut nuire ;)

Je crois que tu confonds deux mécanismes qui peuvent certes avoir des interactions positives, mais ne sont pas strictement liés. (Et je ne suis pas certain de comprendre pourquoi tu opposes les deux parties de ta phrase : ce sont les deux, mon capitaine.)
Je ne les confond ni ne les oppose, je les pense indissociables, le mode copy-on-write génèrant plus de secteurs obsolètes que le ramasse miette ne peut identifier de lui-même. Cela rend, pour moi, le Trim encore plus indispensable en APFS qu'avant (contrairement à ce que l'on peut lire sur certaines pages de IfixIt français).

Le mécanisme de copy-on-write assure que les données déjà présentes sur le « disque » ne sont pas recopiées inutilement, et que des blocs sont alloués uniquement aux données modifiées. En assistant le ramasse-miettes, la commande TRIM libère plus précocement les blocs obsolètes, qui peuvent alors être utilisés pour enregistrer ces modifications. Mais le mécanisme de copy-on-write n’empêche pas qu’il faille utiliser le ramasse-miettes pour consolider des pages et marquer des blocs comme obsolètes, et n’empêche pas l’utilisation d’algorithmes de wear leveling pour répartir les données sur les cellules les moins utilisées. Au contraire : lorsqu’il doit écrire des données, APFS lui-même utilise une sorte de wear leveling, et reporte les modifications sur de nouveaux blocs en laissant au ramasse-miettes le soin de libérer les anciens blocs marqués comme obsolètes.

Je ne mentionne d’ailleurs pas le mécanisme de copy-on-write dans mon papier sur la commande TRIM : les deux sujets ne sont que très tangentiellement liés.
Globalement d'accord, au bémol près que pour moi le Trim n'est pas optionnel en APFS (Apple a même fini par le gérer en USB, c'est dire :D).

Si l’on veut discuter de fonctions d’APFS qui sont plus intimement liées à la commande TRIM, et peuvent aider à compenser son éventuelle absence, mieux vaut parler du Space Manager et de Reaper, comme je le fais d’ailleurs dans le papier précité. Le document de référence sur APFS reste… la référence, quoique parfois elliptique et surtout très technique : https://developer.apple.com/support/downloads/Apple-File-System-Reference.pdf Howard Oakley a écrit quelques bons articles sur le sujet, mais ils sont assez chevelus, j’essaye de faire plus accessible dans les miens. Pierre Dandumont a probablement écrit quelques articles sur APFS aussi.
Comme je disais, sujet mal connu sur lequel il y a peu de littérature concrète :dead:

(Mais on s’éloigne un tantinet de la question originale, à laquelle j’apporte une réponse simple à la fin de ma réponse #6. À la fin on se fait des nœuds au cerveau pour pas grand-chose : la commande TRIM est maintenant disponible dans la plupart des cas, et lorsqu’elle est disponible, elle est utilisée à bon escient par le système de fichiers. La question « to TRIM or not to TRIM » doit mourir.)
:up:
 
Je ne les confond ni ne les oppose, je les pense indissociables, le mode copy-on-write génèrant plus de secteurs obsolètes que le ramasse miette ne peut identifier de lui-même.
Euh, non.

Comme je disais, sujet mal connu sur lequel il y a peu de littérature concrète :dead:
Je ne suis pas certain de pouvoir faire plus concret que LA référence APFS, donc bonne lecture !
 
Statut
Ce sujet est fermé.