Linux – Stresstest von SD-Karten mit Linux?

Ich bin gestern mit jemandem in eine kleine Debatte über die Logik und / oder Richtigkeit meiner Antwort hier geraten, nämlich dass das Protokollieren und Verwalten von fs-Metadaten auf einer SD-Karte mit anständiger Größe (GB+) niemals bedeutsam genug sein könnte, um die Karte zu tragen in einem angemessenen Zeitraum (Jahre und Jahre) heraus. Der Kern des Gegenarguments schien zu sein, dass ich mich irren muss, da es online so viele Geschichten über Leute gibt, die SD-Karten verschwenden.

Da ich Geräte mit SD-Karten darin habe, die rw-Root-Dateisysteme enthalten, die rund um die Uhr aktiv sind, hatte ich die Prämisse zuvor zu meiner eigenen Zufriedenheit getestet. Ich habe diesen Test etwas angepasst, wiederholt (mit der gleichen Karte) und stelle ihn hier vor. Die zwei zentralen Fragen, die ich habe, sind:

1. Ist die Methode, mit der ich versucht habe, die Karte zu zerstören, praktikabel, wenn man bedenkt, dass sie dazu gedacht ist, die Auswirkungen des kontinuierlichen Neuschreibens von klein zu reproduzieren? Datenmengen?
2. Ist die Methode, mit der ich überprüft habe, dass die Karte in Ordnung war, noch praktikabel?

Ich stelle die Frage hier eher als S.O. oder SuperUser, weil ein Einwand gegen den ersten Teil wahrscheinlich behaupten müsste, dass mein Test nicht wirklich so auf die Karte geschrieben hat, wie ich mir sicher bin, und dies zu behaupten, würde einige spezielle Linux-Kenntnisse erfordern.

[Es könnte auch sein, dass SD-Karten eine Art intelligenter Pufferung oder Cache verwenden, sodass wiederholte Schreibvorgänge an derselben Stelle an einem weniger verschleißanfälligen Ort gepuffert/cachet werden. Ich habe nirgendwo einen Hinweis darauf gefunden, aber ich frage danach auf S.U.]

Die Idee hinter dem Test ist, denselben kleinen Block auf der Karte millionenfach zu beschreiben. Dies geht weit über jede Behauptung hinaus, wie viele Schreibzyklen solche Geräte aushalten können, aber vorausgesetzt, Wear Leveling ist effektiv, wenn die Karte eine anständige Größe hat, sollten Millionen solcher Schreibvorgänge immer noch nicht viel ausmachen, da „derselbe Block“ es tun würde nicht buchstäblich derselbe physische Block sein. Um dies zu tun, musste ich sicherstellen, dass jeder Schreibvorgang wirklich auf die Hardware übertragen wurde und scheinbar Ort.

Für das Flushing auf die Hardware habe ich mich auf den POSIX-Bibliotheksaufruf fdatasync() verlassen :

#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;
}                                 

Ich habe dies ungefähr 8 Stunden lang ausgeführt, bis ich mehr als 2 Millionen Schreibvorgänge angesammelt hatte an den Anfang von /dev/sdb1 Partition. Ich hätte einfach /dev/sdb verwenden können (das Raw-Gerät und nicht die Partition), aber ich kann nicht sehen, welchen Unterschied das machen würde.

Ich habe dann die Karte überprüft, indem ich versucht habe, ein Dateisystem auf /dev/sdb1 zu erstellen und zu mounten . Dies funktionierte und zeigte an, dass der spezifische Block, an den ich die ganze Nacht geschrieben hatte, machbar war. Dies bedeutet jedoch nicht, dass einige Bereiche der Karte nicht abgenutzt und durch Wear Levelling verschoben, sondern zugänglich gelassen wurden.

Um das zu testen, habe ich badblocks -v -w verwendet auf der Trennwand. Dies ist ein destruktiver Read-Write-Test, ob Wear-Leveling oder nicht, es sollte ein starker Hinweis auf die Machbarkeit der Karte sein, da sie immer noch Platz für jeden fortlaufenden Schreibvorgang bieten muss. Mit anderen Worten, es ist das wörtliche Äquivalent dazu, die Karte vollständig auszufüllen und dann zu überprüfen, ob alles in Ordnung war. Mehrmals, da ich Badblocks ein paar Muster durcharbeiten lasse.

Verwandt:MVC Unit Testing ?

[Im Gegensatz zu den Kommentaren von Jason C unten ist nichts Falsches oder Falsches daran, Badblocks auf diese Weise zu verwenden. Obwohl es aufgrund der Natur von SD-Karten nicht nützlich wäre, um fehlerhafte Blöcke zu identifizieren, ist es in Ordnung, um destruktive Lese-Schreib-Tests beliebiger Größe mit dem -b durchzuführen und -c Schalter, wo der überarbeitete Test hinging (siehe meine eigene Antwort). Keine Magie oder Zwischenspeicherung durch den Controller der Karte kann einen Test täuschen, bei dem mehrere Megabyte an Daten auf die Hardware geschrieben und korrekt wieder gelesen werden können. Jasons andere Kommentare scheinen auf einer Fehlinterpretation zu beruhen – meiner Meinung nach absichtlich eins, weshalb ich mich nicht die Mühe gemacht habe zu argumentieren. Mit diesem Kopf oben überlasse ich es dem Leser, zu entscheiden, was Sinn macht und was nicht .]

Die Karte war eine alte 4-GB-Sandisk-Karte (sie hat keine „Klassen“-Nummer darauf), die ich kaum benutzt habe. Denken Sie noch einmal daran, dass dies nicht 2 Millionen Schreibvorgänge an buchstäblich denselben physischen Ort sind; Aufgrund des Verschleißausgleichs wird der „erste Block“ während des Tests ständig vom Controller bewegt, um, wie der Begriff sagt, den Verschleiß auszugleichen.

Akzeptierte Antwort:

Ich denke, Stresstests für eine SD-Karte sind im Allgemeinen problematisch, wenn man zwei Dinge berücksichtigt:

1. Verschleißnivellierung
   Es gibt keine Garantie dafür, dass ein Schreibvorgang zum nächsten tatsächlich dieselben physischen Speicherorte auf der SD verwendet. Denken Sie daran, dass die meisten vorhandenen SD-Systeme aktiv einen Block nehmen, wie wir ihn kennen, und den physischen Standort, der ihn unterstützt, basierend auf der wahrgenommenen „Abnutzung“, der jeder Standort ausgesetzt war, verschieben.

2. Unterschiedliche Technologien (MLC vs. SLC)
   Das andere Problem, das ich dabei sehe, ist der Unterschied in den Technologien. Ich würde erwarten, dass SLC-SSD-Typen im Vergleich zur MLC-Variante eine weitaus längere Lebensdauer haben. Außerdem gibt es bei MLC viel engere Toleranzen, mit denen Sie sich bei SLCs einfach nicht auseinandersetzen müssen, oder zumindest sind sie viel toleranter gegenüber solchen Fehlern.

   • MLC – Zelle mit mehreren Ebenen
   • SLC – Einstufige Zelle

Das Problem bei MLC besteht darin, dass eine bestimmte Zelle mehrere Werte speichern kann, die Bits im Wesentlichen unter Verwendung einer Spannung gestapelt werden, anstatt beispielsweise nur physisch +5 V oder 0 V zu sein, sodass dies zu einer viel höheren Ausfallrate führen kann als ihr SLC Äquivalent.

Lebenserwartung

Ich habe diesen Link gefunden, der ein wenig darüber diskutiert, wie lange die Hardware halten kann. Es trägt den Titel:Know Your SSDs – SLC vs. MLC.

SLC

SLC-SSDs können nach den besten Schätzungen größtenteils so berechnet werden, dass sie im Durchschnitt zwischen 49 und 149 Jahre alt werden. Die Memoright-Tests können bestätigen, dass die 128-GB-SSD eine Schreiblebensdauer von über 200 Jahren bei einem durchschnittlichen Schreibvorgang von 100 GB pro Tag aufweist.

MLC

Hier greift das mlc-Design zu kurz. Bisher wurde noch keine veröffentlicht. Niemand hat wirklich untersucht, welche Lebenserwartung mit dem mlc gesichert ist, außer dass sie erheblich niedriger sein wird. Ich habe mehrere unterschiedliche Überzeugungen erhalten, die im Durchschnitt eine Lebensdauer von 10 zu 1 zugunsten des SLC-Designs ausmachen. Eine vorsichtige Schätzung ist, dass die meisten Schätzungen der Lebensdauer zwischen 7 und 10 Jahren liegen werden, abhängig von der Weiterentwicklung der „Verschleißausgleichsalgorithmen“ in den Steuerungen der einzelnen Hersteller.

Vergleiche

Zum Vergleich anhand der Schreibzyklen hätte ein slc eine Lebensdauer von 100.000 vollständigen Schreibzyklen im Vergleich zum mlc, der eine Lebensdauer von 10.000 Schreibzyklen hat. Dies kann je nach verwendetem Design des „Wear Leveling“ erheblich zunehmen.