Linux – ¿Pruebas de estrés en tarjetas SD usando Linux?

Ayer tuve un pequeño debate con alguien sobre la lógica o la veracidad de mi respuesta aquí, es decir, que registrar y mantener los metadatos de fs en una tarjeta SD de tamaño decente (GB+) nunca podría ser lo suficientemente significativo como para usar la tarjeta. en un tiempo razonable (años y años). La esencia del contraargumento parecía ser que debo estar equivocado ya que hay tantas historias en línea de personas que desgastan las tarjetas SD.

Dado que tengo dispositivos con tarjetas SD que contienen sistemas de archivos raíz rw que se dejan encendidos las 24 horas del día, los 7 días de la semana, probé la premisa antes para mi propia satisfacción. Modifiqué un poco esta prueba, la repetí (usando la misma tarjeta, de hecho) y la presento aquí. Las dos preguntas centrales que tengo son:

1. ¿Es viable el método que usé para intentar arruinar la tarjeta, teniendo en cuenta que está destinado a reproducir los efectos de volver a escribir continuamente pequeño? cantidades de datos?
2. ¿Es viable el método que utilicé para verificar que la tarjeta aún estaba bien?

Estoy planteando la pregunta aquí en lugar de S.O. o SuperUser porque una objeción a la primera parte probablemente tendría que afirmar que mi prueba realmente no escribió en la tarjeta de la forma en que estoy seguro de que lo hace, y afirmar eso requeriría un conocimiento especial de Linux.

[También podría ser que las tarjetas SD usen algún tipo de almacenamiento en búfer inteligente o caché, de modo que las escrituras repetidas en el mismo lugar se almacenen en un búfer/caché en un lugar menos propenso a desgastarse. No he encontrado ninguna indicación de esto en ninguna parte, pero estoy preguntando sobre eso en S.U.]

La idea detrás de la prueba es escribir en el mismo pequeño bloque de la tarjeta millones de veces. Esto va mucho más allá de cualquier afirmación de cuántos ciclos de escritura pueden soportar estos dispositivos, pero suponiendo que la nivelación de desgaste sea efectiva, si la tarjeta es de un tamaño decente, millones de tales escrituras aún no deberían importar mucho, ya que "el mismo bloque" lo haría. no ser literalmente el mismo bloque físico. Para hacer esto, necesitaba asegurarme de que cada escritura se descargara realmente en el hardware y en el mismo aparente lugar.

Para descargar al hardware, confié en la llamada de la biblioteca POSIX fdatasync() :

#include <stdio.h>
#include <string.h>
#include <fcntl.h>
#include <errno.h>
#include <unistd.h>
#include <stdlib.h>

// Compile std=gnu99

#define BLOCK 1 << 16

int main (void) {
    int in = open ("/dev/urandom", O_RDONLY);
    if (in < 0) {
        fprintf(stderr,"open in %s", strerror(errno));
        exit(0);
    }

    int out = open("/dev/sdb1", O_WRONLY);
    if (out < 0) {
        fprintf(stderr,"open out %s", strerror(errno));
        exit(0);
    }

    fprintf(stderr,"BEGINn");

    char buffer[BLOCK];
    unsigned int count = 0;
    int thousands = 0;
    for (unsigned int i = 1; i !=0; i++) {
        ssize_t r = read(in, buffer, BLOCK);
        ssize_t w = write(out, buffer, BLOCK);
        if (r != w) {
            fprintf(stderr, "r %d w %dn", r, w);
            if (errno) {
                fprintf(stderr,"%sn", strerror(errno));
                break;
            }
        }
        if (fdatasync(out) != 0) {
            fprintf(stderr,"Sync failed: %sn", strerror(errno));
            break;
        }
        count++;
        if (!(count % 1000)) {
            thousands++;
            fprintf(stderr,"%d000...n", thousands);
        }
        lseek(out, 0, SEEK_SET);
    }
    fprintf(stderr,"TOTAL %lun", count);
    close(in);
    close(out);

    return 0;
}                                 

Ejecuté esto durante ~8 horas, hasta que acumulé más de 2 millones de escrituras al principio de /dev/sdb1 dividir. Podría haber usado fácilmente /dev/sdb (el dispositivo sin procesar y no la partición) pero no puedo ver qué diferencia haría esto.

Luego revisé la tarjeta intentando crear y montar un sistema de archivos en /dev/sdb1 . Esto funcionó, indicando que el bloque específico en el que había estado escribiendo toda la noche era factible. Sin embargo, esto no significa que algunas regiones de la tarjeta no hayan sido desgastadas y desplazadas por la nivelación del desgaste, sino que quedaron accesibles.

Para probar eso, usé badblocks -v -w en la partición. Esto es un destructivo prueba de lectura-escritura, ya sea nivelación de desgaste o no, debería ser una fuerte indicación de la viabilidad de la tarjeta, ya que aún debe proporcionar espacio para cada escritura continua. En otras palabras, es el equivalente literal de llenar la tarjeta por completo y luego verificar que todo esté bien. Varias veces, desde que dejé que los badblocks funcionaran a través de algunos patrones.

Relacionado:¿Prueba de unidad MVC?

[Contra los comentarios de Jason C a continuación, no hay nada malo o falso en usar badblocks de esta manera. Si bien no sería útil para identificar bloques defectuosos debido a la naturaleza de las tarjetas SD, está bien para realizar pruebas destructivas de lectura y escritura de un tamaño arbitrario usando -b y -c interruptores, que es donde fue la prueba revisada (ver mi propia respuesta). Ninguna cantidad de magia o almacenamiento en caché por parte del controlador de la tarjeta puede engañar a una prueba en la que se pueden escribir varios megabytes de datos en el hardware y volver a leerlos correctamente. Los otros comentarios de Jason parecen estar basados ​​en una lectura incorrecta:en mi opinión, es intencional. uno, razón por la cual no me he molestado en discutir. Con ese aviso, dejo que el lector decida qué tiene sentido y qué no. .]

La tarjeta era una tarjeta Sandisk antigua de 4 GB (no tiene un número de "clase") que apenas he usado. Una vez más, tenga en cuenta que no se trata de 2 millones de escrituras literalmente en el mismo lugar físico; debido a la nivelación del desgaste, el controlador habrá movido constantemente el "primer bloque" durante la prueba para, como dice el término, nivelar el desgaste.

Respuesta aceptada:

Creo que la prueba de esfuerzo de una tarjeta SD es, en general, problemática dadas dos cosas:

1. nivelación de desgaste
   No hay garantías de que una escritura a la siguiente realmente esté ejerciendo las mismas ubicaciones físicas en la SD. Recuerde que la mayoría de los sistemas SD en su lugar toman activamente un bloque tal como lo conocemos y mueven la ubicación física que lo respalda en función del "desgaste" percibido al que ha estado sujeto cada ubicación.

2. diferentes tecnologías (MLC vs. SLC)
   El otro problema que veo con esto es la diferencia en las tecnologías. Tipos SLC de SSD Esperaría tener una vida mucho más larga en comparación con la variedad MLC. También hay tolerancias mucho más estrictas en MLC con las que simplemente no tiene que lidiar en SLC, o al menos son mucho más tolerantes a fallar de esta manera.

   • MLC:celda multinivel
   • SLC:celda de un solo nivel

El problema con MLC es que una celda dada puede almacenar múltiples valores, los bits se apilan esencialmente usando un voltaje, en lugar de ser solo un +5V o 0V físico, por ejemplo, por lo que esto puede conducir a un potencial de tasa de falla mucho mayor que su SLC. equivalente.

Esperanza de vida

Encontré este enlace que analiza un poco sobre cuánto tiempo puede durar el hardware. Se titula:Conozca sus SSD:SLC frente a MLC.

SLC

Se puede calcular que los SSD SLC, en su mayor parte, vivan en cualquier lugar entre 49 años y 149 años, en promedio, según las mejores estimaciones. Las pruebas de Memoright pueden validar que la SSD de 128 Gb tenga una vida útil de resistencia de escritura de más de 200 años con una escritura promedio de 100 Gb por día.

MLC

Aquí es donde el diseño de mlc se queda corto. Ninguno ha sido lanzado hasta el momento. Nadie ha examinado realmente qué tipo de esperanza de vida está asegurada con el mlc excepto que será considerablemente menor. He recibido varias creencias diferentes que promedian una vida útil de 10 a 1 a favor del diseño slc. Una conjetura conservadora es que la mayoría de las estimaciones de vida útil serán entre 7 y 10 años, dependiendo del avance de los "algoritmos de nivelación de desgaste" dentro de los controladores de cada fabricante.

Comparaciones

Para realizar una comparación a modo de ciclos de escritura, un slc tendría una vida útil de 100 000 ciclos de escritura completos en comparación con el mlc, que tiene una vida útil de 10 000 ciclos de escritura. Esto podría aumentar significativamente según el diseño de "nivelación de desgaste" utilizado.