Cómo verificar que TRIM está llegando a los SSD detrás de un controlador NAS

La salida exitosa de fstrim no prueba que TRIM haya llegado a cada SSD físico. La verificación de extremo a extremo requiere hacer coincidir la presentación del sistema de archivos con evidencia de capas de almacenamiento inferiores.

En un NAS, los bloques descartados pueden pasar por un sistema de archivos, cifrado, LVM, RAID por software, un controlador y un disco virtual antes de que cualquier SSD los vea. Este procedimiento separa el soporte anunciado de la E/S de descarte observada, muestra dónde el RAID por hardware puede ocultar la ruta y evita pruebas destructivas en un grupo en uso.

¿Qué cuenta como prueba de que TRIM llegó al SSD?

La verificación TRIM tiene varios niveles. Un sistema de archivos puede aceptar una solicitud FITRIM, la capa de bloques de Linux puede emitir una E/S de descarte, un controlador puede completarla, y un controlador aún puede traducir, absorber o rechazar el comando antes de que un SSD miembro lo reciba.

Los bytes potenciales de descarte reportados por fstrim describen rangos enviados desde el sistema de archivos a la pila de bloques. No certifican el reenvío por parte del controlador, la eliminación física en la memoria flash, ni siquiera que ejecuciones repetidas representen espacio recién recuperado.

Use el lenguaje más fuerte que su observación más baja soporte. Un rastreo de bloques puede demostrar que Linux emitió un descarte a un dispositivo visible; solo la telemetría del objetivo o del controlador puede extender esa afirmación más allá de un límite RAID oculto. Lo que el SSD haga después pertenece a la recolección de basura del SSD, no a la salida de FITRIM.

Mapee la ruta de almacenamiento antes de probar cualquier cosa.

Comience con el conjunto de datos o recurso compartido montado, luego resuelva su ruta de bloque real. Una cadena común es sistema de archivos, mapeador cifrado, volumen lógico, RAID por software, disco virtual del controlador y SSD físico. Su NAS puede omitir varias capas o ocultar completamente los miembros finales.

Registre el punto de montaje, el sistema de archivos, el árbol de dispositivos, el modelo del controlador, el controlador, el firmware, el modo de operación, el nivel RAID y los modelos de SSD. Las palabras HBA, JBOD, pass-through y modo RAID describen opciones de presentación, pero no garantizan un comportamiento idéntico de descarte entre controladores o versiones de firmware.

También identifique la familia de comandos. Linux llama a la operación discard; los dispositivos SATA comúnmente reciben ATA Data Set Management con TRIM, el almacenamiento SCSI usa UNMAP y NVMe usa semánticas de desasignación. Un puente o controlador debe traducir y reenviar la operación relevante para el dispositivo físico.

Verifique el soporte de descarte anunciado en cada capa visible.

Ejecute lsblk -D y siga el árbol de dispositivos desde el sistema de archivos montado hacia el dispositivo más bajo que Linux expone. Valores distintos de cero DISC-GRAN y DISC-MAX Los valores significan que esa capa anuncia capacidad de descarte; los valores cero identifican una capa donde el soporte está ausente o oculto.

Los límites de la cola de descarte de Linux definen granularidad cero o máximo como sin soporte de descarte anunciado. Verifique los valores correspondientes en /sys/block/DEVICE/queue/ en lugar de leer solo el disco virtual de nivel superior.

La configuración del mapeador aún puede suprimir el paso. Una guía práctica para TRIM a través de la pila de almacenamiento muestra verificaciones para tablas device-mapper y límites de descarte. Trate los valores distintos de cero como permiso para continuar las pruebas, no como prueba de que un comando llegó a un SSD miembro.

Genere un descarte controlado y rastree el dispositivo visible más bajo.

Use una asignación de prueba desechable dentro de un sistema de archivos montado y saludable, no un rango de sectores en bruto. Asegúrese de que la asignación esté comprometida, elimínela, sincronice el sistema de archivos y ejecute un fstrim dirigido mientras rastrea los dispositivos de bloque relevantes. Evite probar durante reconstrucciones, escaneos, estados degradados o escrituras intensas.

Un procedimiento enfocado para auditar el paso de descarte utiliza estadísticas del dispositivo y blktrace para distinguir eventos de descarte de escrituras. Verifique los campos del comando según las herramientas instaladas en su NAS, porque la salida del rastreo y las posiciones de los campos pueden variar según la versión.

1. Resuelva el punto de montaje a cada dispositivo de respaldo visible para el sistema operativo.
2. Capture contadores de descarte y capacidades actuales de la cola.
3. Inicie un rastreo filtrado por descarte en el dispositivo relevante más bajo.
4. Cree, confirme y elimine una asignación de prueba desechable.
5. Ejecute un fstrim contra ese punto de montaje.
6. Detenga el rastreo y compare eventos en cada capa.

Un problema de descarte en un mapeador superior o nodo RAID solo demuestra que la solicitud llegó a ese nodo. Un problema de descarte en el miembro visible más bajo es más fuerte. La finalización del controlador muestra que Linux recibió la confirmación, pero aún no puede revelar el tráfico oculto del controlador al disco.

Sepa dónde termina la prueba detrás del RAID de hardware

Un controlador RAID de hardware puede presentar un disco virtual mientras mantiene invisibles para Linux los SSD miembros y sus flujos de comandos. En esa configuración, el rastreo de bloques puede llegar al límite del controlador pero no puede establecer qué SSD físico recibió TRIM, UNMAP o un equivalente traducido.

Un ejemplo probado de SSDs detrás de controladores RAID mostró capacidad de descarte anunciada cero en modo RAID para el controlador examinado y una exposición diferente en modo JBOD. Trate eso como un patrón diagnóstico específico del modelo, no como una regla para todos los controladores.

Extienda la prueba solo con registros confiables del controlador, estado de aprovisionamiento del objetivo, trazas de protocolo o contadores documentados del disco físico. Los datos SMART no tienen un contador universal de recibo TRIM. Si el controlador no expone telemetría adecuada, el resultado honesto es “el descarte llegó al dispositivo frente al controlador; el recibo físico no está verificado.”

Interprete el resultado sin exagerar

Use la observación confirmada más baja para elegir la próxima acción. La tabla separa la capacidad, el tráfico observado y el recibo físico para que un resultado limpio de fstrim no se convierta silenciosamente en una afirmación más fuerte de lo que la evidencia soporta.

Una pasada aplica solo al sistema de archivos probado, pila, modo de controlador, firmware y modelo de SSD. Verifique nuevamente después de una actualización del controlador, migración RAID, cambio de cifrado o reconstrucción del diseño de almacenamiento porque cualquier capa alterada puede cambiar la exposición o traducción de la eliminación.

No convierta la verificación en pérdida de datos

No ejecute comandos de eliminación directa contra un pool NAS activo. El límite de pérdida de datos de blkdiscard es explícito: el comando elimina bloques en el rango seleccionado, y su opción de fuerza puede omitir la protección de acceso exclusivo.

No confíe en leer ceros después. Linux documenta que el comportamiento de lectura post-eliminación varía y puede ser poco fiable incluso cuando un dispositivo anuncia comportamiento de retorno cero. Un controlador también puede emular el resultado sin exponer el manejo físico de NAND.

Si la confirmación física es obligatoria, use una SSD desechable aislada o una unidad lógica temporal con copias de seguridad probadas e instrucciones específicas del controlador. Para un NAS de producción, la conclusión segura suele estar limitada: demuestre la eliminación hasta el límite observable más bajo, documente lo que permanece oculto y nunca arriesgue el pool solo para convertir “no verificado” en “sí”.