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
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.)
