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