¿TRIM evita el impacto en el rendimiento de mdadm RAID 1 en SSD?

Question

Ya se mencionó en otras preguntas que Red Hat recomienda no usar mdadm RAID 1 en SSD.

Red Hat también advierte que no se recomienda el uso de los niveles de software RAID 1, 4, 5 y 6 en SSD. Durante la etapa de inicialización de estos niveles RAID, algunas utilidades de administración RAID (como mdadm) escriben en todos los bloques del dispositivo de almacenamiento para garantizar que las sumas de verificación funcionen correctamente. Esto hará que el rendimiento del SSD se degrade rápidamente.

Entiendo el razonamiento detrás de esto. Sin embargo, sospecho que esto fue escrito antes de la llegada demdtrim, que está diseñado específicamente para mdadm RAID 1. ¿Eso evita el problema? Si mi comprensión de TRIM es correcta, entonces creo que sí, pero no estoy seguro, por eso pregunto.

Sin embargo, es posible que TRIM no sea adecuado para mí. Necesito esto para un sistema de producción y mdtrim parece, en el mejor de los casos, experimental. Más importante aún, necesito un cifrado sólido yinvestigaciónha demostrado que TRIM revela demasiado al resaltar qué partes del disco están realmente en uso. ¿Hay alguna forma de evitar el problema de rendimiento y seguir teniendo un cifrado sólido? Me preguntaba si era posible hacer un TRIM parcial, liberando algunos de los bloques para el rendimiento, pero no tantos como para revelar demasiado.

Una sugerencia que vi fue usar solo alrededor del 80% de cada disco para que después de que mdadm realice su verificación inicial, todavía queden algunos bloques sin usar. ¿Pero no serían estos bloques los primeros en usarse en el uso posterior del disco? Todavía se consumirían bastante rápido y entonces no estaría mejor, ¿verdad?

Answer 1

Claro, puedes realizar un recorte parcial con mdtrim (ver --reserveopción) para dejar siempre una cantidad de espacio libre sin recortar. O simplemente puede crear un archivo grande con dd(1) en su FS cifrado para utilizar algo de espacio, que luego nunca será recortado (ni utilizado por usted). Supongo que recortar casi el 30% del espacio no utilizado le brindará muchos beneficios de rendimiento, sin comprometer mucho la seguridad.

puede (como sugiere) hacer un sobreaprovisionamiento en lugar de recortar (en SSD nuevo o borrado de forma segura por ATA) creando una partición con solo el 80% del espacio y usarla en su lugar. No "se agotará con bastante rapidez y luego no estará mejor". He aquí por qué:

Supongamos (para simplificar) que su disco tiene 10000 sectores (LBA). Cuando particiones de modo que solo se use la mitad (nuevamente por simplicidad), solo usarás LBA 0-4999, mientras que LBA 5000-9999 nunca se tocará. Ahora, el nivel de firmware en la unidad tiene dos formas de saber qué sectores no se utilizan: aquellos que su sistema operativo especificó mediante TRIM y aquellos en los que se están reescribiendo. Por lo tanto, si escribe en LBA 100 por primera vez, se utilizará (por ejemplo, en el bloque físico 123). Cuando escriba en LBA 100 segundos, el SSD lo escribirá en una nueva ubicación (por ejemplo, el bloque físico 124) y luego marcará la versión ANTIGUA de LBA 100 (que es el bloque físico 123) como no utilizada (TRIMed), por lo que más adelante cuando el SSD está inactivo, puede realizar la recolección de basura y (si todos los demás bloques físicos en ese bloque de borrado tampoco se utilizan), borrar el bloque de borrado completo (que es mucho más grande que el bloque de escritura físico, por ejemplo, 512 KB frente a 4 KB).

Entonces, al reducir el rango de LBA utilizados a la mitad, se aumenta la cantidad de sectores físicos sobreaprovisionados que la unidad puede usar. No se "agotarán", pero necesita tener suficientes para que la fragmentación en ellos (bloques físicos parcialmente usados ​​y parcialmente no utilizados en el mismo bloque de borrado) desaparezca antes de que se quede sin espacio libre (de lo contrario, el firmware SSD necesitará copiar los bloques usados ​​en otra ubicación antes de borrar todo el bloque de borrado, lo que provocará amplificación de escritura, bajo rendimiento y vida útil más corta del SSD)

El comando TRIM sigue siendo útil ya que acelera ese proceso (y sin perder tanto espacio) al marcar los sectores no utilizados antes de que sea necesario volver a escribirlos (y así también evitar la escritura adicional y prolongar la vida útil del SSD).

Answer 2

Para agregar a la respuesta anticuada, recientemente reemplacé un disco duro fallido en mi RAID1 con un SSD, a partir de los experimentos y las investigaciones que realicé, encontré lo siguiente:

• Linux md pasa comandos TRIM a las unidades constituyentes desde ~2.6.39, pero solo si todas admiten el comando TRIM.
  • Para mi HDD+SSD RAID1, tuve que fallar y quitar el HDD, ejecutar TRIM y luego --re-addel HDD.
• TRIM se puede realizar en un dispositivo de bloque activo usando fstrim, Linux md luego lo transmitirá al SSD.
• La recuperación inicial de RAID1 escribirá en todo el SSD.
• El script mdtrim aún es experimental y no se ha actualizado en años.
• Al usar TRIM en los bloques excesivamente escritos, se puede liberar espacio a los ojos del firmware SSD y mejorar el rendimiento, reducir la amplificación de escritura y más.