Ponemos a prueba el temido disco SMR Red de Western Digital

EFAX Red de Western Digital, un disco SMR, se enfrenta a un Seagate Ironwolf en las pruebas de hoy.

Jim Salter

Western Digital ha recibido una avalancha de malas noticias, e incluso demandas, relacionadas con el intento de insertar la tecnología de disco SMR en su línea «Roja» de discos NAS. Para lidiar mejor con la situación, Ars compró una unidad Western Digital 4TB Red EFAX SMR y la puso a prueba.

Aunque el disco SMR de 4TB de Western Digital funcionó correctamente en las pruebas de servicio ligero de Servethehome, tuvo un desempeño deficiente cuando lo usaron para reemplazar un disco en un RAIDz1 vdev de cuatro discos degradado.

Recientemente, el conocido sitio de entusiastas de la tecnología Servethehome probó uno de los discos rojos de 4 TB basados ​​en SMR con ZFS y descubrió que faltaba. El disco funcionó bien, aunque no es sorprendente, en pruebas de rendimiento genéricas. Pero cuando Servethehome lo usó para reemplazar un disco en un vdev RAIDz1 degradado, tomó más de nueve días completar la operación, cuando todas las unidades NAS de la competencia realizaron la misma tarea en aproximadamente dieciséis horas.

Esto ha suscitado dudas sobre lo que estaba pensando Western Digital cuando intentó utilizar la tecnología SMR en unidades NAS, y mucho menos tratar de llevarla al mercado. ¿Western Digital incluso probó los discos? Sin embargo, a pesar de lo valiosas que han sido las pruebas ZFS de Servethehome, ignoraron el caso de uso más común para esta clase de unidad: dispositivos NAS para consumidores y pequeñas empresas, como DS1819 + de Synology o ReadyNAS RN628X00 de Netgear. Todos usan el kernel RAID de Linux (mdraid) para administrar sus matrices.

Reconstrucción de una matriz RAID6 de ocho discos al 75%

Después de comprar una unidad WD 4TB Red EFAX como la que probó Servethehome, usamos nuestro equipo de prueba existente con ocho unidades Seagate Ironwolf en el Ars Storage Hot Rod para crear una matriz RAID6. Nuestros ocho discos Ironwolf son 12T cada uno, por lo que los dividimos a 3500GiB por pieza; esto hizo que la matriz fuera lo suficientemente pequeña como para que nuestro nuevo disco WD Red pudiera «caber» como reemplazo cuando fallamos con un Ironwolf.

Cuando creamos la matriz RAID6, usamos el argumento -b none, para evitar intentar realizar una exploración de mapa de bits para acelerar las reconstrucciones cuando se usa un disco que estaba previamente en la matriz. Y formateamos usando el sistema de archivos ext4, con argumentos -E lazy_itable_init=0,lazy_journal_init=0 para que los procesos en segundo plano no contaminen nuestras pruebas con una actividad de la unidad que los usuarios normales normalmente no enfrentarían.

Publicidad

Después de formatear los nuevos ocho discos, la matriz de 19TiB, volcamos 14TiB de datos en catorce subdirectorios, cada uno con 1.024 archivos de 1GiB llenos de datos pseudoaleatorios. Esto llevó a la matriz a algo más del 75% de uso. En este punto, fallamos un registro de Ironwolf fuera de la matriz, hicimos un wipefs -a /dev/sdl1 en él para eliminar los encabezados RAID existentes y luego volver a agregarlo a la matriz ahora degradada. Esta fue nuestra línea de base.

Después de que Iron Wolf se reconstruyó con éxito en la matriz, volvimos a fallar y, esta vez, lo eliminamos por completo del sistema y lo reemplazamos con nuestro conejillo de indias Red SMR de 4 TB. Primero, alimentamos todos los 4 TB rojos a la matriz degradada como reemplazo del Iron Wolf dividido que falta. Entonces, una vez que se completó la reconstrucción, fallamos nuevamente, wipefs -atomó su encabezado RAID y lo agregó nuevamente para reconstruirlo por segunda vez.

Esto nos dio nuestros dos casos de prueba: un disco Red SMR nuevo de fábrica que se reconstruye en una matriz y un disco Red SMR usado con una gran cantidad de datos que ya se están reconstruyendo en una matriz. Creemos que fue importante probar en ambos sentidos, ya que cada caso es un uso común de los discos NAS en el mundo real. También parecía probable que un disco SMR lleno de datos pudiera funcionar peor que uno nuevo, que no necesitaría leer-modificar-escribir, ya que se trataba de zonas utilizadas anteriormente.

El SMR EFAX se reconstruyó perfectamente en nuestra matriz RAID6 convencional, incluso cuando el 75% de su capacidad ya estaba llena.

Jim Salter

No nos sorprendió que el disco SMR se desempeñara bien en la primera prueba; aparte de la ira de los consumidores, parecía poco probable que Western Digital hubiera enviado estos discos sin ninguna prueba. Nos sorprendió más ver que funcionaba de la misma manera en una condición usada y cuando era nueva: el firmware de la unidad podía codificar los datos lo suficientemente bien como para que no tomara ni un minuto más reconstruir desde una condición «usada». «como lo hizo cuando era joven.

Publicidad

Prueba de escritura aleatoria simple de 1 MiB

Claramente, el firmware del WD Red estuvo a la altura del desafío de manejar una reconstrucción RAID convencional, lo que equivale a una prueba de escritura secuencial de bloques enorme, muy grande. Lo siguiente que se debía verificar era si EFAX manejaría una versión pesada del caso de uso diario típico de un NAS de consumo, es decir, almacenar archivos grandes.

Una vez más, a primera vista, WD Red pasa la prueba. En términos de rendimiento, Red es solo un 16,7% más lento que su competencia Ironwolf no SMR. Incluso probando nuevamente por segunda vez, cuando el firmware tiene un trabajo más difícil para lidiar con áreas que ya están llenas, no cambia la imagen significativamente.

Cuando profundizamos un poco más y miramos fionúmeros de latencia, las cosas se ven notablemente peores. EFAX Red es un 68,8% más lento en promedio para regresar de una operación que Ironwolf, pero, de nuevo, este es el territorio de «no ganar la carrera», no el territorio de «serás demandado por fraude». Solo cuando observamos la latencia máxima de la prueba de escritura aleatoria de 1 MiB comenzamos a ver qué tan mal pueden ponerse las cosas cuando presionas el rojo en direcciones no planificadas. Su peor retorno de caso es de 1,3 segundos, más de diez veces peor que el retorno más lento del Iron Mill de 108 milisegundos.

Podemos extrapolar a partir de este resultado de latencia máxima que cuando el firmware de Red tiene muchas dificultades, su rendimiento puede caer por debajo de 1 MiB / s durante un tiempo, y esto se correlaciona con los números de rendimiento en cambio constante que vimos mientras veíamos las pruebas de rendimiento en ejecución. También nos dice que para un usuario de escritorio, alguien que quiere que sucedan cosas cuando hacen clic en botones y arrastran cosas, Red ocasionalmente puede proporcionar una experiencia realmente frustrante durante lo que debería ser una carga de trabajo muy fácil, incluso para un Unidad convencional.