Probé cuatro SSD NVMe de cuatro fabricantes: la mitad pierde datos tras un FLUSH al cortarse la alimentación (2022)

Artículo original ↗ Discusión en Hacker News ↗

Pruebas en SSD NVMe de consumo muestran que algunas unidades pierden datos escritos recientemente tras un corte de alimentación incluso cuando el sistema operativo ha emitido un comando FLUSH y se le ha indicado que los datos están almacenados de forma segura. El hilo identifica modelos concretos que fallaron o aprobaron estas comprobaciones de durabilidad, explora cómo decisiones de firmware y del diseño del controlador pueden llevar a los fabricantes a “mentir” sobre que los datos han quedado comprometidos, y contrasta el hardware de consumo con las unidades empresariales que usan condensadores para protección ante pérdida de energía. Los comentaristas también plantean cuestiones legales y prácticas sobre el cumplimiento de estándares, SSD falsificados o rebajados en el mercado, y qué pueden hacer realmente los sistemas de archivos y las aplicaciones para proteger los datos cuando los dispositivos de almacenamiento no son fiables.

Unidades probadas y resultados

  • El tuit inicial probó cuatro SSD NVMe; dos perdieron datos a pesar de que se informó la finalización de FLUSH.
  • Más adelante en el hilo aparece una lista más grande (12 en total probadas en ese momento):
    • Unidades que se informa que aprobaron la prueba de flush:
      Samsung 970 Evo Plus 2TB, WD Red SN700 1TB, Crucial P2 250GB, Samsung 980 250GB, WD Black SN750 1TB, WD Green SN350 240GB.
    • Unidades que se informa que fallaron (perdieron datos después de flush + corte de alimentación):
      SK Hynix Gold P31 2TB (versión específica de FW), Sabrent Rocket 512GB (basada en Phison).
  • Los comentaristas señalan que el título “la mitad” quedó desactualizado una vez se probaron más unidades (2/12, no 2/4), y que la prueba es de principios de 2022.

Semántica de Flush, PLP y comportamiento del firmware

  • Se supone que NVMe FLUSH garantiza que todas las escrituras anteriores estén en medios no volátiles antes de completarse.
  • Se hace una distinción entre:
    • Unidades que retrasan honestamente la finalización hasta que los datos son seguros.
    • Unidades que mienten al completar antes mientras los datos siguen en una caché volátil.
  • La discusión enfatiza que esto no trata de condensadores de pérdida de energía fallando, sino de violar el contrato de flush.
  • Los SSD empresariales suelen usar condensadores de protección ante pérdida de energía (PLP); los de consumo, en su mayoría, no.
  • Algunos argumentan que si una unidad no puede cumplir FLUSH de forma segura (o si se la abusa con flushes muy pequeños), debería ralentizarse o devolver errores, no mentir.

Sistemas de archivos, síntomas de corrupción y efectos en el mundo real

  • Múltiples informes de archivos que quedan completamente a cero tras caídas o cortes de energía (registros, configuraciones, archivos de caché, metadatos de proyectos).
  • Debate sobre si los archivos puestos a cero provienen de:
    • Unidades que se comportan mal e ignoran la semántica de flush/fua, o
    • Comportamiento del sistema de archivos (asignación diferida de ext4, modos de journaling, TRIM devolviendo ceros para espacio no asignado, uso incorrecto de fsync).
  • Consenso: los sistemas de archivos con journaling (NTFS, ext4) protegen los metadatos, pero no pueden proteger los datos si la unidad subyacente miente.

Unidades de consumo vs empresariales y trade-offs de rendimiento

  • Varios comentarios describen SSD NVMe baratos:
    • Buen rendimiento en ráfagas cortas, pero pésimo rendimiento sostenido y/o rendimiento de sincronización.
    • Gran dependencia de cachés SLC y del comportamiento QLC/TLC.
  • Algunos recomiendan usar solo SSD empresariales/PLP para datos críticos o cargas de trabajo intensivas en sincronización; otros subrayan que incluso las unidades de consumo no deben violar los estándares.

Confianza, regulación y problemas del ecosistema

  • Preocupaciones sobre:
    • Fabricantes que cambian componentes después de la revisión.
    • Cumplimiento falso o incompleto de los estándares.
  • Entre las sugerencias se incluyen retiradas del mercado, acciones de menor cuantía, una aplicación más estricta contra la publicidad engañosa y listas comunitarias de hardware “conocido como bueno/malo”.