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 . ¹ 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 .]

¹ 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.

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.

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".

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).

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 ...

;);)