mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik FAT32: Was passiert im Fehlerfall


Autor: Karl (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Jim M. (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: karl (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
holger schrieb:
> Davon kannst du nicht ausgehen.

Es gibt emmc die das garantieren.

Autor: karl (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Buber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Nop (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Karl (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Karl (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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?

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Fat32 Experte kann dazu nichts weiter beitragen. Da musst du schon 
die Herstellers der Karten fragen. Erfahrungsgemäß beantworten die 
solche Detailfragen nicht.

Autor: SearchMe (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Karl schrieb:

> Zufällig noch ein FAT32 Experte hier?

Was soll dir der mitteilen?

Autor: Torsten R. (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Mikro 7. (mikro77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-( ).

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mikro 7. (mikro77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Markus Zehren (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mikro 7. (mikro77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
https://www.embeddedarm.com/blog/preventing-filesy...

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?

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mikro 7. (mikro77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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 ;-)

Autor: Markus Zehren (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und das glaubst Du oder das weißt Du? Wenn letzteres, woher?

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Peter M. (r2d3)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Markus F. (mfro)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
S. R. schrieb:
> Aber du glaubst mir ja sowieso nicht.

Genau. Weil: zum Glauben geht man ja in die Kirche.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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
Autor: S. R. (svenska)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Markus F. (mfro)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Peter D. (peda)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: S. R. (svenska)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: S. R. (svenska)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: uwe (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: uwe (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Karl (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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. ;-)

Autor: Peter M. (r2d3)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: S. R. (svenska)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.