Stimmt es, dass eine SD/MMC-Karte Wear Leveling mit ihrem eigenen Controller durchführt?

Ich kann keine verlässlichen Informationen darüber finden. Ich habe nicht die vollständige Spezifikation der SD/MMC-Kartenhardware.

Ist es wahr? Meine High-Level-Anwendung muss sich bei der Arbeit mit diesen Karten nicht mit Wear Leveling befassen?

BEARBEITEN

Könnte jemand bestätigen, dass Wear Leveling durch die SD-Spezifikation garantiert wird? Ich möchte sicher sein, denn es sieht so aus, als würden die meisten Anbieter dies tun, aber die Spezifikation erfordert es nicht.

Nicht alle Hersteller von Flash-Medien investieren in Wear-Leveling-Algorithmen. Wear Leveling ist häufiger bei SSDs anzutreffen, bei denen die Hersteller aufgrund von Algorithmen den Markt anführen.

Antworten (7)

Ich arbeite für ein Unternehmen, das früher Mitglied der SD Association war, wir sind mit der 2.0 (SDHC)-Spezifikation vertraut. Die SD-Kartenspezifikation hat KEINEN Eintrag für Wear Leveling. Das hängt vollständig vom SD-Hersteller ab, der dies handhabt, wenn er dies wünscht. Wir haben gesehen, dass einige dies wahrscheinlich tun, während andere dies sehr wahrscheinlich nicht tun (Vorsicht vor den supergünstigen gefälschten SD-Karten). SDXC hat das vielleicht geändert, um Wear Leveling einzuschließen, aber da bin ich mir nicht sicher. Leider ist die einzige Möglichkeit, dies wirklich zu zeigen, die offizielle Spezifikation in die Finger zu bekommen. Sie können es höchstwahrscheinlich online finden, aber die SD Association möchte wirklich, dass Sie dafür bezahlen.

Als Nebenbemerkung: Wenn Sie eine 2-GB-Karte nehmen und sie immer wieder von Anfang bis Ende beschreiben, werden im Durchschnitt etwa 10 TB benötigt, bevor die Karte tot und nicht mehr beschreibbar ist. Außerdem lassen SD-Karten Sie nicht wissen, wenn Daten schlecht sind, dh sie geben keinen I/O-Fehler zurück, wie es eine PC-Festplatte tun wird. Dies ist möglicherweise kein Problem für eingebettete Designs, da 10 TB eine Menge Daten sind, aber es könnte für jemanden ein Faktor sein.

Ich gehe davon aus, dass Unternehmen es dennoch tun wollen, um ihren guten Ruf zu wahren, obwohl es nicht in der Spezifikation steht. Während superbillige Fälschungen sich nicht um den Ruf kümmern, werden sie an Leute verkauft, die alles billig kaufen möchten. Klingt das vernünftig?
@Kellenjb Es ist eine sehr vernünftige Annahme, und ich persönlich würde Ihnen zustimmen. Da es jedoch nicht in der Spezifikation enthalten ist und es sehr unwahrscheinlich ist, dass es Zugriff auf die SD-Controller-Designs eines bestimmten Herstellers erhält, kann es nicht wirklich bewiesen werden. Wir haben im Laufe der Jahre viele Tests durchgeführt, einige große Marken schneiden viel besser ab als andere. Es könnten Unterschiede in den internen Algorithmen oder deren vollständiges Fehlen sein.
Billige Nachahmungen werden sich nicht darum kümmern, selbst wenn es in der Spezifikation steht. Es ist für den Kunden nicht sofort sichtbar, es KÖNNTE fehlen. Wir sprechen von Leuten, die Bleistecker als ICs verkaufen. Ich habe noch nie von einer Markenkarte gehört, die kein Wear-Leveling durchgeführt hat, aber ich nehme an, es ist möglich.
@KrisBahnsen können Sie erläutern, was die SD-Karte tatsächlich zurückgibt, wenn ein nicht behebbarer Fehler auftritt? Ich interessiere mich sehr dafür. Gibt es überhaupt keine Möglichkeit, diesen Zustand zu erkennen?
@fredbasset, Weg zum Zombie-Thread;) Es ist eine Weile her, seit ich mit SD-Karten gearbeitet habe. IIRC-SD-Karten selbst geben jedoch physisch zurück, wonach ihnen ist. Einige der neueren in Kombination mit anständigen Treibern können möglicherweise einen E / A-Fehler erkennen. Viele der älteren SD-Karten werden jedoch nur schlechte Daten zurückgeben, die in NAND gespeichert wurden, und sie als gut bezeichnen. Wenn ein Schreibvorgang jedoch nicht abgeschlossen werden kann, wird ein E/A-Fehler zurückgegeben.
Das Versäumnis, einen fehlerhaften Datenlesevorgang anzuzeigen, war das, wovor ich Angst hatte. Wie können Sie definitiv feststellen, ob sich Ihre SD-Karte so verhält oder nicht? Schade, dass sich eine so unzuverlässige Technologie in Linux-Designs eingeschlichen hat. Ist die Verwendung von JFFS2 auf Raw-Nandflash eine zuverlässigere Lösung?
@fredbasset Wenn Linux schlechte Daten erhält, hat es im Allgemeinen einen Anfall. Das Unternehmen, für das ich arbeite, hat einen Prüfsummenprozess direkt auf dem Blockgerät implementiert, der eine Softwareschicht durchläuft. Datenwiederherstellung und Fehler können jetzt über dieses Setup an den Kernel gemeldet werden. Raw NAND ist ein eigenes Biest, aber meiner Erfahrung nach ist es robuster in Bezug auf die Handhabung von Fehlern. Schauen Sie sich UBI und UBIFS an, es ist im Grunde JFFS3, wirklich robust und bietet einige Beschleunigungen.

Es ist wahr! MicroSD-Karten enthalten einen NAND-Flash-Chip, der mit einem (ARM)-Mikrocontroller verbunden ist, der in schwarzem Kunststoff eingekapselt ist. http://www.bunniestudios.com/blog/?p=898 erklärt.

Am Ende des Folgeposts http://www.bunniestudios.com/blog/?p=918 postuliert Bunnie, dass die Integration des Controllers wahrscheinlich weniger kostet, als den Flash im Voraus zu testen.

Zitat aus dem Produkthandbuch für SD-Karten von SanDisk: "1.9 Wear Leveling. Wear Leveling ist ein wesentlicher Bestandteil der Erase-Pooling-Funktionalität der SD-Karte, die NAND-Speicher verwendet." Das Ganze können Sie im Datenblatt einer Karte der Marke SanDisk nachlesen .

Bunnie Huang ist definitiv glaubwürdig genug für mich!
Das ist gut zu wissen, aber ich warte auf jemanden, der diese Frage basierend auf der formalen Spezifikation dieser Technologie aufklären kann.
Digikey zeigte mir diese nutzlose SanDisk-Broschüre , als ich versuchte, ein Datenblatt nachzuschlagen. Die Datenblätter von Wintec und Swissbit waren besser, und beide erwähnten Wear Leveling. Können Sie auf dieses von Digikey gehostete Datenblatt verlinken?
Die sind viel besser als die alte SanDisk.
Das Wintec war nicht großartig, aber das neue SanDisk ist das Beste von allen! Danke für die Bearbeitung.
Bedeutet dies, dass in Sandisks uSD das Wear Leveling in der Karte selbst implementiert ist und der Controller nichts davon weiß?

Ja, SD/MMC-Karten haben Controller, die Wear Leveling durchführen. Wenn sie es nicht täten, könnten Sie einen innerhalb weniger Minuten mit den falschen Schreibmustern zerstören.

Das ist tatsächlich ein Problem für einige eingebettete Projekte. Es gibt (anscheinend) absolut keine Möglichkeit zu wissen, welche Sektoren zu irgendeinem Zeitpunkt abgenutzt sein könnten, sodass ein Aus- und Einschalten zur falschen Zeit Daten überall auf der Karte zerstören kann, egal wo Sie schreiben. (frag nicht woher ich das weiß :))

SD-Karten müssen mit einem System verwendet werden, das ein sauberes Herunterfahren des Systems garantiert (oder zumindest das Abschließen von Schreibvorgängen zulässt), oder es kommt (letztlich) zu Datenverlust.

BEARBEITEN

Das Problem ist, dass der Wear-Leveling-Prozess vollständig verborgen ist. JEDER Sektor auf der Festplatte könnte jederzeit verschoben (ausgetauscht werden, während die Seite geschrieben wird), und wenn der Strom mitten in diesem Prozess ausfallen würde, könnte dieser zufällige Sektor beschädigt werden.

Obwohl es einigermaßen sichere Möglichkeiten gibt, diesen Schritt zu implementieren, ist er in keiner Spezifikation enthalten, sodass Sie nicht darauf vertrauen können, dass die Karte dies tut. Sie könnten eine Karte testen, sie zum Laufen bringen, dann könnte der Hersteller die Implementierung ändern, ohne die Teilenummer zu ändern, und Sie sind am Arsch.

Nach Tests macht der Controller meiner SD-Karten dies überhaupt NICHT auf sichere Weise.

Ich kann mir eine "hochzuverlässige" SD-Karte ansehen, die speziell für Stromausfalltoleranz beworben wurde ... aber dann müssen Sie dem Hersteller vertrauen, dass er das richtig macht, und ich tue es nicht. Ich möchte wirklich die direkte Kontrolle über das Löschen von Seiten haben. Ich versuche immer noch, das herauszufinden.

Siehe meine gepostete Antwort. Da Verschleißausgleichsalgorithmen Sache des Herstellers sind, sind sie möglicherweise nicht auf der Höhe der Zeit. Ein guter Wear-Leveling-Algorithmus verschiebt die Daten zuerst, markiert sie dann als gut und sammelt dann die ursprünglichen Daten. Dies kann bei manchen Karten ein Problem sein, bei anderen vielleicht nicht. SD ist ein sehr hässliches Design, wenn man der Sache auf den Grund geht.
Ja, es ist ein Mist Standard, soweit es mich betrifft. Es ist sehr ärgerlich, dass ein so allgegenwärtiger Speicherstandard so unzuverlässig ist.
@darron, hast du weitere Informationen zu diesem Problem? Das ist eine ernste Sache, aber ich glaube nicht, dass es allgemein bekannt ist.
@jpc: Vielleicht mache ich dann einen Blogeintrag. Ich habe den Eindruck, dass es nicht oft in Betracht gezogen wird. Ich habe die Auswirkungen selbst nicht erkannt, bis es zu spät war. Ich habe damit gekämpft, mit meinem SD-Kartenhersteller gesprochen usw. Keine andere Lösung als die Schreibzeit zu minimieren. Ich schreibe jetzt auf NAND-Flash und kopiere einmal am Tag so schnell ich kann auf SD. Es gibt SD-Karten, die so konzipiert sind, dass sie gegen zufällige Stromausfälle "resistent" sind, aber ich bin mir nicht sicher, ob selbst diese vollständig vertrauenswürdig sind.
... Ich überprüfe auch und doppelt, ob der SD-Schreibvorgang abgeschlossen ist, bevor ich die Daten aus dem NAND-Flash lösche, aber dann ist alles, was garantiert, dass die Daten von gestern in Ordnung sind ... nicht, dass die SD nicht irgendwann vollständig beschädigt wird. Wie auch immer, das massiv kleinere Zeitfenster für Schreibvorgänge macht einen Fehler an dieser Stelle extrem unwahrscheinlich ... aber es ist immer noch möglich.
@darron hast du am Ende SD-Karten mit Industriestandard getestet - wäre sehr daran interessiert, deine Ergebnisse zu hören. Ich arbeite an einem neuen Linux-Board, das uSD als Hauptspeicher verwendet, und mache mir ziemlich Sorgen über Datenbeschädigungen bei plötzlichen Stromausfällen.
@fred basset Seltsamerweise scheinen sich die Spezifikationen für Industriekarten geändert zu haben, seit diese Antwort geschrieben wurde. Ich habe microSD -Karten mit Garantien für Schreibvorgänge gesehen (glaube ich, dass sie in einem Journal gespeichert sind) ... jetzt erheben sie keinen solchen Anspruch. Im Gespräch mit einem Hersteller verwenden sie jetzt Supercaps ... aber nur die Compact-Flash-Karten haben Platz dafür. Dinge sicher zu tun, reduziert die Leistung zu sehr. Sie sagen, dass sie nur irgendwie genug Backup-Strom bereitstellen müssen, um einen Schreibvorgang abzuschließen. Wenn man bedenkt, wie komplex moderne ARM-SBCs sind … ist es wirklich schwierig, dies zu tun, wenn das Referenzdesign des Anbieters dies nicht tut. Keine, die ich kenne.
@darron Du hast vollkommen recht; Alle ARM-Referenzdesigns, die ich bisher gesehen habe, beschönigen das Problem der Beschädigung der SD-Karte vollständig und enthalten kein Supercap usw., um Zeit für ein sicheres Herunterfahren zu haben. Wie viel zuverlässiger ist Ihr Schreiben in NAND-Flash? ZB welches Dateisystem verwenden Sie dort, und was passiert, wenn das System darauf schreibt und es die Stromversorgung verliert?
@freq basset Ich verwende UBI & UBIFS. Es scheint gut zu funktionieren ... Ich habe viele Systeme, die seit Jahren ohne Probleme laufen.
Ich sehe dieses uSD-Datenblatt alliedelec.com/m/d/04db416b291011446889dbd6129e2644.pdf , in dem erwähnt wird, dass Wear Leveling implementiert ist. Ich würde davon ausgehen, dass es Teil der Karte und nicht des Controllers ist. Wenn Sie also sagten, dass der Controller Wear Leveling implementiert, meinten Sie damit das Gerät oder den Mikrocontroller, der mit der SD-Karte kommuniziert?

Jede Art von SD-Karte, die irgendeine Art von herkömmlichem NAND-Flash-Speicher verwendet, muss irgendeine Art von Sektorvirtualisierung verwenden, da kein herkömmliches NAND-Flash-Gerät das Löschen einzelner 512-Byte-Sektoren unterstützen kann und kein herkömmliches NAND-Flash-Gerät von signifikanter Größe würde in der Lage sein, eine Leistung zu erbringen, die in einer Größenordnung liegt, die sogar geringfügig akzeptabel ist, wenn jeder Versuch, einen Sektor zu schreiben, erfordert, dass das Gerät alle Sektoren im Löschblock dieses Sektors (sogar in den RAM) kopiert, dann den Block löscht und schreibt alle Sektoren zurück. Die meisten Sektorvirtualisierungstechniken sind von Natur aus etwas verschleißausgleichend. Ich würde erwarten, dass das größte Problem der Abweichung zwischen Qualitätsgeräten und Imitaten das Ausmaß ist, in dem ein Gerät aktiv versucht, die Nivellierung zwischen den Blöcken auszugleichen. im Gegensatz zur einfachen Verwendung einer pseudozufälligen Blockzuweisung und der Hoffnung, dass dies zu akzeptabel nahezu einheitlichen Ergebnissen führt. In der Praxis würde ich erwarten, dass selbst eine zufällige/auf das Beste hoffende Zuweisung in den meisten Fällen angemessen wäre.

Es kann sehr gut sein, dass das von einigen Herstellern implementierte "Wear Leveling" durch die NAND-Schnittstelle selbst und Block-zu-Sektor-/Sektor-zu-Block-Virtualisierungen verursacht wird.
@KrisBahnsen: Ich würde erwarten, dass Hersteller, die Verschleißausgleich beanspruchen, den relativen Verschleiß verschiedener Blöcke und das Alter der darin enthaltenen Daten aktiv überwachen, und wenn Blöcke mit langlebigen Daten in Blöcken mit viel weniger Verschleiß als im Durchschnitt gefunden werden Daten aus diesen Blöcken werden in Blöcke verschoben, die stärker abgenutzt sind (um höchstwahrscheinlich den zukünftigen Verschleiß dieser Blöcke zu minimieren). Dies könnte die Nutzungsdauer eines Geräts, das zu 95 % mit Daten gefüllt ist, die sich nie ändern, um den Faktor 10 verlängern, während die verbleibenden 5 % des Speicherplatzes häufig bewegt werden.
Ich stimme zu, wenn sie dafür werben, stelle ich mir vor, dass sie eine Art echtes Wear-Leveling durchführen würden. Ich bin dem ganzen Thema gegenüber etwas negativ eingestellt, wofür ich mich entschuldige; Ich wurde ein paar Mal von den Macken von SD gebissen.
@KrisBahnsen: Das größte Problem ist meines Erachtens ein Virtualisierungsmodell, das von einem linearen Bündel fortlaufend nummerierter 512-Byte-Sektoren ausgeht. Es mag bequem gewesen sein, sich mit DOS zu verbinden, aber es passt nicht wirklich gut zu der vorhandenen Hardware oder zu dem, was die Host-Software wirklich will. Erweitern Sie Blocknummern auf 64 Bit und lassen Sie zu, dass sie willkürlich nicht aufeinanderfolgend sind, und arrangieren Sie dann, dass Dateien immer in logisch aufeinanderfolgenden Blöcken gespeichert werden. Um eine Datei zu löschen, löschen Sie ihren Blockbereich.
Dies ist möglicherweise die beste Antwort. Ich vermute, das machen alle so. Wenn Sie darüber nachdenken, gibt es keine Möglichkeit, deterministisches Wear-Leveling mit einem wirklich ausgeklügelten Algorithmus durchzuführen, da die Verschleißhistorie selbst irgendwo auf derselben Karte gespeichert werden müsste und dieser Teil zuerst versagen würde. Die randomisierte Nivellierung ist die einzige praktische Möglichkeit. Ich bin nicht davon überzeugt, dass SSDs intelligenter sind. Sie können einfach mehr Ersatzpuffer haben, obwohl es sicherlich möglich ist, dass sie sehr grobe (und daher selten aktualisierte) Verschleißinformationen speichern.
@Nimrod: Wear Leveling kann sehr gut funktionieren, wenn man über einen Speicherbereich von angemessener Größe verfügt, der atomar in Blöcken geschrieben werden kann, die kleiner als eine Seite sind. Es ist nicht notwendig, dass Löschoperationen atomar sind – lediglich Schreiboperationen.
@Nimrod: Auch ohne die Möglichkeit, Blöcke zu schreiben, die kleiner als eine Seite sind, ist es möglich, eine Gruppe von drei "Root" -Speicherblöcken zu haben, die zum Speichern der Adressen einiger Hauptindexblöcke verwendet werden. Die Dinge können so angeordnet werden, dass zu jeder Zeit, wenn einer der Wurzelblöcke gelöscht wird, die anderen beiden ihn beide als solchen identifizieren werden. Der Hauptindexblock müsste nicht sehr oft verschoben werden, sodass die Root-Blöcke nicht sehr oft beschrieben werden müssten. Wenn man auf einem Teil mit 528-Byte-Seiten, gruppiert in 1024-Seiten-Blöcken, drei Blöcke (3072 Seiten) verwendet, um die Hauptblockpositionen zu verfolgen ...
... man würde nur alle 3072 Änderungen an den Hauptblockpositionen einen Löschzyklus auf dem Wurzelblock durchlaufen. Wenn, anstatt einzelne Blöcke zu identifizieren, jede im Stammblock aufgeführte Adresse einen Bereich von drei Stellen angibt, an denen sich der Hauptblock befinden könnte, und mit diesen einen ähnlichen Ansatz verwendet, und wenn das Teil eine Lebensdauer von 10.000 Schreib-/Löschzyklen hat, dann würde diese Indirektionsebene ausreichen, um einen atomar aktualisierten 528-Byte-Block zu verwalten, der etwa 900.000.000.000 Mal aktualisiert werden könnte, während weniger als 30 wahlfreie Zugriffe erforderlich sind, um den neuesten Wert zu finden.
Das Hinzufügen einer weiteren Indirektionsebene würde die Dinge bis zu dem Punkt bringen, an dem man, selbst wenn man nur bereit wäre, eine Lebensdauer von 3.333 Zyklen anzunehmen, immer noch 1E21-Änderungen an der Hauptseite unterbringen könnte, aber den neuesten Inhalt der Masterseite in weniger als 50 zufälligen Lesevorgängen finden könnte .
Wenn man ein Flash-Laufwerk mit einem NAND-Flash-Chip und einem kleineren NOR-Flash-Chip bauen würde, könnte man die Dinge wahrscheinlich schneller und robuster machen, da NOR-Flash-Chips die Programmierung eines Bytes auf einmal ermöglichen. Tatsächlich vermute ich, dass die Dinge erheblich verbessert werden könnten, selbst wenn einige gültigkeitsbezogene Bits hinzugefügt würden, die eine Seite als einen von vier Zuständen markieren würden: (1) seit dem Löschen nicht berührt; (2) möglicherweise teilweise geschrieben [sollte bis zum nächsten Löschen als unbrauchbar angesehen werden; (3) gültig geschrieben; (4) ausdrücklich ungültig gemacht [offensichtlich unbrauchbar bis zur nächsten Löschung].
Flash-Laufwerke können derzeit jede Seite mit einem Hinweis versehen, welchen logischen Sektor sie darstellt, zusammen mit einer Sequenznummer; Wenn Seiten nur gelesen werden, wenn kein Nachfolger vorhanden ist, und gelöscht werden, wenn ein Nachfolger vorhanden ist, ist der Laufwerksstatus immer wiederherstellbar, selbst wenn Indizes beschädigt werden. Wenn das System jedoch nicht direkt feststellen kann, ob eine Seite ersetzt wurde, könnte ein beschädigter Index beschädigt werden diese Invarianten. Übrigens, ich wünschte, es gäbe ein Standardmittel, mit dem ein Flash-Laufwerk anzeigen könnte, dass Indizes neu erstellt werden müssen, und mit dem eine solche Operation initiiert werden könnte, mit der Einschränkung, dass ...
...das Wiederherstellen von Indizes auf einem großen Laufwerk kann über eine Stunde dauern, und ein Stromausfall könnte einen Neustart erforderlich machen, aber das Laufwerk könnte sehr langsam arbeiten, bis die Indizes neu erstellt wurden.

Sandisk hat ein Whitepaper , das die Wear-Leveling-Logik in seinen Karten erklärt und Schätzungen über die Lebensdauer der Karte unter einer Reihe von Szenarien gibt. Zusammenfassung: Wenn Sie nicht ununterbrochen auf die Karte hämmern, wird sie Jahrzehnte dauern.

Der Link ist tot und der Inhalt scheint gelöscht worden zu sein – weil er vielleicht zu viel preisgegeben hat?
@Cuadue Der Link ist zugänglich. Für den Fall, dass es kaputt geht, ist die Seite jetzt unter web.archive.org/web/20150326122100/http://ugweb.cs.ualberta.ca/…

Es ist interessant festzustellen, dass trotzdem viele Geräte SD- und microSD-Karten beschädigen, insbesondere solche mit hoher Dichte, wenn der Akku schwach ist oder das Telefon abstürzt / herunterfährt / etc. Ich vermute, dass das Problem in einer unzureichenden Regulierung der Spannungsversorgung liegt, da dies bei einigen Karten (hust Ad t /hust) bekanntlich zu dem Phänomen einer nicht lesbaren Karte bei bestimmten externen Lesegeräten führt, aber bei der von einigen gelieferten Micro-Variante problemlos funktioniert Computergeschäfte.

Ich bin gerade dabei, eine Karte mit diesem Fehler wiederherzustellen, seltsamerweise sind die meisten Daten wiederherstellbar, aber einige Sektoren nicht, obwohl sich dies bei jedem Versuch ändert. Könnte das Wear Leveling selbst schuld sein? (Ja, mehrere Lesegeräte ausprobiert, gleicher Fehler!)

Hatte auch einige Erfolge beim "Nuking" von Zombiekarten, dh solchen, die ein Format nicht vervollständigen oder schreibgeschützt sind. Funktioniert nur zu einem kleinen Prozentsatz, aber sie sind viel empfindlicher als die meisten "offiziellen" Richtlinien für die Wirkung.

Eine so behandelte Testkarte hielt volle vier Monate, bevor sie erneut versagte, wenn das Gerät, mit dem sie eine verrauschte Spannung lieferte, nicht gewesen wäre, hätte die Lebensdauer länger sein können.

Mit "Nuking" meinst du es in eine Mikrowelle zu stellen? Bei welcher Wattzahl und wie lange?
Äh, nein :-) Warum auch, wenn eine Glimmentladung (HF) einen ähnlichen Effekt hätte und viel weniger gefährlich wäre als die von mir verwendete Methode? Es stellt sich heraus, dass uSD-Karten viel empfindlicher sind, da auf einer Seite kein Metallgehäuse vorhanden ist.
Ich kann nicht bestätigen oder leugnen, dass Nuking sich aus rechtlichen Gründen auf die Verwendung eines "Gadgets" 5642 + HVPS bezieht. Es hat jedoch wiederholt funktioniert, und die Technik ist jetzt bekannt, da ich sie auf HaD usw. veröffentlicht habe.
Stimmt es, dass eine SD/MMC-Karte Wear Leveling mit ihrem eigenen Controller durchführt?
AntwortenHierDatenschutz-Bestimmungen1y, 0v