Comment vérifier que la commande TRIM atteint les SSD derrière un contrôleur NAS

Une sortie fstrim réussie ne prouve pas que le TRIM a atteint chaque SSD physique. La vérification de bout en bout nécessite de faire correspondre la soumission du système de fichiers avec des preuves provenant des couches de stockage inférieures.

Sur un NAS, les blocs discardés peuvent passer par un système de fichiers, un chiffrement, LVM, un RAID logiciel, un pilote de contrôleur et un disque virtuel avant d’atteindre un SSD. Cette procédure sépare le support annoncé de l’I/O de discard observée, montre où le RAID matériel peut cacher le chemin, et évite les tests destructifs sur un pool en fonctionnement.

Qu’est-ce qui constitue une preuve que le TRIM a atteint le SSD ?

La vérification TRIM comporte plusieurs niveaux. Un système de fichiers peut accepter une requête FITRIM, la couche bloc Linux peut émettre une I/O de discard, un pilote peut la compléter, et un contrôleur peut encore traduire, absorber ou rejeter la commande avant qu’un SSD membre ne la reçoive.

Les octets potentiels à discard rapportés par fstrim décrivent les plages soumises du système de fichiers vers la pile de blocs. Ils ne certifient pas le transfert par le contrôleur, l’effacement physique de la mémoire flash, ni même que les exécutions répétées représentent un espace nouvellement récupéré.

Utilisez la formulation la plus forte que votre observation la plus faible peut soutenir. Une trace de bloc peut prouver que Linux a émis un discard vers un périphérique visible ; seule la télémétrie du contrôleur ou de la cible peut étendre cette affirmation au-delà d’une limite RAID cachée. Ce que fait le SSD ensuite appartient à la collecte des déchets SSD, pas à la sortie FITRIM.

Cartographiez le chemin de stockage avant de tester quoi que ce soit

Commencez par le dataset ou le partage monté, puis résolvez son chemin de bloc réel. Une chaîne courante est système de fichiers, mapper chiffré, volume logique, RAID logiciel, disque virtuel du contrôleur, et SSD physique. Votre NAS peut omettre plusieurs couches ou cacher complètement les membres finaux.

Enregistrez le point de montage, le système de fichiers, l'arbre des périphériques, le modèle du contrôleur, le pilote, le firmware, le mode de fonctionnement, le niveau RAID et les modèles de SSD. Les termes HBA, JBOD, pass-through et mode RAID décrivent des choix de présentation, mais ils ne garantissent pas un comportement identique de discard entre les contrôleurs ou les versions de firmware.

Identifiez également la famille de commandes. Linux appelle l'opération discard ; les périphériques SATA reçoivent couramment ATA Data Set Management avec TRIM, le stockage SCSI utilise UNMAP, et NVMe utilise la sémantique de désallocation. Un pont ou un contrôleur doit traduire et transmettre l'opération pertinente au périphérique physique.

Vérifiez le support discard annoncé à chaque couche visible

Exécutez lsblk -D et suivez l'arbre des périphériques depuis le système de fichiers monté vers le périphérique le plus bas exposé par Linux. Les valeurs non nulles DISC-GRAN et DISC-MAX Les valeurs signifient que la couche annonce la capacité discard ; les valeurs zéro identifient une couche où le support est absent ou caché.

Les limites de la file d'attente discard sous Linux définissent une granularité zéro ou un maximum comme absence de support discard annoncé. Vérifiez les valeurs correspondantes dans /sys/block/DEVICE/queue/ au lieu de lire uniquement le disque virtuel de niveau supérieur.

Les paramètres du mapper peuvent toujours supprimer le passage. Un guide pratique pour TRIM à travers la pile de stockage montre comment vérifier les tables device-mapper et les limites de discard. Considérez les valeurs non nulles comme une permission de continuer les tests, pas comme une preuve qu'une commande a atteint un SSD membre.

Générez un discard contrôlé et tracez le périphérique visible le plus bas

Utilisez une allocation de test jetable à l'intérieur d'un système de fichiers monté sain, pas une plage de secteurs brute. Assurez-vous que l'allocation est engagée, supprimez-la, synchronisez le système de fichiers, puis exécutez un fstrim ciblé tout en traçant les périphériques de bloc concernés. Évitez de tester pendant les reconstructions, les vérifications, les états dégradés ou les écritures intensives.

Une procédure ciblée pour auditer le passage des commandes discard utilise les statistiques des périphériques et blktrace pour distinguer les événements discard des écritures. Vérifiez les champs des commandes en fonction des outils installés sur votre NAS, car la sortie de trace et la position des champs peuvent varier selon la version.

1. Résolvez le point de montage vers chaque périphérique de support visible par le système d'exploitation.
2. Capturez les compteurs de suppression et les capacités actuelles de la file d'attente.
3. Démarrez une trace filtrée sur suppression sur le périphérique pertinent le plus bas.
4. Créez, validez et supprimez une allocation de test jetable.
5. Exécutez un fstrim sur ce point de montage.
6. Arrêtez la trace et comparez les événements à chaque couche.

Un problème de suppression sur un nœud de mappage supérieur ou RAID prouve seulement que la requête a atteint ce nœud. Un problème de suppression sur le membre visible le plus bas est plus fort. L'achèvement du pilote montre que Linux a reçu la confirmation, mais cela ne peut toujours pas révéler le trafic caché du contrôleur vers le disque.

Sachez où s'arrête la preuve derrière un RAID matériel

Un contrôleur RAID matériel peut présenter un disque virtuel tout en gardant les SSD membres et leurs flux de commandes invisibles pour Linux. Dans cette configuration, la traçabilité des blocs peut atteindre la limite du pilote du contrôleur mais ne peut pas établir quel SSD physique a reçu TRIM, UNMAP ou un équivalent traduit.

Un exemple testé de SSD derrière des contrôleurs RAID a montré une capacité de suppression annoncée nulle en mode RAID pour le contrôleur examiné et une exposition différente en mode JBOD. Considérez cela comme un modèle de diagnostic spécifique au modèle, pas comme une règle pour chaque contrôleur.

Étendez la preuve uniquement avec des journaux de contrôleur fiables, l'état de provisionnement de la cible, des traces de protocole ou des compteurs physiques documentés du disque. Les données SMART n'ont pas de compteur universel de réception TRIM. Si le contrôleur n'expose aucune télémétrie appropriée, le résultat honnête est « la suppression a atteint le périphérique côté contrôleur ; la réception physique n'est pas vérifiée ».

Interprétez le résultat sans exagérer

Utilisez l'observation confirmée la plus basse pour choisir l'action suivante. Le tableau sépare la capacité, le trafic observé et la réception physique afin qu'un résultat fstrim clair ne devienne pas silencieusement une affirmation plus forte que ce que les preuves supportent.

Un passage ne s’applique qu’au système de fichiers testé, à la pile, au mode contrôleur, au firmware et au modèle de SSD. Revérifiez après une mise à jour du contrôleur, une migration RAID, un changement de chiffrement ou une reconstruction de la disposition de stockage, car toute couche modifiée peut changer l’exposition ou la traduction de la suppression.

Ne transformez pas la vérification en perte de données

Ne lancez pas de commandes de suppression brute sur un pool NAS en fonctionnement. La limite de perte de données de blkdiscard est explicite : la commande supprime les blocs dans la plage sélectionnée, et son option force peut contourner la protection d’accès exclusif.

Ne comptez pas sur la lecture de zéros par la suite. Linux documente que le comportement de lecture post-suppression varie et peut être peu fiable même lorsqu’un appareil annonce un comportement de retour à zéro. Un contrôleur peut aussi émuler le résultat sans exposer la gestion physique du NAND.

Si une confirmation physique est obligatoire, utilisez un SSD jetable isolé ou une unité logique temporaire avec des sauvegardes testées et des instructions spécifiques au contrôleur. Pour un NAS de production, la conclusion sûre est souvent limitée : prouver la suppression jusqu’à la limite la plus basse observable, documenter ce qui reste caché, et ne jamais risquer le pool simplement pour transformer « non vérifié » en « oui ».