Stresstest von SD-Karten unter Linux

19

Ich habe gestern eine kleine Debatte mit jemandem über die Logik und / oder Richtigkeit meiner Antwort hier geführt , vis., Dass das Aufzeichnen und Verwalten von fs-Metadaten auf einer anständigen SD-Karte (GB +) niemals signifikant genug sein könnte, um die Karte zu tragen in einem angemessenen Zeitraum (Jahre und Jahre). Das Gegenargument schien zu sein, dass ich mich irren muss, da so viele Geschichten über Leute online sind, die SD-Karten tragen.

Da ich Geräte mit SD-Karten habe, die rund um die Uhr verfügbare RW-Root-Dateisysteme enthalten, hatte ich die Voraussetzung zuvor zu meiner eigenen Zufriedenheit getestet. Ich habe diesen Test ein wenig optimiert, ihn wiederholt (tatsächlich mit derselben Karte) und präsentiere ihn hier. Die zwei zentralen Fragen, die ich habe, sind:

  1. Ist die Methode, mit der ich versucht habe, die Karte zu zerstören, realisierbar, wenn ich bedenke, dass sie die Auswirkungen des fortlaufenden erneuten Schreibens kleiner Datenmengen reproduzieren soll ?
  2. Ist die Methode, mit der ich überprüft habe, ob die Karte noch in Ordnung ist, noch praktikabel?

Ich stelle die Frage hier eher als SO 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 dass dies einige erfordern würde Spezialkenntnisse in Linux.

[Es könnte auch sein, dass SD-Karten eine Art Smart Buffering oder Cache verwenden, sodass wiederholte Schreibvorgänge an derselben Stelle an einem Ort gepuffert / zwischengespeichert werden, der weniger anfällig für Abnutzung ist. Ich habe nirgendwo einen Hinweis darauf gefunden, aber ich frage im SU]

Die Idee hinter dem Test ist, millionenfach in denselben kleinen Block auf der Karte zu schreiben. Dies geht weit über jede Behauptung hinaus, wie viele Schreibzyklen solche Geräte aushalten können, aber vorausgesetzt, dass ein Verschleißausgleich effektiv ist, sollten Millionen solcher Schreibvorgänge, wenn die Karte eine anständige Größe hat, immer noch nicht viel ausmachen, wie "derselbe Block" nicht buchstäblich der gleiche physische Block sein. Um dies zu tun, musste ich sicherstellen, dass jeder Schreibvorgang wirklich auf die Hardware und an den gleichen offensichtlichen Ort übertragen wurde.

Für das Löschen auf Hardware habe ich mich auf den POSIX-Bibliotheksaufruf verlassen 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,"BEGIN\n");

    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 %d\n", r, w);
            if (errno) {
                fprintf(stderr,"%s\n", strerror(errno));
                break;
            }
        }
        if (fdatasync(out) != 0) {
            fprintf(stderr,"Sync failed: %s\n", strerror(errno));
            break;
        }
        count++;
        if (!(count % 1000)) {
            thousands++;
            fprintf(stderr,"%d000...\n", thousands);
        }
        lseek(out, 0, SEEK_SET);
    }
    fprintf(stderr,"TOTAL %lu\n", count);
    close(in);
    close(out);

    return 0;
}                                 

Ich habe dies ~ 8 Stunden lang ausgeführt, bis ich 2 Millionen + Schreibvorgänge am Anfang der /dev/sdb1Partition gesammelt hatte . 1 Ich hätte es einfach benutzen können /dev/sdb(das Raw-Gerät und nicht die Partition), aber ich kann nicht sehen, welchen Unterschied dies machen würde.

Ich habe dann die Karte überprüft, indem ich versucht habe, ein Dateisystem zu erstellen und darauf zu mounten /dev/sdb1. 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 durch Abnutzungsnivellierung abgenutzt und verschoben wurden, sondern zugänglich bleiben.

Um das zu testen, habe ich badblocks -v -wauf der Partition verwendet. Dies ist ein zerstörerischer Lese- / Schreibtest, der jedoch eine Abnutzungsbereinigung nach sich zieht oder nicht. Er sollte ein starkes Indiz für die Machbarkeit der Karte sein, da immer noch Platz für jedes rollierende Schreiben vorhanden sein muss. Mit anderen Worten, es ist das wörtliche Äquivalent, die Karte vollständig auszufüllen und dann zu überprüfen, ob alles in Ordnung war. Mehrmals, da ich Badblocks ein paar Muster durcharbeiten ließ.

[Gegen Jason Cs Kommentare unten, es ist nichts Falsches oder Falsches daran, Badblocks auf diese Weise zu benutzen. Es wäre zwar aufgrund der Art der SD-Karten nicht nützlich, um fehlerhafte Blöcke zu identifizieren, aber es ist in Ordnung, zerstörerische Lese- / Schreibtests beliebiger Größe mit den Schaltern -bund durchzuführen. In diesem Fall wurde -cder überarbeitete Test durchgeführt (siehe meine eigene Antwort) ). Keine Menge an Magie oder Zwischenspeicherung durch den Controller der Karte kann einen Test täuschen, bei dem mehrere Megabyte Daten auf die Hardware geschrieben und wieder korrekt zurückgelesen werden können. Die anderen Kommentare von Jason scheinen auf einem falschen Verständnis zu beruhen - IMO auf einem absichtlichen , weshalb ich mich nicht darum gekümmert habe, darüber zu streiten. Wenn dieser Kopf frei ist, überlasse ich es dem Leser zu entscheiden, was Sinn macht und was nicht .]

1 Die Karte war eine alte 4-GB-Sandisk-Karte (sie hat keine "Klassen" -Nummer), die ich kaum benutzt habe. Denken Sie noch einmal daran, dass dies nicht 2 Millionen Schreibvorgänge sind, die buchstäblich am selben physischen Ort abgelegt werden. Aufgrund der Abnutzungsnivellierung wurde der "erste Block" während des Tests ständig von der Steuerung bewegt, um, wie der Begriff besagt, die Abnutzung auszugleichen.

Goldlöckchen
quelle
Dies ist aus den unten aufgeführten Gründen ein unzuverlässiger Test. Sie können auch nicht badblockszum Anzeigen von Seitenfehlern auf einem Flash-Laufwerk verwenden (und behaupten, dass dies sehr irreführend ist). Diese werden vom Controller verarbeitet und reserviert, wenn sie erkannt werden. Das physische Layout der Daten auf dem Laufwerk stimmt nicht mit dem physischen Layout überein, das Sie bei E / A-Vorgängen sehen. Auf diese Weise wird die Transparenz beim Abnutzungsausgleich beibehalten. Nichts davon ist für Sie während der E / A sichtbar. Wenn das Laufwerk SMART unterstützt, können Sie höchstens ein paar Informationen zu Fehlern und dem verbleibenden reservierten Speicherplatz vom Controller abrufen.
Jason C
Was /dev/sdb1vs betrifft , /dev/sdbmacht es keinen Unterschied für Ihr Programm, aber was den Unterschied ausmacht (wie unten beschrieben), ist, dass der Status nicht verwendeter Blöcke auf Ihrem Gerät unbekannt ist und in Ihrem Test nicht berücksichtigt wird, und es sei denn, Sie füllen das gesamte Gerät aus (z. B. ) Bei Daten ist zunächst die Größe des Raumverschleißniveaus, mit dem gearbeitet werden muss, eine Hauptvariable. Während Gerät und Partition für Ihren Test irrelevant sind, ist dies meistens eine Folge eines fehlerhaften Tests, da nach ordnungsgemäßem Füllen des Geräts mit Daten keine Option pro Partition verfügbar ist (es sei denn, Sie haben danach formatiert). /dev/sdb
Jason C
Ein weiterer Punkt, der Ihren Test unrealistisch macht, ist, dass eine Seite ausfallen kann (und es ist durchaus üblich), die SD-Karte danach jedoch zu 100% verwendbar bleibt. Wenn ein Fehler vom Controller erkannt und ausgeblendet wird, die Daten jedoch nicht gelesen werden können, können Dateisystemdaten beschädigt werden, wenn der Controller versucht, den Block zu kopieren.
Jason C
Ich sage Ihnen was - beschreiben Sie mir in spezifischen Begriffen einen reproduzierbaren Test , bei dem eine SD-Karte verbraucht ist, und dann nehme ich Sie ernst. Irreproduzierbare "Behauptungen von Autorität" und persönliche Anekdoten sind genau das. Argumentum ab auctoritate
Goldlöckchen
1
Ich weiß nichts über diese Karte, aber die meisten sind sowieso schon ein bisschen tot. Diese Leute haben den Mikrocontroller auf mindestens eine Marke von SD-Karten gehackt : bunniestudios.com/blog/?p=3554 Die Stundenrede, die sie zu diesem Thema führten, war ziemlich gut.
mikeserv

Antworten:

11

Ich denke, Stresstests einer SD-Karte sind im Allgemeinen problematisch, wenn man zwei Dinge bedenkt:

  1. Wear Leveling Es gibt keine Garantie dafür, dass ein Schreibzugriff auf den nächsten dieselben physischen Positionen auf der SD ausübt. Denken Sie daran, dass die meisten vorhandenen SD-Systeme aktiv einen Block wie wir ihn kennen und den physischen Ort, an dem er sich befindet, basierend auf der wahrgenommenen "Abnutzung", der jeder Ort ausgesetzt war, verschieben.

  2. Unterschiedliche Technologien (MLC vs. SLC) Das andere Problem, das ich dabei sehe, ist der Unterschied in den Technologien. SLC-Typen von SSDs Ich würde erwarten, dass sie im Vergleich zur MLC-Variante eine weitaus längere Lebensdauer haben. Außerdem gibt es bei MLC viel engere Toleranzen, mit denen Sie bei SLCs nicht zu tun haben, oder zumindest sind sie viel toleranter, wenn sie auf diese Weise versagen.

    • MLC - Multi Level Cell
    • SLC - Single Level Cell

Das Problem mit MLC besteht darin, dass eine bestimmte Zelle mehrere Werte speichern kann. Die Bits werden im Wesentlichen mit einer Spannung gestapelt, anstatt zum Beispiel nur eine physikalische Spannung von +5 V oder 0 V zu haben. Dies kann zu einem viel höheren Ausfallratenpotenzial als der SLC führen Äquivalent.

Lebenserwartung

Ich habe diesen Link gefunden, der ein wenig beschreibt, wie lange die Hardware halten kann. Der Titel lautet : Know Your SSDs - SLC vs. MLC .

SLC

SLC-SSDs können nach den besten Schätzungen zum größten Teil so berechnet werden, dass sie zwischen 49 und 149 Jahren im Durchschnitt leben. Mit dem Memoright-Test kann die 128-Gbit-SSD mit einer Schreiblebensdauer von mehr als 200 Jahren und einem durchschnittlichen Schreibvolumen von 100 Gbit pro Tag validiert werden.

MLC

Hier fällt das mlc-Design ins Wanken. Bisher wurden noch keine veröffentlicht. Niemand hat wirklich untersucht, welche Art von Lebenserwartung mit dem mlc gewährleistet ist, außer dass diese erheblich niedriger sein wird. Ich habe verschiedene Überzeugungen erhalten, die eine durchschnittliche Lebensdauer von 10 zu 1 zugunsten des SLC-Designs haben. Eine konservative Schätzung ist, dass die meisten Schätzungen der Lebensdauer zwischen 7 und 10 Jahren liegen werden, abhängig von der Weiterentwicklung der "Wear Leveling Algorythms" innerhalb der Controller der einzelnen Hersteller.

Vergleiche

Um den Vergleich über Schreibzyklen zu zeichnen, hätte ein slc eine Lebensdauer von 100.000 vollständigen Schreibzyklen im Vergleich zu dem mlc, der eine Lebensdauer von 10.000 Schreibzyklen hat. Dies kann sich je nach dem verwendeten Design des Verschleißausgleichs erheblich erhöhen.

slm
quelle
1
WRT Wear Leveling "Es gibt keine Garantie, dass ein Schreibzugriff auf den nächsten tatsächlich dieselben physischen Positionen auf der SD ausübt" - das wird in der Frage slm angenommen! Sehr explizit, denke ich ... Ohne Wear Leveling würde ich nie damit rechnen, dass dieser Test bestanden wird, da ich weit über die angegebene maximale Lebensdauer des Schreibzyklus hinausgehe. Der Test soll die Wirksamkeit des Verschleißausgleichs nachweisen , nicht ignorieren. Die Tatsache, dass ich 2 Millionen Mal an dieselbe scheinbare Stelle schreiben kann, deutet darauf hin, dass der Abnutzungsgrad gleich ist.
Goldlöckchen
WRT # 2, Qualität und Technologie werden natürlich eine Karte von der anderen unterscheiden. Mein Punkt ist, dass eine gewöhnliche Sandisk-Karte auch dann noch eine lange Lebensdauer hat, wenn die Datenmenge, die pro Tag geschrieben wird, relativ gering ist.
Goldlöckchen
@goldilocks - OK, OK, verprügel mich nicht. 8-) Also, was Sie sagen ist, wenn ich eine ausreichend große Datenmenge schreibe, so dass ich den Abnutzungsgrad effektiv aus der Gleichung eliminiere, und Badblocks darauf mache, ist das genug, um die Wirksamkeit des Abnutzungsgrads zu zeigen?
slm
1
@goldilocks - habe ich gerade die Büchse der Pandora geöffnet?
slm
1
(Zum Beispiel: Wenn Sie eine SD-Karte klonen, indem Sie ein Image darauf schreiben, und dies anschließend nicht tun / können fstrim, haben Sie die dynamische Abnutzungskorrektur vollständig deaktiviert Markieren Sie jede Seite als gebraucht.)
Jason C
6

Es gibt eine Reihe von Problemen mit Ihrem Test, einige verschwommen, andere nicht. Es hängt auch von Ihrem Ziel ab. Zwei subtile, unscharfe Probleme sind:

  • Sie lesen nicht aus demselben Bereich, in den Sie schreiben, und Ihr Lesetest führt dann effektiv nichts aus (es sei denn, der Controller hat eine Lesestörungskorrektur durchgeführt. In diesem Fall wird die gelesene Seite gelegentlich an einen anderen Ort verschoben, dies ist jedoch immer noch der Fall Ihren Test nicht beeinträchtigen).
  • Sie gehen davon aus (und es ist wahrscheinlich, aber nicht garantiert), dass ein Lese- / Schreibzugriff auf einen fehlerhaften Block vom Controller erkannt und gemeldet wird. Sie möchten Daten schreiben, zurücklesen und für eine garantierte Überprüfung vergleichen.

Diese sind jedoch wohl pedantisch. Ernsthafter ist:

  • Sie können nicht verwenden badblocks, um fehlgeschlagene Seiten im Flash-Speicher anzuzeigen. Alle Fehlererkennungen und nachfolgenden Seitenzuordnungen werden vom Controller vorgenommen und sind für das Betriebssystem transparent. Sie könnten einige Informationen von SMART erhalten, wenn das Laufwerk dies unterstützt (ich kenne keine SD-Karten, die dies unterstützen, möglicherweise gibt es USB-Sticks der höheren Klasse, die dies unterstützen).
  • Verschleißnivellierung, die durch Ihren Test erschwert wird, wobei frühere TRIM-Befehle, der freie / verwendete Zustand des Laufwerks während des Tests und der reservierte Speicherplatz nicht berücksichtigt werden.

Verschleißausgleich: Das Hauptproblem ist, dass der Verschleißausgleich eine wichtige Variable in Ihrem Test ist. Es passiert auf dem Controller (normalerweise) und auf jeden Fall ist es transparent, sogar das Gerät direkt zu suchen + lesen / schreiben. In Ihrem Beispiel kennen Sie den Abnutzungsgrad nicht wirklich (insbesondere wurden kürzlich TRIM-Befehle für freie Blöcke ausgegeben?) ...

Für die dynamische Abnutzungskorrektur (die in praktisch allen Consumer-Speichermedien vorhanden ist) auf Ihrem Gerät kann es sich also um einen beliebigen Zustand handeln: Im Extremfall ist keine der Seiten als frei markiert, sodass der Controller nur auf diesen Seiten arbeiten muss mit sind diejenigen im reservierten Raum (falls vorhanden). Beachten Sie, dass , wenn es ist reservierter Speicherplatz auf dem Gerät, es wird ganz zum Scheitern verurteilt, bevor Sie beginnen garantierten immer nicht auf Seite schreibt (vorausgesetzt , es gibt keine andere Seiten als frei markiert verbleibend). Im anderen Extremfall wird jede Seite als frei markiert. In diesem Fall muss theoretisch jede Seite auf dem Gerät fehlerhaft sein, bevor Schreibfehler auftreten.

Beim statischen Verschleißausgleich (die SSDs haben in der Regel SD-Karten und die USB-Sticks variieren): Abgesehen davon, dass auf jede Seite des Geräts wiederholt geschrieben wird, führt kein Weg daran vorbei.

... Mit anderen Worten, es gibt Details zum Verschleißausgleich, die Sie nicht genau kennen und mit Sicherheit nicht steuern können - insbesondere, ob ein dynamischer Verschleißausgleich verwendet wird, ob ein statischer Verschleißausgleich verwendet wird oder nicht, und die Auf dem Gerät reservierter Speicherplatz für den Verschleißausgleich (der hinter dem Controller nicht sichtbar ist (oder in einigen Fällen, z. B. beim alten DiskOnChip von M-Systems)).

SLC / MLC: Wie bei SLC im Vergleich zu MLC hat dies einen sehr direkten Einfluss auf die erwarteten Grenzwerte, aber das allgemeine Abnutzungsnivellierungsverfahren und das Testverfahren sind für beide gleich. Viele Anbieter veröffentlichen nicht, ob ihre Geräte SLC oder MLC für ihre billigeren Konsumgüter sind oder nicht, obwohl jedes Flash-Laufwerk, das eine Zyklusbegrenzung von 100.000 + pro Seite vorsieht, wahrscheinlich SLC ist (vereinfachter Kompromiss ist SLC = Ausdauer, MLC = Dichte).

Caching: Was das Caching angeht, ist es ein bisschen zweifelhaft. Auf Betriebssystemebene garantiert fsync / fdatasync im Allgemeinen natürlich nicht, dass die Daten tatsächlich geschrieben wurden. Ich denke jedoch, dass es in diesem Fall sicher ist, anzunehmen, dass dies der Fall ist (oder zumindest der Controller sich dazu verpflichtet hat, dh der Schreibvorgang wird nicht im Cache verschluckt), da Wechseldatenträger im Allgemeinen für das allgemeine Verwendungsmuster von ausgelegt sind "auswerfen" (aushängen> synchronisieren) und dann entfernen (Stromausfall). Obwohl wir es nicht genau wissen, kann man davon ausgehen, dass die Synchronisierung die absolute Gültigkeit des Schreibvorgangs garantiert, insbesondere beim Schreiben -> Synchronisieren -> Zurücklesen (wenn dies nicht der Fall wäre, wären die Laufwerke unzuverlässig) nach dem Auswerfen). Es gibt keinen anderen Befehl als 'sync', der beim Auswerfen ausgegeben werden kann.

Auf dem Controller ist alles möglich, aber die obige Annahme beinhaltet auch die Annahme, dass der Controller zumindest nichts "Kompliziertes" genug tut, um einen Datenverlust nach einer Synchronisierung zu riskieren. Es ist vorstellbar, dass die Steuerung Daten beispielsweise puffern und gruppieren oder nicht schreiben kann, wenn dieselben Daten (in begrenztem Umfang) neu geschrieben werden. Im folgenden Programm wechseln wir zwischen zwei verschiedenen Datenblöcken und führen vor dem Zurücklesen eine Synchronisierung durch, um einen vernünftigen Controller-Caching-Mechanismus zu umgehen. Natürlich gibt es noch keine Garantien und keine Möglichkeit zu wissen, aber wir können vernünftige Annahmen treffen, die auf der normalen Verwendung dieser Geräte und vernünftigen / allgemeinen Caching-Mechanismen beruhen.

Testen:

Leider gibt es keine Möglichkeit, das Zykluslimit einer bestimmten Seite definitiv zu testen, es sei denn, Sie wissen, dass das Gerät keinen reservierten Speicherplatz hat und keine statische Nivellierung durchführt. Der nächstmögliche Wert ist jedoch der folgende (vorausgesetzt, es liegt kein statischer Verschleiß vor):

Als erstes müssen Sie die gesamte Karte mit Daten füllen. Dies ist wichtig und die Hauptvariable, die in Ihrem ursprünglichen Test verblieben ist. Dies markiert so viele Blöcke wie möglich, abgesehen von reservierten Bereichen (auf die Sie keinen Zugriff haben). Beachten Sie, dass wir mit einem gesamten Gerät arbeiten (wodurch alle Daten zerstört werden), da das Arbeiten mit einer einzelnen Partition nur einen bestimmten Bereich auf dem Gerät betrifft:

dd if=/dev/urandom bs=512k of=/dev/sdb conv=fsync oflag=sync

Wenn Sie der Fortschrittsbalkentyp sind:

pv -pterb -s <device_size> /dev/urandom | dd bs=512k of=/dev/sdb conv=fsync oflag=sync

Bearbeiten: Versuchen Sie dies für Karten mit 4 MB Löschblöcken für ein schnelleres Schreiben:

dd if=/dev/urandom bs=4M of=/dev/sdb conv=fsync oflag=direct,sync iflag=fullblock

Als nächstes können Sie ein Zyklustestprogramm wie folgt schreiben, wobei Sie O_DIRECTund O_SYNC(und möglicherweise paranoid, redundant fsync()) verwenden, um so viel OS-Pufferung und Caching wie möglich aus dem Bild herauszuschneiden und theoretisch direkt in die Steuerung zu schreiben und warten Sie, bis gemeldet wird, dass der Vorgang abgeschlossen ist:

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <cstdlib>
#include <cstdio>
#include <cstring>

using namespace std;

static const int BLOCK_SIZE = 512;
static const int ALIGNMENT = 512;
static const int OFFSET = 1024 * ALIGNMENT; // 1024 is arbitrary


int main (int argc, char **argv) {

    if (argc != 2) {
        fprintf(stderr, "usage: %s device\n", argv[0]);
        return 1;
    }

    int d = open(argv[1], O_RDWR | O_DIRECT | O_SYNC);
    if (d == -1) {
        perror(argv[1]);
        return 1;
    }

    char *block[2], *buffer;
    int index = 0, count = -1;

    // buffers must be aligned for O_DIRECT.
    posix_memalign((void **)&(block[0]), ALIGNMENT, BLOCK_SIZE);
    posix_memalign((void **)&(block[1]), ALIGNMENT, BLOCK_SIZE);
    posix_memalign((void **)&buffer, ALIGNMENT, BLOCK_SIZE);

    // different contents in each buffer
    memset(block[0], 0x55, BLOCK_SIZE);
    memset(block[1], 0xAA, BLOCK_SIZE);

    while (true) {

        // alternate buffers
        index = 1 - index;

        if (!((++ count) % 100)) {
            printf("%i\n", count);
            fflush(stdout);
        }

        // write -> sync -> read back -> compare
        if (lseek(d, OFFSET, SEEK_SET) == (off_t)-1)
            perror("lseek(w)");
        else if (write(d, block[index], BLOCK_SIZE) != BLOCK_SIZE)
            perror("write");
        else if (fsync(d))
            perror("fsync");
        else if (lseek(d, OFFSET, SEEK_SET) == (off_t)-1)
            perror("lseek(r)");
        else if (read(d, buffer, BLOCK_SIZE) != BLOCK_SIZE)
            perror("read");
        else if (memcmp(block[index], buffer, BLOCK_SIZE))
            fprintf(stderr, "memcmp: test failed\n");
        else
            continue;

        printf("failed after %i successful cycles.\n", count);
        break;

    }

}

Beachten Sie, dass die O_DIRECTPuffer entsprechend ausgerichtet sein müssen. 512-Byte-Grenzen sind im Allgemeinen ausreichend. Sie können kompilieren mit:

g++ -O0 test.cpp -o test

-D_POSIX_C_SOURCE=200112LBei Bedarf hinzufügen .

Nachdem Sie das Gerät wie oben beschrieben vollständig befüllt haben, lassen Sie es einfach über Nacht laufen:

./test /dev/sdb

512 Byte, ausgerichtete Schreibvorgänge sind in Ordnung, sodass Sie eine ganze Seite löschen und neu schreiben können. Sie könnten den Test erheblich beschleunigen, indem Sie einen größeren Block verwenden, aber dann wird es schwierig, konkrete Ergebnisse zu erzielen.

Ich teste derzeit auf einem ziemlich heruntergekommenen 4-GB-PNY-Stick, den ich gestern auf dem Bürgersteig gefunden habe (anscheinend das, was von einem http://www3.pny.com/4GB-Micro-Sleek-Attach-- -Purpur-P2990C418.aspx ).

Das obige Programm ist im Wesentlichen eine eingeschränkte Version von badblocksund Sie würden keine Fehler sehen, bis der gesamte reservierte Speicherplatz erschöpft ist. Daher wird erwartet (mit 1 pro Iteration geschriebenen Seite), dass die oben beschriebene Prozedur im Durchschnitt bei Iterationen mit reserved_page_count * write_cycle_limit fehlschlägt (auch hier ist der Verschleißausgleich eine wichtige Variable). Schade, dass USB-Sticks und SD-Karten normalerweise SMART nicht unterstützen. SMART kann die Größe des reservierten Speicherplatzes melden.

Im fsyncÜbrigen fdatasyncmacht vs keinen Unterschied für die Block-Device-Schreibvorgänge, die Sie für die Zwecke dieses Tests ausführen. Ihre open()Modi sind wichtig.

Wenn Sie neugierig auf technische Details sind; Hier finden Sie alles, was Sie über die Funktionsweise von SD-Karten (und mehr) wissen möchten: https://www.sdcard.org/downloads/pls/simplified_specs/part1_410.pdf

Edit: Bytes vs Pages: Im Zusammenhang mit solchen Tests ist es wichtig, Dinge in Form von Seiten und nicht in Form von Bytes zu betrachten. Es kann sehr irreführend sein, das Gegenteil zu tun. Beispielsweise beträgt bei einer SanDisk 8 GB SD-Karte die Seitengröße gemäß dem Controller (auf den über /sys/classes/mmc_host/mmc?/mmc?:????/preferred_erase_sizezugegriffen werden kann ) volle 4 MB. Beim Schreiben von 16 MB (ausgerichtet an 4 MB-Grenzen) werden dann 4 Seiten gelöscht / geschrieben. Wenn Sie jedoch vier einzelne Bytes mit jeweils 4 MB Versatz voneinander schreiben, werden auch 4 Seiten gelöscht / geschrieben.

Es ist ungenau, zu sagen "Ich habe mit 16 MB Schreibzugriffen getestet", da es den gleichen Verschleiß aufweist wie "Ich habe mit 4-Byte-Schreibzugriffen getestet". Genauer gesagt "habe ich mit 4 Seiten getestet".

Jason C
quelle
Ich habe einen Kommentar in Bezug auf Bytes vs Seiten hinzugefügt.
Jason C
Das PNY erscheint unzerstörbar. Nach ca. 8,1 Millionen Iterationen (über 8 Stunden) auf einer brandneuen SanDisk 8 GB MicroSD, gefolgt von einem Aus- und Wiedereinschalten, sank die maximale Schreibrate (ursprünglich 4 MB / Sek.) Dauerhaft auf ca. 410 KB / Sek. Und schlug ddnach dem Schreiben von 250 MB fehl . Der Schaden trat erst nach dem Aus- und Einschalten auf. Der PNY-Stick bleibt nach ~ 30 Millionen Iterationen unberührt. Ich habe das obige Programm geändert (im obigen Code jedoch nicht berücksichtigt), um jedes Mal an zufälligen 16-KB-ausgerichteten Stellen zu schreiben, anstatt an denselben, aber ich habe das nach ~ 4 Millionen Iterationen auf SD gemacht. Wird mit neuer Karte erneut getestet.
Jason C
Beim dritten Versuch ddauf dieser Karte wurde die 250-MB-Marke überschritten, und die Schreibleistung stieg erneut auf die vollen 4 MB / s in Bereichen nach diesem Punkt. Ich erwarte jedoch, dass die Leistung unvorhersehbar sein wird, da die Blöcke weiterhin gemischt werden. Ich würde nicht sagen, dass die Karte zerstört ist, aber es ist sicherlich nicht zu 100%.
Jason C
5

Nur ein paar Punkte zur Antwort von slm hinzufügen - beachten Sie, dass diese für SSDs besser geeignet sind als für "dumme" SD-Karten, da SSDs viel schmutziger mit Ihren Daten umgehen (z. B. Deduplizierung):

  • Sie schreiben 64 KB an den Anfang des Geräts - dies selbst hat zwei Probleme:

    1. Flash-Zellen haben normalerweise Löschblöcke mit einer Größe ab 16 KB (wahrscheinlicher jedoch im Bereich von 128 bis 512 KB). Das bedeutet, dass ein Cache von mindestens dieser Größe benötigt wird. Daher scheint mir das Schreiben von 64 KB nicht genug zu sein.

    2. Für Low-End-Lösungen (lesen Sie "Nicht-Unternehmen") (und ich würde erwarten, dass dies für die SD / CF-Karten noch mehr gilt als für SSDs) entscheiden sich Hersteller möglicherweise dafür, den Anfang des Geräts widerstandsfähiger zu machen als den Rest seit dem Dort befinden sich wichtige Strukturen - die Partitionstabelle und FAT auf der einzelnen Partition des Geräts (die meisten Speicherkarten verwenden dieses Setup). Das Testen des Kartenanfangs kann daher voreingenommen sein.

  • fdatasync() garantiert nicht wirklich, dass die Daten auf das physische Medium geschrieben werden (obwohl es wahrscheinlich das Beste tut, was unter der Kontrolle des Betriebssystems steht) - siehe Manpage:

    Der Anruf wird blockiert, bis das Gerät meldet, dass die Übertragung abgeschlossen ist

    Es würde mich nicht überraschen, wenn sich herausstellen würde, dass es einen kleinen Kondensator gibt, der in der Lage ist, Energie zum Schreiben von zwischengespeicherten Daten in den Flash-Speicher zu liefern, falls die externe Stromversorgung unterbrochen wird.

    Unter der Annahme, dass ein Cache auf der Karte vorhanden ist (siehe meine Antwort auf Ihre Frage zu SU ), fdatasync()scheint das Schreiben von 64 KB und das Synchronisieren (mit ) für diesen Zweck nicht überzeugend genug zu sein. Auch ohne "Power Backup" spielt die Firmware sie möglicherweise immer noch unsicher ab und hält die Daten länger als erwartet ungeschrieben (da sie in typischen Anwendungsfällen keine Probleme verursachen sollten).

  • Vielleicht möchten Sie die Daten lesen, bevor Sie einen neuen Block schreiben und vergleichen, um sicherzustellen, dass sie wirklich funktionieren (und einen gelöschten Puffer zum Lesen verwenden, wenn Sie paranoid genug sind).

peterph
quelle
+1 Zur Hervorhebung der Cache-Möglichkeit und der Bedeutung des Löschblocks in diesem. Aber ...
Goldlöckchen
"Das Testen des Kartenanfangs könnte voreingenommen sein" Denken Sie daran, dass dies nur anscheinend der erste Block ist, da der Abnutzungsgrad (der im Spiel sein muss - ich habe zu diesem Zeitpunkt eine angemessene Anzahl von Schreibzyklen überschritten) . Das heißt, es ist der erste virtuelle Block, nicht der erste physische Block.
Goldlöckchen
"fdatasync () garantiert nicht wirklich, dass die Daten auf das physische Medium geschrieben werden" IMO, das Gerät, das meldet, dass die Übertragung abgeschlossen wurde, gibt an, dass der Schreibvorgang stattgefunden hat, wenn das Gerät auch Lese- / Schreibtests besteht (hat es nicht) noch nicht bestanden). Zwischenspeichern kann dies erschweren, aber wenn wir einen relativ großen Teil verwenden, um das zu umgehen, ist es einfach nicht möglich, dass "falsche Schreibvorgänge" auftreten, wenn das Gerät einen Erfolg gemeldet hat. Es wäre nutzlos, wenn es das täte.
Goldlöckchen
1
@goldilocks nein, das Zurücklesen der Daten vom Gerät garantiert nichts. Es ist vernünftig zu erwarten , dass sich die Daten auf dem physischen Medium befinden, und dies wird wahrscheinlich in den meisten Fällen der Fall sein, aber dies kann nicht garantiert werden - zumindest wenn Sie nicht über die Cache-Größe hinausgehen.
Peterph
1
@goldilocks peterph bringt eine andere Sache zum Vorschein, auf die ich hinweisen wollte; Das readin Ihrem Test ist unnötig, es fügt keine Informationen hinzu und ist für einen Schreibzyklus-Test nicht relevant. Für einen echten Test sollten Sie den gerade geschriebenen Block zurücklesen und validieren, es sei denn, Sie wissen, dass die Steuerung alle Fehlermodi erkennen und zurückmelden kann.
Jason C
2

Die Antwort von Peterph hat mich veranlasst, das Problem des möglichen Caching weiter zu untersuchen. Nach dem Stöbern kann ich immer noch nicht genau sagen, ob eine, einige oder alle SD-Karten dies tun, aber ich denke, dass es möglich ist.

Ich glaube jedoch nicht, dass das Zwischenspeichern Daten beinhalten würde, die größer als der Löschblock sind. Um ganz sicher zu gehen, habe ich den Test mit einem 16-MB-Block anstelle von 64 KB wiederholt. Dies ist 1/250 des Gesamtvolumens der 4-GB-Karte. Es dauerte ca. 8 Stunden, um dies 10.000 Mal zu tun. Wenn der Verschleißausgleich die Last am besten verteilt, bedeutet dies, dass jeder physische Block 40-mal verwendet worden wäre.

Das ist nicht viel, aber der ursprüngliche Zweck des Tests bestand darin , die Wirksamkeit des Abnutzungsausgleichs zu demonstrieren, indem gezeigt wurde, dass ich die Karte durch wiederholtes Schreiben bescheidener Datenmengen an derselben (scheinbaren) Stelle nicht leicht beschädigen kann. IMO war der vorherige 64 kB Test wohl echt - aber der 16 MB muss man sein. Das System hat die Daten auf die Hardware übertragen und die Hardware hat den Schreibvorgang ohne Fehler gemeldet. Wenn dies eine Täuschung wäre, wäre die Karte für nichts geeignet, und sie kann nur im primären Speicher 16 MB zwischenspeichern, was der Test betonen soll.

Hoffentlich reichen 10.000 Schreibvorgänge mit jeweils 16 MB aus, um zu demonstrieren, dass selbst auf einer Markenkarte mit einem unteren Namen (Wert: 5 USD CDN) ein rund um die Uhr laufendes RW-Root-Dateisystem, das täglich bescheidene Datenmengen schreibt , die Karte nicht abnutzt eine angemessene Frist. 10.000 Tage sind 27 Jahre ... und die Karte ist noch in Ordnung ...

Wenn ich dafür bezahlt würde, Systeme zu entwickeln, die eine höhere Leistung erbringen, würde ich zumindest ein paar Tests durchführen, um festzustellen, wie lange eine Karte halten kann . Meine Vermutung ist, dass es bei einer solchen mit niedriger Schreibgeschwindigkeit Wochen, Monate oder Jahre dauern kann, bis mit maximaler Geschwindigkeit fortlaufend geschrieben wird (die Tatsache, dass es nicht viele vergleichende Tests dieser Art online gibt, spricht für die Tatsache, dass es eine sehr lange Angelegenheit wäre).

Im Hinblick auf die Bestätigung, dass die Karte noch in Ordnung ist, halte ich die Verwendung badblocksin der Standardkonfiguration nicht mehr für angemessen. Stattdessen habe ich es so gemacht:

badblocks -v -w -b 524288 -c 8

Das heißt, Sie testen mit einem 512-kB-Block, der 8 Mal wiederholt wird (= 4 MB). Da es sich um einen zerstörerischen RW-Test handelt, wäre er wahrscheinlich in Bezug auf die Beanspruchung des Geräts bei Verwendung in einer Endlosschleife so gut wie mein selbst erstellter Test.

Ich habe auch ein Dateisystem darauf erstellt, in eine 2-GB-Datei kopiert, diffdie Datei mit dem Original abgeglichen und sie dann - da die Datei eine .iso-Datei war - als Image gemountet und das Dateisystem darin durchsucht.

Die Karte ist noch in Ordnung. Was wohl doch zu erwarten ist ...

;);)

Goldlöckchen
quelle
Ich denke nicht, dass deine Mathematik richtig ist. Eine Class 2-Karte hat einen Durchsatz von 2 MB / s, dh, Sie benötigen in etwa 4 Monaten 20 TB. Sicher, Sie haben erwähnt, dass Sie eine nicht klassifizierte Karte haben, aber Sie scheinen wirklich Größenordnungen darunter zu sein (wie Terdon in unix.stackexchange.com/questions/84902/… ausführte ). Ansonsten stimme ich slm voll zu.
Peterph
Ich glaube, wir können ziemlich sicher sein, dass das Caching nach einer Synchronisierung für Medien, die häufig entfernt werden sollen und auch über den Bus mit Strom versorgt werden, nur minimale oder gar keine Auswirkungen hat. Beachten Sie, dass diese Geräte zuverlässig "ausgeworfen" und entfernt werden können und dass eine Synchronisierung das absolut letzte ist, was ein Betriebssystem mit einem anderen Gerät tun kann, als die Stromversorgung zu unterbrechen (sofern dies möglich ist). Es ist zu vermuten, dass z. B. ein USB-Laufwerk oder eine SD-Karte entweder nach der Synchronisierung physisch beschrieben oder nach dem Ausschalten in extrem kurzer Zeit beschrieben wird.
Jason C
Übrigens badblockswerden Ihnen fehlgeschlagene Seiten im Flash-Speicher nicht angezeigt . Es ist nicht das richtige Werkzeug für diesen Job und Sie können es nicht verwenden, um fehlerhafte Seiten in Flash zu finden. Wenn der Controller einen Fehler feststellt, markiert er die Seite intern als fehlerhaft und ordnet sie einer Seite im reservierten Bereich zu. All dies geschieht hinter dem Controller und ist für Sie selbst in einem Raw-Device-Dump überhaupt nicht sichtbar . Sie könnten einige Informationen vom Controller erhalten, wenn SMART unterstützt wird. Die physische Reihenfolge der Daten auf dem Gerät stimmt nicht mit der Reihenfolge der Bytes überein, die Sie beim Ausführen von E / A auf dem Gerät sehen.
Jason C
Noch ein Kommentar, eher ein FYI: Auf einer SanDisk 8 GB MicroSD mit Consumer-Note beträgt die Zuordnungseinheit (dh die Seitengröße) 4 ​​MB, wie vom Controller gemeldet. Dies bedeutet, dass 16 MB auf dieser Karte 4 Seiten umfassen (5, wenn sie nicht ausgerichtet ist). Sie könnten diesen Test beschleunigen, indem Sie 512 Byte mit 4 MB Versatz voneinander schreiben, anstatt der Karte 16 MB zuzuführen. Sie unterscheiden nicht zwischen Bytes und Seitenzahl, aber Sie sollten es tun - in Ihrem Beispiel, wenn es sich um eine SanDisk 8-GB-Karte handelt, trägt "16MB" dieselbe Abnutzung auf der Karte wie "2KB". Es ist sehr irreführend, auf Bytes anstatt auf Seiten zu verweisen.
Jason C
Nach ca. 8,1 Millionen Iterationen (über 8 Stunden) in dem Testprogramm, das ich oben geschrieben habe, gefolgt von einem Aus- und Wiedereinschalten auf einer brandneuen SanDisk 8GB MicroSD, ist die Schreibgeschwindigkeit permanent auf ca. 450 kB / s begrenzt und konnte ddnicht länger als ca. 250 MB schreiben Kennzeichen. Beim dritten ddVersuch wurden 250 MB überschritten, und sobald dies der Fall war, stieg die Schreibleistung in diesen Bereichen erneut an. Ich würde nicht sagen, dass die Karte zerstört ist, aber es ist sicherlich nicht zu 100%.
Jason C