Hallo liebes Forum,
für ein Datenloggerprojekt steht u.A. die Verwendung von FAT32 als
Dateisystem zur Auswahl. Mir ist klar, dass es nicht "Transaction Safe"
ist und es durchaus Alternativen gibt, die aber ein wenig an Komfort
einbüßen würden. Vor allem das problemlose und direkte Auslesen des
Loggers an jedem PC ist eines der Design-Ziele. Der Logger kann dabei
jederzeit vom Strom getrennt werden. Es ist aus Platzgründen leider
nicht möglich, einen ausreichend großen Puffer zu verbauen, der ein
kontrolliertes Herunterfahren des Systems ermöglichen würde.
Die folgenden Fragen zielen mehr oder weniger auf FatFs von Chan ab,
sind aber (denke ich) allgemein für ein FAT32 übertragbar. Dabei gehe
ich immer davon aus, dass das Speichermedium (SD oder eMMC) einen Sektor
entweder schreibt oder eben nicht und bei einem unterbrochenen
Schreibvorgang kein Datenmüll entsteht.
Nach einigermaßen detailiertem Studium des Dateisystems und der
Implemetierung sehe ich bei den typischen Anwendungsfällen eines Loggers
folgende Probleme, wenn während dessen eine Unterberchung stattfinden
sollte:
- Erstellen einer neuen (leeren) Datei:
- Erstellen eines oder mehrerer Directory-Einträge (LFN)
- evtl. Allokieren eines neuen Clusters, falls das Verzeichnis voll
sein sollte.
-> im Schlimmsten Fall liegt eine leere Datei herum oder es werden
Directory-Einträge oder Cluster verschwendet
- Schreiben in eine Datei:
- Allokieren eines neuen Clusters
- Cluster suchen und Allokieren
-> Im schlimmsten Fall habe ich einen EOC Cluster allokiert, der
in keiner Liste auftaucht und deshalb nicht mehr genutzt werden kann.
- Cluster in Liste eintragen
-> im Schlimmsten fall klappt das nicht und der Cluster ist
verloren
- Schreiben in einen bestehenden Cluster
-> Im schlimmsten Fall fehlen die zuletzt bzw. in letzter Zeit
geschriebenen Daten
- Dateilänge im Directory-Eintrag anpassen
-> Im schlimmsten fall ist die Datei kürzer und die zuletzt
geschriebenen Daten fehlen
Das alles klappt natürlich nur, wenn wie gesagt ein abgebrochener
Schreibversuch nicht in Datenmüll endet sondern entweder die alten oder
die neuen Daten liefert.
Was meint Ihr?
Vielen Dank,
Karl
Karl schrieb: > Es ist aus Platzgründen leider > nicht möglich, einen ausreichend großen Puffer zu verbauen, der ein > kontrolliertes Herunterfahren des Systems ermöglichen würde. Warum nicht? Von allen Anforderungen ist das (kein Puffer) doch diejenige auf die sich am einfachsten verzichten ließe so daß die anderen beiden Forderungen (Fat32, Ausschalten) nunmehr erfüllt werden können. Nur ein paar hundert Millisekunden sollten doch schon reichen um die geänderten Teile der FAT und den Verzeichniseintrag in einen konsistenten Zustand zu versetzen. Ein paar dutzend µF als Energiespeicher und ein bisschen Hühnerfutter um das Trennen der Versorgungsspannunng unverzüglich zu detektieren werden doch wohl noch irgendwo auf die Platine draufpassen?
:
Bearbeitet durch User
>und bei einem unterbrochenen >Schreibvorgang kein Datenmüll entsteht Davon kannst du nicht ausgehen. Wenn beim schreiben von Clustereinträgen in die FAT was schief geht kann das zum Totalverlust der Daten führen.
Karl schrieb: > Das alles klappt natürlich nur, wenn wie gesagt ein abgebrochener > Schreibversuch nicht in Datenmüll endet sondern entweder die alten oder > die neuen Daten liefert. SD Karten kamen hier nach plötzlichem Spannungsverlust manachmal nicht wieder hoch und waren dann kaputt. Richtig lustig wird es übrigens wenn eine neue Datei über alte (gelöschte) Daten geschrieben wird. Dann kann man "neue" von "alten" Sektoren nicht mehr sicher unterscheiden.
Bernd K. schrieb: > Warum nicht? Weil das Ding beim schreiben ca 400 mA braucht. Und selbst die guten SD Karten mindestens 100 Bis 200 ms write latency haben. Da ist mit ein paar uF nicht viel los wenn ich mich nicht verrechnet habe.
Bau zwei SD-Kartenslots ein. Schreib zuerst auf die erste und wenn das abgeschlossen ist auf die zweite. Dann kann man zu jedem beliebigen Zeitpunkt den Stecker ziehen oder auch eine der Karten rausziehen, eine der beiden Karten wird stets gut sein.
:
Bearbeitet durch User
karl schrieb: > Bernd K. schrieb: >> Warum nicht? > > Weil das Ding beim schreiben ca 400 mA braucht. Und selbst die guten SD > Karten mindestens 100 Bis 200 ms write latency haben. Da ist mit ein > paar uF nicht viel los wenn ich mich nicht verrechnet habe. Das ist ganz großer Quark. Du solltest einmal Datenblätter bemühen, deine Bauchmeinung ist belanglos. Z. B. benötigen ATP (128 MByte, industrial grade) max. 50 mA @ 3,3 V beim Schreiben.
Bernd K. schrieb: > Bau zwei SD-Kartenslots ein. > > Schreib zuerst auf die erste und wenn das abgeschlossen ist auf die > zweite. Dann kann man zu jedem beliebigen Zeitpunkt den Stecker ziehen > oder auch eine der Karten rausziehen, eine der beiden Karten wird stets > gut sein. Nette Idee. Problem ist nur woher weis man welche Karte OK ist?
guest schrieb: > Nette Idee. Problem ist nur woher weis man welche Karte OK ist? CRC über den Nutzbereich der Daten, mitsamt Zeitstempel? Dann ist entweder nur ein Datensatz OK, der ist dann gültig. Oder beide sind OK, dann ist der aktuellere gültig.
guest schrieb: > woher weis man welche Karte OK ist? Prüfzahl und Zeit könnten helfen die gesunde Karte zu finden? Sinnvoller wäre jedoch, die Daten an einem anderen Ort nochmals zu sichern, da Diebstahl oder Überspannung beide Karten betreffen könnten!
Nop schrieb: > CRC über den Nutzbereich der Daten, mitsamt Zeitstempel? Und wo willst Du die ablegen? Mit auf der Karte? Und wie sicherst Du diese Daten dann ab? oszi40 schrieb: > Sinnvoller > wäre jedoch, die Daten an einem anderen Ort nochmals zu sichern, da > Diebstahl oder Überspannung beide Karten betreffen könnten! Selbst wenn man Diebstahl oder Überspannung mal außen vor läßt, ein anderer Speicherort ist nicht nur sinnvoll, sondern der einzige Weg das tatsächlich sicher zu bekommen, vorrausgesetzt dieser Speicherort garantiert einem abgeschlossene Schreibvorgänge. Womit man dann wieder bei Pufferkondensatoren oder ähnlichem ist. Oder halt bei den von karl erwähnten eMMC, die das garantieren.
guest schrieb: > Und wo willst Du die ablegen? Mit auf der Karte? Ja, sicher. Im Nutzdatenbereich der Dateien. > Und wie sicherst Du diese Daten dann ab? Wen das Dateisystem lesbar ist und die Nutzdaten mitsamt der in ihnen enthaltenen CRC gültig, dann ist die Karte halt OK. Selbst den Zeitstempel kann man in den Nutzdaten unterbringen.
Nop schrieb: > Wen das Dateisystem lesbar ist und die Nutzdaten mitsamt der in ihnen > enthaltenen CRC gültig, dann ist die Karte halt OK. Das kannst Du nach einem power loss während des Schreibens vergesssen. Dann kann es passieren, daß Du die Daten samt CRC ja nach Mondstand mal korrekt lesen kannst oder eben auch nicht und nach einiger Zeit sind sie dann meist kommplett Schrott. Wenn Du dann nach einem korrekten Leseversuch anfängst die zweite Karte zu beschreiben und wieder ein power loss eintritt, sind beide Karten hinüber.
guest schrieb: > Das kannst Du nach einem power loss während des Schreibens vergesssen. > Dann kann es passieren, daß Du die Daten samt CRC ja nach Mondstand mal > korrekt lesen kannst oder eben auch nicht und nach einiger Zeit sind sie > dann meist kommplett Schrott. Dann sind die Karten halt grundsätzlich ungeeignet für so eine Anwendung, wenn der Schreibvorgang "halb" ablaufen kann und dann mal das Richtige rauskommt und mal nicht (bei power loss).
Buber schrieb: > Das ist ganz großer Quark. Du solltest einmal Datenblätter bemühen, > deine Bauchmeinung ist belanglos. Z. B. benötigen ATP (128 MByte, > industrial grade) max. 50 mA @ 3,3 V beim Schreiben. Danke für das Kompliment. Datenblätter und Spezifikationen habe ich gelesen. Es geht hier nicht um 128 MiB sondern mindestens um 8 Gib, besser 64 GiB. Kennst Du einen konkreten, vergleichbar günstigen Speicher in dieser Größenordnung, der mir das Wear-Leveling etc abnimmt? Beim schreiben brauchen die halt ihren Strom und es dauert auch immer mal wieder sehr lange. Deswegen schreibe ich von Write Latency. Dass das wegschreiben eines Sektors meistens schneller geht ist schon klar, aber meistens ist halt nicht immer.
Bernd K. schrieb: > Bau zwei SD-Kartenslots ein. Auch dafür ist leider kein Platz. Die Idee ist aber insofern interessant, dass ich einfach zwei Partitionen anlegen könnte und die nacheinander mit dem selben Inhalt beschreiben könnte. Kostet dann "nur" Speicherplatz und Durchsatz beim Schreiben.
Vielen Dank für die Beiträge bisher. Ich möchte die Diskussion aber nochmal auf die eigentliche Fragestellung lenken: Sind meine Überlegungen zum Verhalten des FAT Dateisystems (in konkreter Implementierung von Chan) wie im ersten Post beschrieben korrekt oder übersehe ich was wichtiges?
Falls es jemanden interessiert: Habe ein paar Tests bzgl. verschiedener SD-Karten bei Spannungsunterbrechung im Schreibvorgang gemacht. Das Board kann die Spannungsversorgung der SD-Karten per Pin vom µC schalten, so dass ich mir einfach den Spaß gemacht habe und einen Sektor zu beschreiben und währenddessen die SD-Karte aus dem Leben zu reißen. Der Abstand zwischen Schreibvorgang und Spannungsunterbrechung lässt sich variieren (hier z.B. in Schritten von 100 µs). Zum Testen hatte ich eine SanDisk 8 GB SDHC Class 4 und eine Transcend 8 GB SDHC Class 6. Die Ergebnisse sind beinahe schon wie erwartet: SanDisk: Entweder bleiben die zuletzt gültigen Daten erhalten oder die neuen werden korrekt geschrieben. Dabei braucht die Karte zwischen 60 und 80 ms um den Sektor wegzuspeichern. Der Schreibvorgang am Bus ist dank SDIO bei 24 MHz für einen Sektor wesentlich schneller abgeschlossen. Transcend: Die Karte schreibt scheinbar "sofort" weg, bei einer Spannungsunterbrechung liefert sie dafür aber auch Datenmüll. Zufällig noch ein FAT32 Experte hier?
Ein Fat32 Experte kann dazu nichts weiter beitragen. Da musst du schon die Herstellers der Karten fragen. Erfahrungsgemäß beantworten die solche Detailfragen nicht.
Nur mal so ins Unreine gedacht: Vielleicht kannst Du einen kleinen Teil der Karte dazu abzweigen, updates auf die FA-Table zu protokollieren. Dann könntest Du nach einem Start dieses Protokoll rückwärts durchgehen und gucken, ob die da beschriebenen Änderungen so gemacht wurden. Wenn nicht, dann nimmst Du die beschriebene Änderung vor. Das setzt dann natürlich voraus, dass Du jede Operations weitgehend so vorbereiten kannst, dass sie zum Abschluss nur noch eine (relativ kleine) Änderung an der FAT benötigt.
Ich meinte ja auch zu den Überlegungen im ersten Post. eMMC unterstützt einen "reliable write" Modus, der das garantiert. Von SanDisk und Swissbit gibt es "industrial" SD Karten, die auch dieses Verhalten garantieren (und anscheinend machen es auch die SanDisk consumer Karten). Damit kann die Annahme für die obigen Überlegungen, dass ein Sektor entweder den alten oder den neuen Wert annimmt auf jeden Fall dargestellt werden.
Torsten R. schrieb: > Nur mal so ins Unreine gedacht: Vielleicht kannst Du einen kleinen Teil > der Karte dazu abzweigen, updates auf die FA-Table zu protokollieren. Du hast "für solche Anforderungen nimmt man vorzugsweise ein Journaling Filesystem" ein bißchen umständlich geschrieben. ;-) Dummerweise kann das ein normaler Windows-PC dann aber nicht mehr lesen.
Torsten R. schrieb: > Nur mal so ins Unreine gedacht: Vielleicht kannst Du einen kleinen Teil > der Karte dazu abzweigen, updates auf die FA-Table zu protokollieren. > Dann könntest Du nach einem Start dieses Protokoll rückwärts durchgehen > und gucken, ob die da beschriebenen Änderungen so gemacht wurden. Wenn > nicht, dann nimmst Du die beschriebene Änderung vor. > > Das setzt dann natürlich voraus, dass Du jede Operations weitgehend so > vorbereiten kannst, dass sie zum Abschluss nur noch eine (relativ > kleine) Änderung an der FAT benötigt. Ja, das funktioniert. RFAT [https://github.com/GrumpyOldPizza/RFAT] implementiert das so ähnlich und ist "Transaction Safe". Leider hat RFAT einige andere Schwächen und ich wollte mir den Aufwand für die Portierung gerne sparen (zumal FatFs strukturell nicht sooo gut dafür geeignet zu sein scheint). Mit ggf. verlorenen einzelnen Clustern könnte ich leben.
Du könntest doch die Daten in einem eigenen prorietären Format ganz ohne Dateisystem auf eine unformatierte nackte Karte schreiben. Dazu lieferst Du noch eine kleine Windows .exe aus mit hybscher GUI mit der man das lesen, schön filtern, graphisch darstellen und notfalls auch als .csv exportieren kann. Mit ner nackten Logdatei allein (vor allem wenn sie etliche GB groß werden kann) kann man ja auf Windows eh nix sinnvolles anfangen mangels geeigneter Tools zum Auswerten oder Aufbereiten, also muss man so oder so zusätzliche Software installieren.
:
Bearbeitet durch User
Karl schrieb: > Falls es jemanden interessiert... > > Transcend: Die Karte schreibt scheinbar "sofort" weg, bei einer > Spannungsunterbrechung liefert sie dafür aber auch Datenmüll. Was heißt das? Der zuletzt geschriebene Sektor enthält weder die alten noch die neuen Daten? Die Daten in anderen (nicht geschriebenen) Sektoren haben sich geändert? Schreibst du (atomare) Sektoren und wartest auf auf ein Feedback oder schreibst du ohne Feedback weiter?
Nop schrieb: > Du hast "für solche Anforderungen nimmt man vorzugsweise ein Journaling > Filesystem" ein bißchen umständlich geschrieben. ;-) Ja, hat er wohl. > Dummerweise kann das ein normaler Windows-PC dann aber nicht mehr lesen. NTFS ist ein journaling FS und Windows kann das (im Prinzip) ganz hervorragend lesen und schreiben. Blöderweise wurde Windows aber von Microsoft künstlich kastriert, so dass mindestens ab Windows7 (wahrscheinlich ab Vista) Windows doch nicht mehr in der Lage ist, mit NTFS auf Wechselmedien umzugehen. Überhaupt: es ist nicht einmal mehr in der Lage, mit mehreren Partitionen auf Wechselmedien umzugehen, früher (bis XP) hat es immer noch wenigstens die erste gesehen und korrekt nutzen können, auch mit NTFS. Tja, der Fortschritt der Technik á la Microsoft... Aber ganz so schlimm, wie es scheint, ist die Nicht-Unterstützung von NTFS auf Flash-Medien auch wieder nicht. Das Blöde ist nämlich: Die Medien selber kommen eigentlich mit keinem FS gut klar, was auch nur einen Hauch von dem abweicht, was ab Werk darauf ist, weil die wear-leveling-Strategie ihrer Controller eben genau darauf abgestimmt ist. Davon abweichende Filesysteme führen deshalb regelmäßig zu grottigen Schreibraten und in der Endkonsequenz zum vorzeitigen Ableben des Mediums. Es ist also sowieso dringend zu empfehlen, bei genau dem FS mit genau der Geometrie zu bleiben, was ab Werk darauf ist.
Bernd K. schrieb: > Du könntest doch die Daten in einem eigenen prorietären Format ganz ohne > Dateisystem auf eine unformatierte nackte Karte schreiben. Das Datenformat ist vorgegeben (MDF4). Dass die Möglichkeit ein anderes Dateisystem als FAT32 einzusetzen einiges einfacher macht ist klar, aber es soll explizit ohne zusätzliche Software funktionieren. Analysesoftware etc. gibt es ausreichen (und teuer :-( ).
Mikro 7. schrieb: > Was heißt das? Der zuletzt geschriebene Sektor enthält weder die alten > noch die neuen Daten? Die Daten in anderen (nicht geschriebenen) > Sektoren haben sich geändert? Schreibst du (atomare) Sektoren und > wartest auf auf ein Feedback oder schreibst du ohne Feedback weiter? Ich schreibe einen Sektor per DMA und warte dann eine gewisse Zeit bis ich die Karte aus dem Leben reiße. Dann wird neu initialisiert und der Sektor ausgelesen und mit dem zuvor geschriebenen Inhalt verglichen. Geprüft habe ich auf die Schnelle nur genau diesen Sektor, werde aber nächste Woche noch auf die ganze Allocation Unit schauen.
Karl schrieb: > Nach einigermaßen detailiertem Studium des Dateisystems und der > Implemetierung sehe ich bei den typischen Anwendungsfällen eines Loggers > folgende Probleme, wenn während dessen eine Unterberchung stattfinden > sollte: ... Bin es auch gerade mal durchgegangen. Hast wohl recht. Konsistenz sollte immer bestehen. (A) Anhängen n Bytes an eine Datei: Prüfen ob die bereits zugewiesenen Cluster zusätzlich n Bytes abdecken. Falls nicht, freien Cluster suchen, als Ende markieren, vorherigen Cluster auf neuen Cluster verweisen lassen. (Immer beide FATs updaten.) -- Bei leerer Datei ohne Start-Cluster - Start-Cluster setzten. Prüfung wiederholen (Schleife). -- (Läßt sich natürlich optimieren für n > Cluster.) Falls ja, Daten schreiben. Länge im Directory-Eintrag updaten. (B) Neue (leere) Datei Anlegen: Falls ein freier Eintrag vorhanden ist, diesen nutzen. Falls nicht wie in (A) verfahren (die Nutzdaten sind der neue leere Directory-Eintrag). Bei einem Absturz kann es dann -- einen nicht genutzten Cluster geben (oder Cluster-Kette bei Optimierung für n>Cluster). -- eine Datei kann auf mehr Cluster verweisen, als sie für den Inhalt benötigt. Ein Konsistenzproblem sehe ich aber nicht. Der Dateinhalt sollte entweder immer der alte, oder der neue sein, aber nichts dazwischen. > Dabei gehe > ich immer davon aus, dass das Speichermedium (SD oder eMMC) einen Sektor > entweder schreibt oder eben nicht und bei einem unterbrochenen > Schreibvorgang kein Datenmüll entsteht. Wenn das nicht erfüllt ist, wird es etwas schwieriger.
Mikro 7. schrieb: > Bin es auch gerade mal durchgegangen. Vielen Dank. > Ein Konsistenzproblem sehe ich aber nicht. Der Dateinhalt sollte > entweder immer der alte, oder der neue sein, aber nichts dazwischen. > >> Dabei gehe >> ich immer davon aus, dass das Speichermedium (SD oder eMMC) einen Sektor >> entweder schreibt oder eben nicht und bei einem unterbrochenen >> Schreibvorgang kein Datenmüll entsteht. > > Wenn das nicht erfüllt ist, wird es etwas schwieriger. Da bin ich ja noch den Test schuldig, habe aber erst heute Nachmittag wieder Zugriff auf die Hardware. Wenn man aber vom worst case ausgehen darf, nämlich dass bei einer billigen Karte die ganze Allocation Unit von 4 bis 16 MiB hinüber ist, wird es langsam für viele Dateisysteme schwierig, oder? Man müsste dann sicherstellen, dass relevante Dateisysteminformationen immer auch in unterschiedlichen Allocation Units liegen, weil man sonst mehr verlieren würde als das woran man gerade arbeitet. Weiter gedacht heißt das für mich, dass der schlechte Ruf von FAT Dateisystemen eher der schlechten Qualität vieler Wechselmedien (USB, SD) bei unvollständigen Schreibvorgängen entsprungen ist.
Karl schrieb: > Wenn man aber vom worst case ausgehen darf, nämlich dass bei einer > billigen Karte die ganze Allocation Unit von 4 bis 16 MiB hinüber ist, > wird es langsam für viele Dateisysteme schwierig, oder? Der worst case ist, dass ein unplanmäßiger Stromausfall zufällige Sektoren irgendwo kaputtmacht, weil das Wear Levelling die Sektoren so verteilt hat. Jedes Dateisystem braucht bestimmte Garantien, die das zugrundeliegende Speichermedium einhalten muss, um ordentlich zu funktionieren. Wenn deine SD-Karte das nicht garantiert, dann kann auch nichts, was darauf aufbaut, irgendwas garantieren. > Weiter gedacht heißt das für mich, dass der schlechte Ruf von FAT > Dateisystemen eher der schlechten Qualität vieler Wechselmedien (USB, > SD) bei unvollständigen Schreibvorgängen entsprungen ist. Nein, FAT war auch schon vorher scheiße: Absturz, Neustart, Scandisk, Dateisystem kaputt. Sowas passiert mit Journalling nicht. Aber wer SD-Karten mit FAT spezifiziert und gezielt daraufhin entwickelt, unterstützt eben kein Journalling, egal auf welche Art und Weise, weil FAT es eben auch nicht kann. Samsung hat F2FS nicht ohne Grund entwickelt.
Hallo zusammen, noch eine Idee. :-) Journaling File System bzw. dessen Simulation aufgrund der Beschränkung auf FAT wurde ja schon genannt. Das schützt zwar erstmal nicht vor korrupten Daten, anhand des Journals kann das aber nachvollzogen werden und somit ein konsistenter Zustand hergestellt werden. Besser wäre aber wohl ein File System mit Copy on Write. Hier bleiben die originalen Daten zunächst unberührt, und werden bei der Änderung nochmal geschrieben. Erst wenn die Änderung erfolgreich abgeschlossen wurde, wird im Dateisystem der Pointer auf den neuen Eintrag umgeschrieben. Nun, auch das gibt es bei FAT nicht. Möglich wäre aber, dies zu simulieren, indem die Datei komplett neu geschrieben wird (also also bisherigen Daten und die neuen Daten), und erst nach erfolgreichem Abschluß wird die ursprüngliche Datei gelöscht. Man müßte dabei allerdings wechselnde Dateinamen verwenden, oder mit verschiedenen Ordnern arbeiten. Leider kann das aber nicht hinnehmbare Performanceprobleme verursachen, wenn die Datenmenge zu groß wird... ...war mich beim Nachdenken darüber auf eine weitere Idee bringt: Was spricht denn dagegen, für jeden Datensatz eine eigene Datei zu erzeugen? Das läßt sich immer weiterverarbeiten. Und alle schon existenten Daten bleiben bei einem Crash unberührt, da deren Sektoren nicht mehr beschrieben werden. Gruß Markus Zehren
Je nachdem, wie verkorkst die Firmware der SD-Karte ist, funktioniert keine deiner Möglichkeiten. Es gibt SD-Karten, die das Wear-Levelling über den gesamten Flash machen und bei einem Stromausfall einen Erase-Block verlieren. Dann sind zufällige Sektoren, die du eventuell seit Tagen nicht mehr angefasst hast, plötzlich leer. Auf so einer Karte ist jede Liebesmüh verloren.
https://www.embeddedarm.com/blog/preventing-filesystem-corruption-in-embedded-linux/ Ich hätte nicht gedacht, dass das ein so ernstes Problem mit dem Stromausfall beim Wear Levelling ist. :-( Warum wird nicht ein Spare genommen und geschrieben, bevor der Block gelöscht wird?
S. R. schrieb: > Der worst case ist, dass ein unplanmäßiger Stromausfall zufällige > Sektoren irgendwo kaputtmacht, weil das Wear Levelling die Sektoren so > verteilt hat. Hand auf's Herz: Hast Du das schon erlebt? > Nein, FAT war auch schon vorher scheiße: Absturz, Neustart, Scandisk, > Dateisystem kaputt. Sowas passiert mit Journalling nicht. Erzähl doch mal bitte, wo bei einer SD Karte oder eMMC, die jeweils "reliable write" bieten ein FAT32 Dateisystem einfach so kaputt geht, abgesehen von evtl. verlorenen Cluster(ketten). > Aber wer SD-Karten mit FAT spezifiziert und gezielt daraufhin > entwickelt, unterstützt eben kein Journalling, egal auf welche Art und > Weise, weil FAT es eben auch nicht kann. Samsung hat F2FS nicht ohne > Grund entwickelt. eMMC schreiben kein Dateisystem vor. Journaling Dateisysteme sind hier aber nicht das Thema.
Markus Zehren schrieb: > Hallo zusammen, > > noch eine Idee. :-) Journaling File System bzw. dessen Simulation > aufgrund der Beschränkung auf FAT wurde ja schon genannt. Das schützt > zwar erstmal nicht vor korrupten Daten, anhand des Journals kann das > aber nachvollzogen werden und somit ein konsistenter Zustand hergestellt > werden. > Inwiefern wird FAT32 inkonsistent, wenn das Speichermedium reliable write bietet? > Besser wäre aber wohl ein File System mit Copy on Write. Hier bleiben > die originalen Daten zunächst unberührt, und werden bei der Änderung > nochmal geschrieben. Erst wenn die Änderung erfolgreich abgeschlossen > wurde, wird im Dateisystem der Pointer auf den neuen Eintrag > umgeschrieben. Nun, auch das gibt es bei FAT nicht. Möglich wäre aber, > dies zu simulieren, indem die Datei komplett neu geschrieben wird (also > also bisherigen Daten und die neuen Daten), und erst nach erfolgreichem > Abschluß wird die ursprüngliche Datei gelöscht. Man müßte dabei > allerdings wechselnde Dateinamen verwenden, oder mit verschiedenen > Ordnern arbeiten. Leider kann das aber nicht hinnehmbare > Performanceprobleme verursachen, wenn die Datenmenge zu groß wird... Die Logdateien können mehrere GiB haben, so dass ich ein vollständiges Neuschreiben aus Performancesicht ausschließen kann. Auch der Aufwand für (momentan) 4 kiB neue Daten pro Schreibvorgang wäre IMO nicht gut, auch im Hinblick auf die total bytes written. > ...war mich beim Nachdenken darüber auf eine weitere Idee bringt: Was > spricht denn dagegen, für jeden Datensatz eine eigene Datei zu erzeugen? > Das läßt sich immer weiterverarbeiten. Und alle schon existenten Daten > bleiben bei einem Crash unberührt, da deren Sektoren nicht mehr > beschrieben werden. Festgelegtes Datenformat: MDF4
Karl schrieb: > S. R. schrieb: > >> Der worst case ist, dass ein unplanmäßiger Stromausfall zufällige >> Sektoren irgendwo kaputtmacht, weil das Wear Levelling die Sektoren so >> verteilt hat. > > Hand auf's Herz: Hast Du das schon erlebt? fyi: Könnte für dich interessant sein: https://www.mikrocontroller.net/topic/405315#new
Wie versprochen noch die Ergebnisse bzgl. korrupter Daten in nicht
beschriebenen Sektoren:
SanDisk 8 GB: Keinerlei korrupte Sektoren feststellbar Alle Sektoren im
Bereich +- 8 MiB um den geschriebenen Sektor enthalten
richtige Daten. Der zum Zeitpunkt der
Spannungsunterbrechung
gerade geschriebene Sektor enthält entweder die alten
oder
die neuen Daten.
Transcend 8GB: Es werden auch Sektoren in Mitleidenschaft gezogen,
nicht
angefasst wurden. Sie enthalten dann nicht zuordenbaren
Datenmüll. Die Karte ist damit eigentlich für fast
jegliche
Anwendung unbrauchbar.
Ein besonderer Dank geht an mikro77, der als einziger die
Fragestellung im Ausgangspost beantworten konnte und wollte. Garnicht so
schlecht für dieses Forum ;-)
Karl schrieb: > Inwiefern wird FAT32 inkonsistent, wenn das Speichermedium reliable > write bietet? Das hängt davon ab, wann Fehlerfall (z.B. der genannte Stromausfall) auftritt. Es kann durchaus passieren, daß mehrere Blöcke erfolgreich geschrieben werden konnten, dann aufgrund des Stromausfalls das Beriebssystem/die Firmware nicht mehr dazu kommt, die restlichen Blöcke zu schreiben. Es nutzt dann nichts, wenn die schon geschriebenen Blöcke korrekt sind. Das Dateisystem ist dann korrupt. Wie du weiter unten schreibst, ist die Dateigröße zu groß, als daß ein einzelner Block reichen würde. > Die Logdateien können mehrere GiB haben, so dass ich ein vollständiges > Neuschreiben aus Performancesicht ausschließen kann. Auch der Aufwand > für (momentan) 4 kiB neue Daten pro Schreibvorgang wäre IMO nicht gut, > auch im Hinblick auf die total bytes written. Aus meiner Sicht ist also die Zuverlässigkeit/Datensicherheit der Tod, denn du sterben willst. OK. >> Was spricht denn dagegen, für jeden Datensatz eine eigene Datei >> zu erzeugen? > > Festgelegtes Datenformat: MDF4 Davon, daß es nur genau eine MDF4-Datei sein darf, war bisher keine Rede. Gruß Markus Zehren
Karl schrieb: > Transcend 8GB: Es werden auch Sektoren in Mitleidenschaft gezogen, > nicht > angefasst wurden. Sie enthalten dann nicht zuordenbaren > Datenmüll. Die Karte ist damit eigentlich für fast Hast Du beide Karten vor dem Test geTRIMt (ERASE) um das Wear-Leveling nicht in die Verlegenheit zu bringen keine unbenutzten Blöcke mehr im Pool zu haben und um gleiche Ausgangsbedingungen zu schaffen?
:
Bearbeitet durch User
Markus Zehren schrieb: > Karl schrieb: > >> Inwiefern wird FAT32 inkonsistent, wenn das Speichermedium reliable >> write bietet? > > Das hängt davon ab [...] > Bitte etwas konkreter. Dateisystemänderungen (FAT, Directory-Eintrag) finden immer nur in einem Sektor statt. Wie soll das Dateisystem bei "reliable write" kaputt gehen können? Dass die neuen Daten in einer Datendatei evtl. fehlen ist klar. Auch, dass evtl. (einzelne) Cluster verloren gehen können. Das würde ich aber akzeptieren und nicht als defektes Dateisystem bezeichnen. > > Aus meiner Sicht ist also die Zuverlässigkeit/Datensicherheit der Tod, > denn du sterben willst. OK. > Warum? Mit welchem Mechanismus könnte ich bereits bestehende Daten verlieren? >>> Was spricht denn dagegen, für jeden Datensatz eine eigene Datei >>> zu erzeugen? >> >> Festgelegtes Datenformat: MDF4 > > Davon, daß es nur genau eine MDF4-Datei sein darf, war bisher keine > Rede. Ok, es dürfen schon mehrere Dateien sein. Manchmal Notgedrungen, wenn die Messung > 4 GiB werden sollte. Ich kann aber keine Messung mit nur 512 Bytes machen, weil alleine der Rumpf der Messdatei schon in der Größenordnung vonn 100 kiB liegt. Wahrscheinlich habe ich Dich aber nicht richtig verstanden. Würdest Du mir nochmal erklären, inwiefern das Aufteilen einer Messung in mehrere Messungen die Datensicherheit erhöht?
Bernd K. schrieb: > Hast Du beide Karten vor dem Test geTRIMt (ERASE) um das Wear-Leveling > nicht in die Verlegenheit zu bringen keine unbenutzten Blöcke mehr im > Pool zu haben und um gleiche Ausgangsbedingungen zu schaffen? Nein, das halte ich aber auch nicht für sinnvoll. Wenn dann müsste man die Karte randvoll schreiben, dann Dateien ohne ERASE löschen und dann den Test wiederholen, oder? Also wenn es mir auf den Worst-Case ankommt. Ich kann ja nicht davon ausgehen, dass die Karte imme vollständig gelöscht wurde bevor sie wieder beschrieben wird. Der µC könnte zwar die Sektoren löschen, aber idR werden die Dateien am PC gelöscht. Das Speichermedium ist per USB MSC/BOT angebunden, so dass der µC erstmal nichts von dem weiß, was der PC macht. Ein parsen der FAT während der PC darin herumwerkt möchte ich nach aktuellem Kenntnisstand nicht machen.
Mikro 7. schrieb: > fyi: Könnte für dich interessant sein: > Beitrag "Raspberry 3 : Was hält länger? SD Karte oder USB Stick?" Danke. In der Tat interessant, dass es auch völlig unberührte Daten betrifft, bei den billigen Karten. Gut, dass es Hersteller gibt, die eine vernünfitige Firmware in ihre Flash-Produkte einbauen. Ich darf aus einer Antwort-Mail von Greenliant zitieren: "Yes our flash file system is inherently power failsafe".
c-hater schrieb: > Das Blöde ist nämlich: Die > Medien selber kommen eigentlich mit keinem FS gut klar, was auch nur > einen Hauch von dem abweicht, was ab Werk darauf ist, weil die > wear-leveling-Strategie ihrer Controller eben genau darauf abgestimmt > ist. Davon abweichende Filesysteme führen deshalb regelmäßig zu > grottigen Schreibraten und in der Endkonsequenz zum vorzeitigen Ableben > des Mediums. Das habe ich schon öfter gelesen, mag es aber nicht so recht glauben. Wenn's so wäre, müsste ja ein Filesystemimage mit einem anderen FS-Typ und fester Größe, das als Datei auf FAT32 läge, irgendwie besser (oder länger) funktionieren (ist ja schließlich FAT32). Wie das zugehen sollte, ist mir allerdings unklar. Nur weil FAT32 bestimmte Zugriffsmuster beim Schreiben und Lesen der FAT hat, kann man ja schließlich nicht auf die Zugriffsmuster von Applikationen auf ihre Dateien schließen. Oder darf man auf SD-Karten nur Dateien anlegen und wieder löschen?
:
Bearbeitet durch User
Markus F. schrieb: > Das habe ich schon öfter gelesen, mag es aber nicht so recht glauben. Stimme Dir im Prinzip zu. Wenn man sich ansieht, was der "SDformatter" so an Dateisystem anlegt und was die Spec vorschreibt, wird schnell klar wie es dazu kommen konnte: - Spec stammt aus einer Zeit, als das Wear-Leveling evtl. noch nicht so ausgereift war und zusätzliche Reserve-Kapazität sehr viel teurer war als heute. Da machte es evtl. Sinn für einen sehr begrenzten Speicherbereich (FAT) entsprechende Vorkehrungen zu treffen. - Die Festlegung auf ein bestimmtes Dateisystem mit ganz bestimmtem Aufbau ist für die Definition und Einhaltung der Speed Class Kennzeichnung schon wichtig. - Ablage häufig benutzter Strukturen an AU Grenzen ist absolut sinnvoll. Ich wage zu behaupten, dass sich die FTL von guten SD, eMMC und USB Sticks sehr ähnlich sind. Für zwei der drei genannten gibt es kein vorgeschriebenes Dateisystem.
Karl schrieb: > Dateisystemänderungen (FAT, Directory-Eintrag) finden immer nur in einem > Sektor statt. Wie soll das Dateisystem bei "reliable write" kaputt gehen > können? Du hast nie Windows 9x benutzt, oder? Festplatten haben "reliable write" (nach deiner Definition) und das Dateisystem ist dennoch oft nach nem Absturz kaputtgegangen. Scandisk kam nicht grundlos automatisch. Änderungen können auch über Sektorgrenzen hinweg nötig werden, wenn du z.B. eine Clusterkette verlängerst. Zerreißt es dir eine Clusterkette, hast du u.U. zwei Dateien, die sich einen Dateinamen und die ersten Cluster teilen, aber dann auseinanderlaufen. Sowas erkennst du ohne Scandisk nicht. > Dass die neuen Daten in einer Datendatei evtl. fehlen ist klar. > Auch, dass evtl. (einzelne) Cluster verloren gehen können. Das würde ich > aber akzeptieren und nicht als defektes Dateisystem bezeichnen. Du verpeilst den Unterschied zwischen "die Daten sind kaputt" und "das Dateisystem ist inkonsistent". FAT ist gegen letzteres nicht gefeit. >> Aus meiner Sicht ist also die Zuverlässigkeit/Datensicherheit der Tod, >> denn du sterben willst. OK. >> > Warum? Mit welchem Mechanismus könnte ich bereits bestehende Daten > verlieren? Erstens: Die SD-Karte zerkloppt dir irgendwelche Sektoren, wenn du den Stecker ziehst. Beliebige Korruption deiner Daten, irgendwo. Zweitens: Die SD-Karte zerkloppt dir naheliegende Sektoren, wenn du den Stecker ziehst. Betrifft das ein Inhaltsverzeichnis, ist der betreffende Ordner futsch. Drittens: Du bist gerade dabei, die Datenstrukturen des Dateisystems zu ändern, da reißt's dir den Strom weg. Du hast zwei unterschiedliche Kopien der FAT und keine Ahnung, welche davon stimmt. Soll ich weitermachen? Markus F. schrieb: > c-hater schrieb: >> Das Blöde ist nämlich: Die Medien selber kommen eigentlich mit keinem >> FS gut klar, was auch nur einen Hauch von dem abweicht, was ab Werk >> darauf ist, weil die wear-leveling-Strategie ihrer Controller eben >> genau darauf abgestimmt ist. > > Das habe ich schon öfter gelesen, mag es aber nicht so recht glauben. Glauben kannst du in der Kirche, das ist so. Teilweise gibt es sogar unterschiedliche Geometrien für verschiedene Bereiche des Flashs, zumindest aber unterschiedliche Algorithmen. > Wie das zugehen sollte, ist mir allerdings unklar. Nur weil FAT32 > bestimmte Zugriffsmuster beim Schreiben und Lesen der FAT hat, kann man > ja schließlich nicht auf die Zugriffsmuster von Applikationen auf ihre > Dateien schließen. Das Zugriffsmuster auf die Metadaten (nicht nur die FAT) ist bekannt, darauf kann man gnadenlos optimieren. Gelegentlich performt eine Karte deswegen unter Linux auch schlicht scheiße, weil sie gezielt auf den Windows-Treiber hin optimiert wurde. Außerdem werden SD-Karten hauptsächlich für zwei Märkte entworfen: Kameras und Mediaplayer. Im einen Fall wird fast ausschließlich linear in eine einzelne Datei geschrieben, im anderen Fall wird hauptsächlich linear aus einer einzelnen Datei gelesen. In beiden Fällen ist Datensicherheit bei Stromausfall kein Thema (die Kamera schaltet vorher schon ab). Schreibe mal zwei Dateien gleichzeitig und beobachte, wie der Durchsatz bei manchen Karten um >80% einbricht. Oder lies drei Dateien gleichzeitig und freue dich über konstante 60 KB/s auf einer Class 10-Karte. Das passiert, wenn der Controller nur zwei Flashblöcke gleichzeitig "offen" halten kann (einen für die FAT, einen für die Daten). Karl schrieb: > Ich wage zu behaupten, dass sich die FTL von guten SD, eMMC und USB > Sticks sehr ähnlich sind. Für zwei der drei genannten gibt es kein > vorgeschriebenes Dateisystem. Ja. FAT wird auf SD, eMMC und USB-Sticks unter 32 GB durchgängig benutzt. Du kannst auf allen dreien auch etwas anderes einsetzen und du wirst bei allen dreien auf Vertreter stoßen, die danach nichts mehr taugen.
Ich habe mich vor einiger Zeit mal zu Samsungs F2FS informiert und dort Informationen (u.a. von Samsung) gefunden, wo solches Verhalten beschrieben wird. Schreibe einfach mal gleichzeitig und linear auf N unabhängige Blöcke im rohen Flash (ohne Dateisystem), variiere N zwischen 1 und 16, und miss den Datendurchsatz. Bei einigen Medien wird der Durchsatz für N>2 massiv einbrechen. Bei einigen Medien wird der Durchsatz unterschiedlich sein, je nachdem ob du den vorderen Teil des Flashes benutzt oder nicht. "Eine Datei schreiben" auf FAT arbeitet immer nur auf zwei Flash-Blöcken gleichzeitig (FAT und Datenblöcke). Andere Dateisysteme verteilen ihre Datenstrukturen und sind auf billigen Medien dementsprechend nicht zu gebrauchen. Aber du glaubst mir ja sowieso nicht.
FKarl schrieb: > Vielen Dank für die Beiträge bisher. Ich möchte die Diskussion aber > nochmal auf die eigentliche Fragestellung lenken: Deine eigentliche Fragestellung lautete "Was meint ihr?" Gerne beantworte ich Deine Frage. Ich meine, dass der Himmel heute ziemlich grau ist. :) Eine etwas spezifischere Fragestellung hätte sicherlich auch in "diesem Forum", wie Du es ja ausdrückst, zu einer spezifischen Antwort geführt. > Sind meine Überlegungen zum Verhalten des FAT Dateisystems (in konkreter > Implementierung von Chan) wie im ersten Post beschrieben korrekt oder > übersehe ich was wichtiges? Die Überlegungen sind zwar korrekt, aber Du übersiehst trotzdem etwas wichtiges. Deine Sorge gilt ja überwiegend der Platzverschwendung. Bei den von Dir genannten Medien- und Dateigrößen ist überflüssiger Speicherplatz für Inhaltsverzeichnissektoren oder ein als nicht leer gekennzeichneter Cluster, der zu keiner Datei gehört, irrelevant, da er außer durch Speicherplatzminderung den Nutzer in keiner Form beeinträchtigt. Entscheidend sind Beschädigungen der Metastrukturen. Ist also irgendwann irgendein Verzeichnis oder die FAT nicht mehr lesbar, hast Du den (Datei-)Salat. ES ist fraglich, wieweit die FAT-Kopie Dir weiterhelfen kann. Bei dem folgenden Benutzer gibt es zwar keine kaputte FAT, aber kaputte Metastrukturen: Beitrag "Datenrettung mit ddrescue" Trifft es irgendeinen beliebigen Sektor und damit Cluster, ist bei Deinen langen Dateilängen zu 99% nur eine Datei kaputt. Das führt zu der Fragestellung, wie denn Deine Speicherkarte so genutzt wird. Bei meiner digitalen Fotokamera, bzw Filmkamera wird auf dem Datenträger keine Datei durch mich gelöscht. Der wird voll- oder teilbeschrieben, der Inhalt auf eine Festplatte kopiert und der Quelldatenträger gelöscht und/oder formatiert. Bei mir liegen die Daten damit immer linear und fragmentierungsfrei auf dem Quelldatenträger und sind daher sehr recoveryfreudig auch im Fall von Metadatenverlust. Vielleicht trifft das ja auf Dich auch zu.
S. R. schrieb: > Aber du glaubst mir ja sowieso nicht. Genau. Weil: zum Glauben geht man ja in die Kirche.
> Bei mir liegen die Daten damit immer linear und > fragmentierungsfrei auf dem Quelldatenträger und sind daher > sehr recoveryfreudig auch im Fall von Metadatenverlust. Ich hatte mal eine Digitalkamera von Olympus, da stand sogar in der Bedienungsanleitung drin, es sei sicherer, zwischendurch keine einzelnen Fotos zu löschen.
Die einzige Lösung wird wohl sein, das System so lange zu puffern, bis die Logdaten weggeschrieben wurden. Dazu kann man serielles RAM benutzen. Die Steine gibt es auch mit Backup-Funktion, so dass man einen Goldcap oder eine Batterie anschließen kann. Dort hinein kommen die Log-Daten und der gerade angefasste FAT-Sektor. Ist der Log-Datensektor voll, wird dieser auf die Karte geschrieben. Fällt der Strom aus, wird zusätzlich auch der FAT-Sektor geschrieben. Die Speicherkarte und der Controller müssen also nur so lange gepuffert sein, wie das Schreiben dieser beiden Sektoren plus Reserve dauert. Die Stromversorgung wird letztlich also etwas aufwändiger. Ist zwar umständlicher, aber nicht unlösbar. In einem solchen System ist es Wurscht, welche Karte von welchem Hersteller unter welchen widrigen Bedingungen eingesetzt wird, denn das Schrieben ist immer abgeschlossen, bevor das System abschmiert oder gesichert gestoppt wird. Wenn o.g. serielle RAM batteriegepuffert ist, können angeschnittene Sektoren darin auch mehrere Wochen überleben, falls die Karte beim Schreiben doch Mist gemacht hat oder der User sie versehentlich ausgeworfen hat.
:
Bearbeitet durch User
Markus F. schrieb: > S. R. schrieb: >> Aber du glaubst mir ja sowieso nicht. > Genau. Weil: zum Glauben geht man ja in die Kirche. Richtig. Deswegen hatte ich dir geschrieben, wie du das selbst messen kannst. Wirst du aber deswegen trotzdem nicht tun.
S. R. schrieb: > Richtig. Deswegen hatte ich dir geschrieben, wie du das selbst messen > kannst. Wirst du aber deswegen trotzdem nicht tun. Du wirst lachen, das habe ich bereits vor Jahren getan. Nicht unbedingt repräsentativ und sicherlich nicht wissenschaftlich korrekt, aber eben so, wie's meine Anforderungen abdeckt. Durchsatzmessungen mit FAT32 und ext2 ergaben bei mir - natürlich mit einer nicht repräsentativen Anzahl von - mehr oder weniger willkürlichen - Testkandidaten (Chinaramschware war nicht dabei) und mit (m)einer auf meine Anforderungen zurechtgeschnittener Software (die per SPI-Mode die Karten selbstverständlich nicht an ihre Durchsatzgrenzen bringt) relativ konsistente Ergebnisse: ext2 war (fast) immer besser. Ausfälle habe ich damals (auch nach mehr als einer Woche Dauerbetrieb) übrigens keine hingekriegt.
Man könnte auch einen Data-Flash nehmen. Z.B. der S25FL164K0XMFI011 braucht für eine Page (256Byte) schreiben max 3ms bei max 20mA. Und im Worst Case ist auch nur die eine Page korrumpiert.
Peter D. schrieb: > Und im Worst Case ist auch nur die eine Page korrumpiert. Und nicht einmal das, weil die 5ms Schreibzeit wird ein 220µF-Kondensator locker überbrücken. Aber so ein DataFlash ist dem TO wahrscheinlich zu klein. Als Zwischenpuffer tut´s wie gesagt auch das RAM, zumal das byteweise geschrieben werden kann und ewig hält...
Markus F. schrieb: > ext2 war (fast) immer besser. Nach Stromausfall brauchst du sowohl bei FAT als auch bei ext2 ein fsck (weil kein Journal), sonst riskierst du ein kaputtes Dateisystem - unabhängig davon, ob das Medium was taugt oder nicht. > ... vor Jahren ... Vielleicht bist du auch einfach nicht in die Limits des Controllers reingelaufen, weil die groß genug oder dein Anwendungsfall zu klein waren. Unterhalb einer gewissen Datenrate spielt das sowieso keine Rolle mehr, weil der Controller die Blöcke dann nicht mehr puffert. Vielleicht verhalten die sich im SPI-Modus auch anders. Ist ein ganzer Haufen "vielleicht", ich weiß. Aber in meinem Netbook steckt z.B. eine "SSD", die mit ext2/ext4/NTFS vollkommen unbrauchbar ist (~ 100-200 KB/s lesend), während sie mit FAT/F2FS fast 10x schneller ist.
> Aber in meinem Netbook > steckt z.B. eine "SSD", die mit ext2/ext4/NTFS vollkommen unbrauchbar > ist (~ 100-200 KB/s lesend), während sie mit FAT/F2FS fast 10x schneller > ist. 10 mal schneller als 200kB/s ist immer noch unbrauchbar, erst recht für eine SSD. Und warum beim lesendem Zugriff ext2 zehn mal langsamer sein soll als FAT leuchtet mir nicht ein, egal ob SSD oder nicht.
Erstens: Das "SSD" stand nicht umsonst in Anführungszeichen. Zweitens: Um eine Datei zu lesen, muss man bei FAT weniger Sektoren für die Metadaten anfassen als bei ext2, und davon liegt mindestens einer logisch vorne. Darauf kann man optimieren, darauf wird auch optimiert.
Im SPI-Mode lese ich (bis zu) knapp 1000 kB/s auf ext2 (ColdFire V4 mit 266 MHz im SPI-Mode). ext2, versteht sich. Das dürfte (mit ein bißchen "Übertaktung", weil meine SPI-Clocks ein bißchen höher als die SD-Spezifikation liegen) so ziemlich das physikalische Limit sein. FAT32 lag meist deutlich darunter (bis zu 800 kB/s). Mit einer 8GB SDHC-Karte. Für mich ist die Entscheidung da relativ klar. Die Schreibraten variieren - je nachdem, wo auf der SD man unterwegs ist - so stark, daß ich dafür keine vernünftigen Werte habe. Trotzdem war - gefühlt - ext2 meist schneller.
Peter M. schrieb: > Deine eigentliche Fragestellung lautete "Was meint ihr?" > Gerne beantworte ich Deine Frage. > Ich meine, dass der Himmel heute ziemlich grau ist. :) > > Eine etwas spezifischere Fragestellung hätte sicherlich auch in "diesem > Forum", wie Du es ja ausdrückst, zu einer spezifischen Antwort geführt. Hahaha. Du beweist gerade das Gegenteil. Was soll der Dummschwätz?? > Die Überlegungen sind zwar korrekt, aber Du übersiehst trotzdem etwas > wichtiges. > > Deine Sorge gilt ja überwiegend der Platzverschwendung. Nein. Meine Sorge gilt der Datenintegrität. Die Platzverschwendung würde ich einfach so akzeptieren, wenn das das schlimmste ist was passiert.
Knut B. schrieb: > Die einzige Lösung wird wohl sein, das System so lange zu puffern, bis > die Logdaten weggeschrieben wurden. Dazu kann man serielles RAM > benutzen. Die Steine gibt es auch mit Backup-Funktion, so dass man einen > Goldcap oder eine Batterie anschließen kann. Dort hinein kommen die > Log-Daten und der gerade angefasste FAT-Sektor. Keine Schlechte Idee. Der µC hat eh ein Backup SRAM und eine RTC mit Akku ist auch vorhanden...
S. R. schrieb: > Erstens: Die SD-Karte zerkloppt dir irgendwelche Sektoren, wenn du den > Stecker ziehst. Beliebige Korruption deiner Daten, irgendwo. > > Zweitens: Die SD-Karte zerkloppt dir naheliegende Sektoren, wenn du den > Stecker ziehst. Betrifft das ein Inhaltsverzeichnis, ist der betreffende > Ordner futsch. > > Drittens: Du bist gerade dabei, die Datenstrukturen des Dateisystems zu > ändern, da reißt's dir den Strom weg. Du hast zwei unterschiedliche > Kopien der FAT und keine Ahnung, welche davon stimmt. > > Soll ich weitermachen? Ja, bitte. Habe mittlerweile Kontakt mit einigen eMMC Herstellern und ich glaube, ich muss Dir (für mich leider) Recht geben. Bei MLC Flash scheint es so zu sein, dass alle Sektoren, die Daten in einer Zelle haben bei einem Stromausfall beschädigt werden können. In diesem Fall führt dann wirklich kein Weg an einer Pufferung vorbei, weil unter diesen Bedingungen keinerlei Datenintegrität garantiert werden kann.
Meine Erfahrung mit meinem selbst gebauten Datenlogger (allerdings CF-card): die Datensammlung erfolgt im RAM, wird dann als tmp.Datei gespeichert und zum Abschluss in die gewünschte Datei umbenannt. Die vorhergende (alte) wird kurz vorher gelöscht. Das hat den Vorteil, dass ein loss power nur im Moment des Umbenennens problematisch ist. Die Praxis zeigt (ich ziehe grundsätzlich bei laufenden Betrieb den Stecker) dass die FAT-32 formatierten Flashs sich deshalb almählich mit defekten Sektoren zumüllen aber die Daten konsistent bleiben. Unter Windows kann man diese Sektoren wieder in "found" Ordner zurückholen und dann löschen.
nochmal ich.. wenn man Daten nur an eine (bereits vorhandene) Datei anhängen will, so wäre folgender Weg denkbar: Kopie von Ziel-Datei machen, Daten an diese Kopie anhängen, prüfen, dass kein Fehler bei der Dateioperation aufgetreten ist, Originaldatei löschen, Kopie wieder zurück umbenennen.
Für die Freunde des gepflegten Datenloggens ein kurzes Update: Bei mir läuft seit ca einer Woche ein Dauertest bzgl. Spannungsausfall während eines Schreibvorgangs. Dabei wird nach einer zufälligen Wartezeit die Spannung per Relais abgeschalten. Es ist immer noch die gute alte SanDisk Consumer Karte im Einsatz. Ergebnis: Es werden wie erwartet Cluster verloren. Das Dateisystem an sich scheint dabei immer heile zu bleiben (wenn man die verlorenen Cluster als akzeptabel einstuft). Es wurden bis jetzt keine Daten nachträglich verfälscht. Alles was als einmal geschrieben war, ist bis jetzt auch so geblieben. (Das Dateiformat der Logdateien und die testhalber geloggten Daten lassen ganz gut darauf schließen.) Ich frage mich jetzt gerade ernsthaft, wie groß das theoretische Risiko von nachträglich zerstörten Daten bei MLC Flash tatsächlich ist. Schließlich habe ich im Moment keinerlei Mechanismen gegen Schreibvorgänge bei Spannungsausfall aktiv und verlasse mich einzig und allein auf die SD Karte. Nach über 5000 Spannungsunterbrechungen ist bis jetzt alles gut.
Karl schrieb: > Ergebnis: Es werden wie erwartet Cluster verloren. Das Dateisystem wird also inkonsistent, aber du kannst damit leben. > Ich frage mich jetzt gerade ernsthaft, wie groß das theoretische Risiko > von nachträglich zerstörten Daten bei MLC Flash tatsächlich ist. Ich vermute mal, dass das bei manchen SD-Karten fast immer und bei anderen Karten nie auftritt, weil das eine Funktion des Controllers ist. Du scheinst einfach eine gute Karte erwischt zu haben. Oder du merkst einfach nicht, wie im unbenutzten Teil ständig Daten kaputt gehen. ;-)
S. R. schrieb: > Oder du merkst einfach nicht, wie im unbenutzten Teil ständig Daten > kaputt gehen. ;-) In ungenutzten Clustern befinden sich keine Daten, also können sie auch nicht kaputt gehen. @Karl: Welche Größenordnung hat denn der Cluster-Verlust? Ist der relevant?
S. R. schrieb: >> Ich frage mich jetzt gerade ernsthaft, wie groß das theoretische Risiko >> von nachträglich zerstörten Daten bei MLC Flash tatsächlich ist. > > Ich vermute mal, dass das bei manchen SD-Karten fast immer und bei > anderen Karten nie auftritt, weil das eine Funktion des Controllers ist. > Du scheinst einfach eine gute Karte erwischt zu haben. Meinst Du dass das bei an sich baugleichen Karten unterschiedlich sein kann? > Oder du merkst einfach nicht, wie im unbenutzten Teil ständig Daten > kaputt gehen. ;-) Alle Hersteller haben bis jetzt gemeint, dass der Fehler auf jeden Fall in der selben Erase Group liegt, wenn er denn auftritt. Hast Du anderslautende Informationen? Bis jetzt habe ich 1x am Tag ausgelesen und überprüft. Es sind ca 2,4 GiB Daten pro Tag, da hätte man schon was sehen können, wenn das ein ernsthaftes Problem wäre. Trotzdem habe ich vorgestern angefangen die Karte mal komplett zu füllen.
Peter M. schrieb: > @Karl: > Welche Größenordnung hat denn der Cluster-Verlust? > Ist der relevant? Für meine Anwendung eher weniger. Ich verliere aktuell bei 3,5 GiB Daten 22 MiB an Clustern laut chkdsk. Dabei ist die Anzahl der Spannungsunterbrechungen unnatürlich hoch, da ist in einer echten Anwendung sicher ein Faktor 20 .. 100 dazwischen. Für mich ist das tolerierbar. Vielleicht mach ich noch eine kleine Routine die im Hintergrund verlorene Cluster sucht und wieder freigibt... Dürfte nicht so aufwendig sein.
Diese momentan günstig beschaffbaren 1TB und mehr USB-Sticks, wie sicher sind die eigentlich? Halten die vermutlich viel weniger Schreibzyklen als die paar GB-Varianten durch? Irgendwie kommen mir dir doch als zu sehr preisgünstig vor.
Karl schrieb: >> Du scheinst einfach eine gute Karte erwischt zu haben. > > Meinst Du dass das bei an sich baugleichen Karten unterschiedlich sein > kann? Er meint wahrscheinlich Du hast einen guten Typ von Karte erwischt, eine deren Controller eine bessere Strategie zum Umkopieren, Schreiben und Löschen anwendet die Datenverluste in alten Sektoren beim Umkopieren derselben weniger wahrscheinlich oder gar unmöglich macht. Oder eine die überhaupt kein Wear-Leveling außerhalb der FAT macht. Und wenn sie von außen baugleich aussehen könnte trotzdem die eine 2 Jahre alt sein und die andere letzten Monat in dem neuen Werk in China gefertigt sein. Mit original chinesischem Controller für 5 cent weniger. Oder die eine war irgendwann in der Vergangenheit schonmal voll (Wear Leveling Pool leer) und die andere war fabrikneu (Pool voll). Es reicht auch schon sie mit dem falschen Tool zu formatieren und die korrekten Offsets und Alignments nicht einzuhalten, schon muss die Karte jedesmal doppelt so viel löschen und schreiben oder umkopieren.
:
Bearbeitet durch User
Karl schrieb: >> *weil das eine Funktion des Controllers ist.* >> Du scheinst einfach eine gute Karte erwischt zu haben. > > Meinst Du dass das bei an sich baugleichen Karten unterschiedlich sein > kann? Wie gesagt, das hängt vom Controller ab. Du hast keine Ahnung, was da für ein Controller drin ist, und selbst die Aufschrift gibt dir keine Garantien. >> Oder du merkst einfach nicht, wie im unbenutzten Teil ständig Daten >> kaputt gehen. ;-) > Alle Hersteller haben bis jetzt gemeint, dass der Fehler auf jeden Fall > in der selben Erase Group liegt, wenn er denn auftritt. Hast Du > anderslautende Informationen? Die Controller halten mehrere (oft zwei oder mehr) Erase Groups (Blocks) gleichzeitig offen, d.h. auch oder nur im RAM des Controllers. Lineare Zugriffe gehen dann genau einmal pro Block ins Flash durch - das ist wichtig für Kameras. Ziehst du die Spannung ab, gehen immer nur die gerade geöffneten Blöcke kaputt (d.h. enthalten alte Daten oder Nullen). Aber: Welche Daten das sind, und welche Konsequenzen das hat, kannst du nicht vorhersehen, v.a. wenn das Wear-Levelling über Blockgrenzen hinaus arbeitet. Ich vermute, dass manche Controller für die ersten Blöcke Sonderregeln anwenden (wegen FAT) und Blöcke automatisch schließen (wegen Datensicherheit) oder einen Befehl dafür verstehen. Letzteres kann auch vom Zugriffsmuster abhängen (z.B. die FAT-Zugriffe nach einem fclose); je nach Heuristik gehen dann andere (selbst formatierte) Dateisysteme kaputt. Sicher ist aber, dass manche Controller nichts dergleichen tun. Da sind dann nach einem Stromausfall beliebige Daten hinüber. Deine Karte gehört offensichtlich nicht dazu. Für den Worst Case musst du das annehmen, für den Common Case eher nicht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.