Die FAT wird nur angefasst, wenn die Datei tatsächlich einen Cluster wächst. Beim Schreiben eines 120-Byte-Datensatzes kommt das eher selten vor. Allerdings bleibt noch der Verzeichniseintrag, der Größe und Modifizierungszeit enthält. Allerdings wächst zum einen eine Datenbank nicht mit jedem geschriebenen Datensatz (weil das DBMS in größeren Häppchen vorallokiert), zum anderen aktualisiert Windows das m.W. nur beim Schließen der Datei.
Aber ansonsten stimmt's schon: 3 Schreibzugriffe ist vermutlich recht optimistisch geschätzt (gedacht in etwa: Transaktionsanfang, Operation, Transaktionsende).
Ich kann ja morgen mal schauen, was sqlite auf meinem Flash so macht :-)
Hallo NG, betrifft die Angabe "10.000 erase cycles" die Zyklen pro Zelle/Block oder den kompletten Speicher?
Von wikipedia:
formatting link
EEPROM and flash memory media have individually erasable segments, each of which can be put through a limited number of erase cycles before becoming unreliable. This is usually around 1000 cycles but many flash devices have one block with a specially extended life of 100,000+ cycles that can be used by wear levelling controllers.
Wir haben nach vier bis fünf Jahren die ersten Totalausfälle von dauernd beschriebenen CFs, aber nur Einzelfälle bisher, bei dreistelliger Anzahl an GEräten.
-ras
--
Ralph A. Schmid
http://www.dk5ras.de/ http://www.db0fue.de/
http://www.bclog.de/
Keine Ahnung ob Du sowas noch irgendwie dazustricken kannst, könnte aber helfen:
Wie wäre es mit einem Write-Cache in NV-Ram, z.B. gepuffertes SRAM oder einfacher noch FRAM (gibts mittlerweile auch Automotive). Sollte natürlich so gross sein das möglichst selten ins Flash geschrieben wird, also z.B. 2 Flash-Blöcke reinpassen, für Dateisystemverwaltung und aktueller Datenbereich.
So hat man auch definierte Schreibzeiten, man könnte in Verbindung mit einer Unterspannungserkennung und ausreichender Restlaufzeit das System auch gegen Stromausfall sichern. Falls ein Schreibvorgang aufs Flash nicht beendet werden konnte wird er halt beim nächsten Booten durchgeführt, die Daten sind ja noch da.
Ich mache sowas ähnliches mit SD-Karten und On-Board-FRAM, aber relativ low-level, ohne richtiges Betriebssystem und Dateiverwaltung, da ist das einfach.
Inwieweit das die Schreibzugriffe auf das Flash tatsächlich verringert hängt natürlich vom ganzen Drumherum (Dateisystem, Datenbankstruktur) und der Möglichkeit das zu Beeinflussen ab.
Windows-Vista soll Unterstützung für fertige Medien mit integriertem NV-Cache eingebaut haben, aber vermutlich geht es dabei eher um Hybrid-Disks. USB-Sticks mit eingebautem NVRAM-Cache sind mir jedenfalls noch nicht untergekommen.
Ich könnte mir vorstellen das man sich sowas auch mit einem Vinculum-Chip auch relativ einfach selber stricken kann.
Hi Michael, davon ging ich bis jetzt auch immer aus. Habe aber unterschiedliche Aussagen darüber gehört. Und die USB Stick Hersteller schreiben einfach nur "erase cycles" rein... Gruß Andy
Hi Stefan, danke für das ausführliche Posting. Das "oberlehrerhaft" interpretierst du hinein, war nicht böse gemeint und du hast mir ja trotzdem geantwortet :-) Aber du musst ja zugeben, dass die Rechnung nicht so einfach ist wie von Alexander angenommen. Außer man geht davon aus, dass die angegebenen "erase cycles" für den kompletten Stick gelten... Gruß von Andy
Sorry, auf Sätze wie "denk mal darüber nach" und "du hast wohl das Posting nicht gelesen" bin ich irgendwie allergisch :-)
Alexander hat eine Rechnung für den Pessimalfall aufgemacht. Und wenn wir von Consumerplastik reden, gehe ich mal davon aus, das alle schlimmen Dinge, die man so bauen kann, auch gebaut werden[1].
Um die Verwirrung zu vervollständigen, hab ich noch mal ein bisschen experimentiert und gesucht.
"Forensic Data Recovery from Flash Memory"
Da haben sie mal ein paar (ältere) USB-Sticks zerlegt und teilweise rausgefunden, wie deren Wearleveling funktioniert.
"Hard disks are dead. Now what?"
hat eine schöne kurze Erklärung, wie "SmartMedia" funktioniert. Zum Thema auch noch diesen Absatz, der es gut zusammenfasst. # A side-effect of waiting is that the current block would be considered # invalid if the system crashed. That can have interesting consequences # to databases calling fsync() and trusting the storage media to # safeguard the data afterwards. Whether all implementations of such an # optimisations are sync-safe is unknown and hard to test. As always, # manufacturers tend to be secretive and consumers are left to hope for # the best.
Und schließlich noch eine Hausnummer zum Thema Datenbank: sqlite schreibt bei mir für das Einfügen eines Datensatzes in eine einspaltige Tabelle reichlich 5 kByte in 12 Schreibzugriffen. Bei MSSQL würde ich ganz ehrlich deutlich mehr erwarten.
Letztlich wird es darauf hinauslaufen, dass eine Datenbank unter deinen Rahmenbedingungen auf einem kaufbaren USB-Stick mit FAT-Dateisystem keinen Spaß machen wird, obwohl NAND-Flash durchaus in der Lage wäre, das zu stemmen.
Stefan
[1] Ähnliches Thema: Versuch mal gezielt, eine SDHC-Karte zu kaufen, die CMD42 unterstützt. Laut Standard müssen das alle. Aber da der PC diesen Befehl nicht nutzt, ist der gerne falsch oder gar nicht implementiert. Teilweise sogar unterschiedlich in verschiedenen Chargen desselben Typs.
Oh ja. Es gab zum Beispiel auch Consumer USB Sticks mit 2 GB Kapazitaet, bei denen nur das erste GB wirklich mit Flash hinterlegt war. Schreibzugriffe ins zweite GB gingen ins Leere ... dafuer waren die Sticks sehr billig ;-)
Die vorgenannten 120 Byte pro Datensatz sind, so nehme ich an, die Groesse des Datensatzes wie er per INSERT an die DB uebergeben wird. Dafuer duerfte die DB mindestens 4 Schreibzugriffe taetigen: - Transaktion als offen ins Log eintragen - Daten schreiben (die 120 Byte plus allfaelliges Padding) - Metadaten aktualisieren - Transaktion als beendet ins Log eintragen
Davon erfolgen letztlich alle mehr oder weniger synchron (also entweder mit O_SYNC oder fsync (bzw aequivalentes) nach jedem Schreibzugriff).
Real sind es vermutlich noch mehr.
Allerdings.
Man liest sich, Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Wenn sie denn wenigstens ins Leere gegangen wären, die haben munter den unteren GB Bereich überschrieben. Solange < 1GB benutzt wird, gehen die Dinger gut. Man darf eben nur eine 1 GB Partition anlegen. Ich habe aber nicht getestet, was die interne Logik macht, wenn ein Block ersetzt werden müsste und kein Flash mehr da ist...
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.