Solution 1 :
Depuis le 2.6.37, il devrait être présent (source) . Le noyau ne le fait pas en arrière-plan, le processus de suppression de bloc est actuellement conçu pour être exécuté à la demande (script cron !). La prise en charge de Dm-crypt n'existe pas encore.
Le 13 janvier 2011, un correctif a été fusionné dans dm-raid1.c :
dm raid1: support discard
Enable discard support in the DM mirror target.
Also change an existing use of 'bvec' to 'addr' in the union.
Je ne suis pas à 100%, mais je pense que c'est la fenêtre de fusion pour 2.6.38.
EXT4 a ajouté le support il y a quelque temps, tout comme LVM. RAID est la seule clé qui n'a pas de support. Depuis le 13/01/2011, il semble que la prise en charge ait été ajoutée. Recherchez-le dans 2.6.38 ou peut-être 2.6.39.
Le temps a passé et le support TRIM est définitivement inclus dans le noyau 3.7. Le commit pour RAID10 indique :
Cela permet à md raid 10 de prendre en charge TRIM. Si un disque prend en charge le rejet et un autre non, ou si l'un a des données de rejet_zéro et un autre non, il peut y avoir une incohérence entre les données de ces disques. Mais cela ne devrait pas avoir d'importance, les données rejetées sont inutiles. Cela ajoutera cependant une copie supplémentaire lors de la reconstruction.
Solution 2 :
Retour sur l'historique des commits depuis 2020 :
2010-08:Autoriser la transmission des rejets aux mappages linéaires si au moins un appareil sous-jacent le prend en charge.
2 ans plus tard, il y a des commits concernant md (LSR), l'un d'eux :
2012-10:md :le raid 10 prend en charge TRIM
- Fondamentalement, quelques mois après que j'ai modifié ma réponse précédemment, le noyau Linux est devenu capable de prendre en charge les suppressions de blocs dans la configuration.
Versions précédentes de la réponse :
MISE À JOUR. :Merci à Wodin de me l'avoir fait savoir — selon lkml.org/lkml/2012/3/11/261 cette fonctionnalité a été ajoutée proposé récemment. proposé !=accepté , cependant.
Impossible, car Linux Soft RAID ne le supporte pas (encore ?).