Linux - Test de résistance des cartes SD sous Linux ?

J'ai eu un petit débat avec quelqu'un hier concernant la logique et/ou la véracité de ma réponse ici, à savoir que l'enregistrement et la maintenance des métadonnées fs sur une carte SD de taille décente (GB+) ne pourraient jamais être assez importants pour porter la carte dans un délai raisonnable (des années et des années). L'essentiel du contre-argument semblait être que je devais me tromper car il y a tellement d'histoires en ligne de personnes qui utilisent des cartes SD.

Étant donné que j'ai des appareils avec des cartes SD contenant des systèmes de fichiers racine rw qui restent allumés 24h / 24 et 7j / 7, j'avais déjà testé la prémisse à ma propre satisfaction. J'ai un peu peaufiné ce test, je l'ai répété (en utilisant la même carte, en fait) et je le présente ici. Les deux questions centrales que j'ai sont :

La méthode que j'ai utilisée pour tenter de détruire la carte est-elle viable, en gardant à l'esprit qu'elle est destinée à reproduire les effets d'une réécriture continue ? petite quantités de données ?
La méthode que j'ai utilisée pour vérifier que la carte fonctionnait toujours était-elle viable ?

Je pose la question ici plutôt que S.O. ou SuperUser parce qu'une objection à la première partie devrait probablement affirmer que mon test n'a pas vraiment écrit sur la carte comme je suis sûr qu'il le fait, et affirmer que cela nécessiterait une connaissance particulière de Linux.

[Il se peut également que les cartes SD utilisent une sorte de mémoire tampon intelligente ou de cache, de sorte que les écritures répétées au même endroit seraient mises en mémoire tampon/cache dans un endroit moins sujet à l'usure. Je n'ai trouvé aucune indication à ce sujet nulle part, mais je pose la question sur S.U.]

L'idée derrière le test est d'écrire dans le même petit bloc sur la carte des millions de fois. C'est bien au-delà de toute affirmation sur le nombre de cycles d'écriture que ces appareils peuvent supporter, mais en supposant que le nivellement d'usure est efficace, si la carte est d'une taille décente, des millions d'écritures de ce type ne devraient toujours pas avoir beaucoup d'importance, car "le même bloc" le ferait pas littéralement être le même bloc physique. Pour ce faire, je devais m'assurer que chaque écriture était vraiment envoyée au matériel, et au même apparent lieu.

Pour le vidage du matériel, je me suis appuyé sur l'appel de bibliothèque 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;
}

J'ai exécuté cela pendant environ 8 heures, jusqu'à ce que j'aie accumulé 2 millions d'écritures au début du /dev/sdb1 cloison. J'aurais pu facilement utiliser /dev/sdb (le périphérique brut et non la partition) mais je ne vois pas quelle différence cela ferait.

J'ai ensuite vérifié la carte en essayant de créer et de monter un système de fichiers sur /dev/sdb1 . Cela a fonctionné, indiquant que le bloc spécifique dans lequel j'avais écrit toute la nuit était réalisable. Cependant, cela ne signifie pas que certaines régions de la carte n'avaient pas été usées et déplacées par le nivellement d'usure, mais laissées accessibles.

Pour tester cela, j'ai utilisé badblocks -v -w sur la partition. C'est un destructeur test de lecture-écriture, mais nivellement d'usure ou non, cela devrait être une indication forte de la faisabilité de la carte puisqu'elle doit encore fournir de l'espace pour chaque écriture roulante. En d'autres termes, c'est l'équivalent littéral de remplir complètement la carte, puis de vérifier que tout cela était correct. Plusieurs fois, depuis que j'ai laissé les badblocks fonctionner à travers quelques modèles.

Connexes :Tests unitaires MVC ?

[Contrairement aux commentaires de Jason C ci-dessous, il n'y a rien de mal ou de faux à utiliser les badblocks de cette façon. Bien que cela ne soit pas utile pour identifier les blocs défectueux en raison de la nature des cartes SD, cela convient pour effectuer des tests de lecture-écriture destructifs d'une taille arbitraire en utilisant le -b et -c commutateurs, où le test révisé est allé (voir ma propre réponse). Aucune quantité de magie ou de mise en cache par le contrôleur de la carte ne peut tromper un test dans lequel plusieurs mégaoctets de données peuvent être écrits sur le matériel et relus correctement. Les autres commentaires de Jason semblent basés sur une mauvaise lecture - IMO un intentionnel un, c'est pourquoi je n'ai pas pris la peine de discuter. Avec cette tête haute, je laisse au lecteur le soin de décider ce qui a du sens et ce qui ne l'est pas .]

La carte était une vieille carte Sandisk de 4 Go (elle n'a pas de numéro de "classe" dessus) que j'ai à peine utilisée. Encore une fois, gardez à l'esprit qu'il ne s'agit pas de 2 millions d'écritures littéralement au même endroit physique; en raison du nivellement de l'usure, le "premier bloc" aura été constamment déplacé par le contrôleur pendant le test pour, comme le terme l'indique, niveler l'usure.

Réponse acceptée :

Je pense que tester une carte SD sous contrainte est en général problématique étant donné 2 choses :

nivellement d'usure
Rien ne garantit qu'une écriture sur la suivante exerce réellement les mêmes emplacements physiques sur la carte SD. N'oubliez pas que la plupart des systèmes SD en place prennent activement un bloc tel que nous le connaissons et déplacent l'emplacement physique qui le soutient en fonction de l'"usure" perçue à laquelle chaque emplacement a été soumis.
différentes technologies (MLC vs. SLC)
L'autre problème que je vois avec cela est la différence de technologies. Types de SSD SLC Je m'attendrais à avoir une durée de vie beaucoup plus longue par rapport à la variété MLC. De plus, il existe des tolérances beaucoup plus strictes sur les MLC que vous n'avez tout simplement pas à gérer sur les SLC, ou du moins, ils sont beaucoup plus tolérants aux défaillances de cette manière.
- MLC – Cellule à plusieurs niveaux
- SLC – Cellule à un seul niveau

Le problème avec MLC est qu'une cellule donnée peut stocker plusieurs valeurs, les bits sont essentiellement empilés à l'aide d'une tension, plutôt que d'être simplement un + 5V ou 0V physique, par exemple, ce qui peut entraîner un potentiel de taux de défaillance beaucoup plus élevé que leur SLC équivalent.

Espérance de vie

J'ai trouvé ce lien qui explique un peu combien de temps le matériel peut durer. Il s'intitule :Connaissez vos SSD - SLC contre MLC.

SLC

Les SSD SLC peuvent être calculés, pour la plupart, pour vivre entre 49 ans et 149 ans, en moyenne, selon les meilleures estimations. Les tests Memoright peuvent valider le SSD de 128 Go ayant une durée de vie d'endurance en écriture supérieure à 200 ans avec une écriture moyenne de 100 Go par jour.

MLC

C'est là que la conception mlc échoue. Aucun n'a encore été publié. Personne ne s'est vraiment penché sur le type d'espérance de vie assurée avec la mlc sauf qu'elle sera considérablement plus faible. J'ai reçu plusieurs croyances différentes qui s'élèvent en moyenne à une durée de vie de 10 à 1 en faveur de la conception slc. Une supposition prudente est que la plupart des estimations de durée de vie se situeront entre 7 et 10 ans, en fonction de l'avancement des "algorithmes de nivellement d'usure" dans les contrôleurs de chaque fabricant.

Comparaisons

Pour établir une comparaison au moyen de cycles d'écriture, un slc aurait une durée de vie de 100 000 cycles d'écriture complets par rapport au mlc qui a une durée de vie de 10 000 cycles d'écriture. Cela pourrait augmenter de manière significative en fonction de la conception du « nivellement d'usure » utilisé.