FatFS Dateisystem

Peter schrieb:

> Für einen Datenlogger muss ich auf eine 32GB SD-Karte solange Daten
> abspeichern, bis diese komplett gefüllt ist. Das ganze funktioniert
> soweit auch einwandfrei, allerdings nur solange, bis eine gewisse Menge
> an Daten abgespeichert wurde. Danach werden die Schreibvorgänge und das
> erstellen neuer Ordner immer langsamer und langsamer.

Das ist doch vollkommen logisch. Du Suchvorgänge nach freiem Speicher 
dauern immer länger. Da die FAT als einfache lineare Liste vorliegt und 
nicht im RAM gecached wird, müssen sie bei jedem Suchvorgang immer 
wieder von neuem ganz von vorn eingelesen werden, bis ein freier Cluster 
gefunden wird. Da das mit zunehmende Füllung natürlich erst immer weiter 
hinten in der Liste der Fall ist, dauert das Einlesen immer länger.

Damit ergibt sich auch gleich eine sehr einfache Optimierung für dein 
Zugriffsmuster: Du merkst dir einfach, in welchem Sektor der FAT du 
zuletzt freien Speicher gefunden hast und läßt die Suche immer erst ab 
diesem FAT-Sektor beginnen.

Diese Optimierung hilft natürlich nur bei so einem einfachen 
Zugriffsmuster mit monoton wachsendem Datenbestand. Für dasselbe in 
clever muss man schon ein wenig mehr Hirnschmalz investieren. Da hilft 
es, einen dynamischen Index (sprich: binary tree) über die FAT zu 
generieren und mitzuführen. Der braucht zwar auch RAM, aber wesentlich 
weniger als ein kompletter FAT-Cache. Und das Beste: man kann den 
Speicherbedarf des Baums dem verfügbaren RAM anpassen. Je mehr Speicher 
er benutzen kann, desto wirkungsvoller kann er die Suchvorgänge nach 
freiem Speicher beschleunigen. Allerdings: die dynamische Aktualisierung 
des Suchbaums kostet ihrerseit aber natürlich auch wieder Rechenzeit.

Trotzdem lohnt das. Deswegen machen es auch alle ernstzunehmenden 
Datenbanken und Dateisysteme ganz genau so...

Hallo zusammen

Vielen Dank schon mal für die vielen guten Antworten.

Gut also ich kann nachvollziehen, dass das Finden von freien Sektoren 
auf der SD-Karte bei zunehmenden Daten länger dauert. Dann müsste sich 
ja aber die Zugriffszeiten konstant verlangsamen - also je mehr Daten 
auf der SD-Karte sind, desto länger werden die Schreibzyklen. Dann kann 
es ja nicht sein, dass kurzzeitig die Schreibvorgänge wieder sehr 
schnell sind und dann plötzlich wieder extrem langsam. Irre ich mich da? 
Ich sehe da den zusammenhang nicht, denn es müssen ja immer die gleichen 
Schritte durchgeführt werden, nähmlich das Suchen von freien Sektoren/ 
Clustern.

Weiter kann ich auch noch nicht nachvollziehen, worin den die 
Unterschiede bestehen, ob ich jetzt eine neue Datei eröffne oder ob ich 
in die selbe Datei schreibe. Den es wird ja bei beiden nach freien 
Sektoren gesucht, um die Daten zu speichern. Wie unterscheidet die 
SD-Karte diese "Daten"? (Neue Datei dauert in der Regel extrem viel 
länger, als in bestehende zu schreiben)

Ebenfalls nicht fündig wurde ich, wie man am besten die SD-Karte belegt. 
Ist es besser, sehr grosse Daten am Stück zu belassen oder nur kleine 
Dateien zu schreiben, dafür sehr viele? Und weshalb macht das einen 
Unterschied, ob sehr viele Dateien in einzelnen Ordner sind oder auf 
mehrere verteilt? Wie gross sollte man den die Datensätze wählen und von 
was hängt das ab?

Ihr seht ich blicke da leider - trotz stundenlanger 
Informationsbeschaffung - irgendwie noch nicht ganz durch.

Die Idee con c-hater kling eigentlich sehr gut - gleichzeitig aber auch 
sehr kompliziert. Ich dachte, die FatFS-Library von ChaN macht sämtliche 
Optimierungen bezüglich Zugriffen etc. selber, so dass ich micht mit der 
SD-Karte nicht "beschäftigen" muss. Ich kann mir nähmlich irgendwie auch 
nicht vorstellen, dass ich der Erste bin, der mit solchen "grossen" 
SD-Karten arbeitet. Das Problem besteht bei meinem System nähmlich 
darin, dass ich sehr wenig Rechenleistung bei sehr wenig vorhandener 
Energie habe. Dauert der Schreibvorgang zu lange, stellt mein System ab, 
da die Energiereserven nicht ausreichen.


Vielen Dank für eure Hilfe.

Grüsse
Peter

> Ebenfalls nicht fündig wurde ich, wie man am besten die SD-Karte belegt.

Für optimale Performance legst du auf der SD Karte eine einzige Datei 
an, die den gesamten Platz belegt. Und diese Datei befüllst du dann nach 
und nach mit den tatsächlichen Daten.

Dann musst du deine Daten natürlich irgendwie selbst strukturieren. und 
so erhältst du letztendlich eine Datenbank oder ein Dateisystem in einer 
Datei.

> Ich dachte, die FatFS-Library von ChaN macht sämtliche
> Optimierungen bezüglich Zugriffen etc. selber, so dass
> ich micht mit der SD-Karte nicht "beschäftigen" muss.

Die Library wurde wohl eher so geschrieben, dass sie möglichst wenig RAM 
belegt. Linux und Windows wären diesbezüglich das andere Extrem.

Hallo zusammen

Gut also geschrieben wurde, dass ein Schreibzyklus zwischen "fast 
nichts" und "100ms" dauern kann. Damit hätte ich absolut kein Problem, 
aber das schein so nicht der Fall zu sein. Mein System hat erst 
Probleme, wenn der Schreibzyklus 4 Sekunden dauert, und das scheint der 
Fall zu sein. Nach vier Sekunden ist mein Zwischenspeicher gefüllt und 
beginnt überzulaufen, wenn die SD-Karte nicht bereit ist.

Ok, gemäss euren Antworten ist es also am besten, grosse Datnesätze zu 
haben. Das dachte ich auch, bis ich das in der Praxis getestet habe. 
Also sehr viele Daten in einem Ordner macht probleme, dass kontte ich 
auch nachmessen. Allerdings sehr grosse Daten (200MB), wobei so viel 
Daten vorhanden waren, dass die Karte fast voll ist, führt dann dazu, 
dass das erstellen eines neuen Ordner extrem lange dauert (26 Sekunden 
nachgemessen). Wird die SD-Karte ebenfalls fast gefüllt, allerdings mit 
30MB Daten, so dauert das Erstellen eines neuen Ordners deutlich weniger 
lang (8 Sekunden). Beides ist eigentlich viel zu lange, aber der 
Unterschied ist drastisch.


Auf was sollte man beim Kauf einer SD-Karte achten, damit ich diese 
Probleme in den Griff bekomme respektive verbessern kann?

Vielen Dank.

Gruss
Peter

S. R. schrieb:
> (Hinweis: auf FAT maximal 2 GB!)
Falsch, es sind 4 GiB-1B, also 4294967295 Bytes :)

Peter schrieb:
> Auf was sollte man beim Kauf einer SD-Karte achten, damit ich diese
> Probleme in den Griff bekomme respektive verbessern kann?
Versuch einfach mal eine bessere SD-Karte. Ich habe sehr gute 
Erfahrungen mit den Samsung Evo SDHC Karten gemacht. SanDisk und Toshiba 
hingegen haben sporadisch sehr lange Zugriffszeiten.
Selbst der SD-Standard sagt, dass das Schreiben großer Blöcke auf einmal 
besser ist. Ideal (bei SDHC) sind immer 4 MiB am Stück. Viele kleine 
Dateien sind immer schlecht...

S. R. schrieb:
> Das hängt davon ab, ob dein Treiber intern uint32_t oder int32_t nutzt,
> beide Varianten wurden verwendet.
Und ich dachte schon das hängt von der FAT32-Spezifikation von Microsoft 
ab... Wäre ja auch zu einfach wenn alle Treiber/Geräte das gleiche FAT32 
sprechen!
Wer int32_t für etwas verwendet das laut Spezifikation definitiv 
uint32_t verlangt, macht was falsch. Ein solcher Treiber ist nutzlos...

S. R. schrieb:
> - sicherstellen, dass die Partition korrekt ausgerichtet ist
>   (die Werksformatierung sollte das sein, deine eigene nicht
>   unbedingt) und eventuell neu formatieren
Richtig, und zwar mit dem Tool von 
https://www.sdcard.org/downloads/formatter_4/index.html , nicht den 
Standard-Tools vom OS.

S. R. schrieb:
> - die Partition verkleinern, so dass 10% des Flashes unpartitioniert
>   sind (damit gibst du dem Kartencontroller mehr Platz zum Atmen);
Der Controller hat typischerweise noch "unsichtbare" Blöcke zum 
ausweichen. Die SD-Spezifikation verlangt dass die Partition bis zum 
Ende geht; ist das nicht der Fall ist die Funktionsweise nicht 
garantiert. Was eher sinnvoll ist, die Karte nicht 100% vollzuschreiben 
- der Controller weiß ja dank FAT, welche Blöcke noch frei (zum 
Ausweichen) sind.

Bei meinen eigenen Versuchen habe ich keine Verlangsamung bei voller 
Karte feststellen können. Dramatische Auswirkungen hat aber die Menge 
der auf einmal geschriebenen Daten sowie der Hersteller...

Hallo zusammen

Ich habe jetzt mal neue SD-Karten bestellt (unter anderem die 
vorgeschlagene Karte von Samsung) und erwarte morgen/ übermorgen die 
Lieferung. Bin ja gespannt wie gross der Unterschied zwischen den 
einzelnen SD-Karten ist. Ich werde diesbezüglich so schnell wie möglich 
wieder berichten.

Aber was ich immer noch nicht verstehe ist, weshalb das so ein enormer 
Unterschied ist, um ein Ordner zu erstellen bei folgenden Situationen:

32GB fast gefüllt mit jeweils 200MB Daten
-> Erstellen eines neuen Ordners ganz am Anfang des Loggens dauert ca. 
26 Sekunden

32GB fast gefüllt mit jeweils 32MB Daten
-> Erstellen eines neuen Ordners ganz am Anfang des Loggens dauert ca. 8 
Sekunden

Gemäss erhaltenen Informationen müsste es doch immer besser/ schneller 
werden, je grösser die Datensätze gewählt sind, den dies bewirkt auch 
eine einfachere Struktur im Fat-Dateisystem, nicht?

Besten Dank für eure Feedbacks.

Grüsse
Peter

> Wer int32_t für etwas verwendet das laut Spezifikation definitiv
> uint32_t verlangt, macht was falsch. Ein solcher Treiber ist nutzlos...

Urteile nicht so hart. Es war viele Jahre lang allen Programmierern 
klar, dass FAT Partitionen und Dateien darauf maximal 2GB groß sein 
dürfen. Und dass man einen signed Integer verwendet hat, war auch viele 
Jahre lang üblich.

Irgendwann wurde das zugunsten der 4GB Dateien geändert.

Wir schleppen noch viele andere Altlasten und Unklarheiten mit uns 
herum. Damit muss man einfach Leben. Ganz besonders, wenn man im 
Internet Umfeld programmiert.

Stefan U. schrieb:
> Und dass man einen signed Integer verwendet hat, war auch viele
> Jahre lang üblich.

Das stimmt allerdings. Selbst das (alte) Standard-Java-API verwendet 
"int" (in Java immer 32bit signed), d.h. max 2 GB Dateigröße. Windows 
und Linux haben aber keine Probleme mit 4GiB Dateigröße, und da die 
Karten eines solchen Loggers vermutlich nicht in einem antiken 
MP3-Player landen, würde ich da dennoch die 4GiB auch nutzen. Bei meinen 
Experimenten hatte ich da keinerlei Probleme mit.

Peter schrieb:
> 32GB fast gefüllt mit jeweils 200MB Daten
> -> Erstellen eines neuen Ordners ganz am Anfang des Loggens dauert ca.
> 26 Sekunden
>
> 32GB fast gefüllt mit jeweils 32MB Daten
> -> Erstellen eines neuen Ordners ganz am Anfang des Loggens dauert ca. 8
> Sekunden
Das sind ja katastrophale Werte. Die langsamste Operation die ich je 
gemessen hab war ca. 2 Sekunden (bei einer SanDisk-Karte). Finde doch 
mal heraus, welche Operation in der FatFS Library so lange dauert - das 
Suchen freier Cluster, das Beschreiben des Verzeichniseintrags,...?

Hallo zusammen

Habe bereits nachgemessen, welche Funktion so lange dauert. Und zwar bin 
ich zum Schluss gekommen, dass innerhalb der f_mkdir Funktion die 
Unterfunktion

1

dcl = create_chain(dj.fs, 0);  /* Allocate a cluster for the new directory table */

sehr lange dauert.

Es ist allerdings zu unterscheiden, ob die SD-Karte zuvor mit Windows 
verändert wurde - das heisst irgendein File verändert/ gelöscht/ 
hinzugefügt wird. Konnte direkt mit der FatFS-Library bereits ein Ordner 
neu erstellt werden (also nach 26 Sekunden warten) dauert dies beim 
nächsten Ordner nur noch wenige ms bis eine Sekunde. Also auch nach dem 
die SD-Karte vollständig entfernt und wieder eingesetzt wurde ist dies 
so der Fall. Also mir scheint, als ob Windows irgendwas in der 
"Datenbank" umformatiert, und die FatLibrary das zuerst neu ordnen muss. 
Ich blicke da aber zu wenig durch um solche Schlüsse zu ziehen.

Die SPI-Schnittstelle taktet bei mir mit 8MHz, was gemäss den mir 
vorliegenden Informationen die maximale zulässige Taktfrequenz sein 
sollte. Täusche ich mich da?

Grüsse
Peter

Jim M. schrieb:
> Bei 32GB ist die FAT Größe ca. 4 MByte.  Ein AVR braucht bei 10 MHz SPI
> schon 3 Sekunden für die nackte Übertragung ohne Overhead.
> Und da man die Daten auch verarbeiten muss, sind die 8 Sekunden schon
> recht nahe am Erwartungswert.

Achja, die schwachbrüstigen AVR :) Aber es war gar nie von AVR die Rede, 
oder hab ich was überlesen? Ein STM32 braucht für 4 MiB lesen bei SDIO 
und HS 167ms, und wenn man gleichzeitig überträgt und verarbeitet (DMA) 
braucht das Suchen kaum länger. Hoffentlich merkt sich die FatFS wo sie 
zum letzten mal einen freien Cluster gesehen hat, um nicht jedes mal von 
vorne zu suchen...

Peter schrieb:
> Und zwar bin
> ich zum Schluss gekommen, dass innerhalb der f_mkdir Funktion die
> Unterfunktion
> dcl = create_chain(dj.fs, 0);  /* Allocate a cluster for the new
> directory table */
> sehr lange dauert.

Ah, das war zu erwarten. Jetzt musst du darin noch herausfinden, ob das 
Suchen derart lange dauert und ob es da keinen Cache gibt. Hatte das 
FatFS nicht eine Caching-Option (fastseek oder so)? Hast du die 
eingeschaltet?

Also die fastseek-Option habe ich gesehen, hab da aber ehrlichgesagt 
nicht ganz verstanden, für was die gut sein soll. Wenn du mir also 
sagst, dass das gut sein könnte, dann lese ich mich da noch genau ein.

Besten Dank

Grüsse
Peter

Also ich benutze ein MSP430FR5969 Mikrocontrollerboard von TI. Der 
Controller selber taktet mit 16 MHz, die SPI-Schnittstelle mit 8MHz. Bin 
mir gar nicht mehr sicher, weshalb ich auf 8MHz kam, aber ich dachte 
dies sei die Grenze von irgendwas. Könnte sein, dass das die Grenze 
meiner SPI-Schnittstelle des Controllers war =)

Peter schrieb:

> Gemäss erhaltenen Informationen müsste es doch immer besser/ schneller
> werden, je grösser die Datensätze gewählt sind, den dies bewirkt auch
> eine einfachere Struktur im Fat-Dateisystem, nicht?

Nein. Auf das offensichtliche Hauptproblem, die Suche nach freien 
Clustern, hat es wenig bis keinen Einfluss, wie genau die Daten 
strukturiert sind. Dafür ist eigentlich nur eine Sache entscheidend: die 
"allocation strategie", die verwendet wurde, während die bisherigen 
Daten auf das Medium gelangt sind und die allocation strategie, die 
verwendet wird, um die neuen Daten zu schreiben.

Scheinbar ist die ElmChan-Implementierung immerhin so clever, sich den 
FAT-Sektor zu merken, in dem die Suche zuletzt freie Cluster gefunden 
hat. Aber diese Optimierung ist nur relativ klein. Sie endet 
offensichtlich in dem Moment, wenn die freien Cluster dieses Sektors 
aufgebraucht sind. Dann wird erstmal wieder eine Runde lineare Suche 
ganz vom Anfang eingeschoben.

Diese kleine Optimierung bringt also nicht wirklich viel, sie genügt 
aber völlig, um absolut nichtssagende Messwerte zu produzieren, nämlich 
welche mit extremen Sprüngen, abhängig von der aktuellen Belegung und 
der Zahl der für einen Vorgang benötigten freien Cluster. Wenn man den 
Kram allerdings häufig genug mißt und die Ergebnisse kompetent mit den 
Methoden der Statistik auswertet, dann kommt da doch wieder was 
aussagekräftiges raus: nämlich, dass die Suchzeiten exponentiell mit dem 
Datenbestand ansteigen (was angesichts der verwendete Strategie auch 
nicht anders zu erwarten war)...

Und nur ein Index oder ein Cache für die FAT kann daran etwas 
grundlegendes ändern. Ob dir das nun paßt oder nicht...

c-hater schrieb:

> Und nur ein Index oder ein Cache für die FAT kann daran etwas
> grundlegendes ändern. Ob dir das nun paßt oder nicht...

Ergänzend: Schon eine Index, der nur aus einem einzigen Byte besteht, 
kann die mittlere Suchzeit theoretisch um ca. den Faktor 8 reduzieren. 
Ein Index aus drei Byte ca. um den Faktor 16 usw.

Natürlich steigt der Gewinn in der Realität nicht ganz so stark an, was 
sich umso stärker zeigt, je tiefer der Baum ist. Aber 15, 31 oder 63 
Bytes Index wären, bezogen auf dein Problem, ganz sicher sehr gut 
angelegte Bytes. Mehr Performancegewinn pro eingesetztem Byte RAM 
bekommst du ganz sicher mit keiner anderen denkbaren Methode (jedenfalls 
nicht bezogen auf universelle Nutzung, für den Fall monoton wachsenden 
Datenbestands habe ich die optimale Lösung ja bereits gepostet)...

Allerdings: wie auch die kleine Optimierung von ElmChan sorgt so ein 
Index u.U. auch für heftige Sprünge in der Performance. Er muss nämlich 
erst einmal aufgebaut werden. Und das geht bei einem "neuen" (also für 
das System neuen) Filesystem entweder dadurch, das man einmal die 
lineare Suche komplett durchläuft, um ihn vollständig aufzubauen (was 
entsprechend lange dauert, aber dafür in der Folge keine heftigen 
Sprünge mehr produziert) oder man baut ihn vollkommen dynamisch im 
laufenden Betrieb auf, was dann eben für Sprünge sorgen kann, weil 
zwischendurch immer mal wieder eine Runde lineare Suche mit Indexaufbau 
erfolgen muss.

Bei dem Anwendungsfall mit ab "leer" monoton wachsendem Datenbestand 
sind allerdings auch ohne initialen Indexaufbau keine großen Sprünge zu 
befürchten. Da wächst der Index wirklich nahezu unmerklich nebenbei und 
tut einfach seinen Job.

Vielen Dank für die ausführliche und nützliche Antwort, c-hater.
So wie ich mich grad eingelesen habe, könnte die Option mit dem 
fast_seek tatsächlich etwas gutes sein, nur verstehe ich das ganze nicht 
wirklich.

Je genauer ich die FatFS Library studiere, desto mehr bin ich 
verunsichert, ob ich das überhaupt richtig mache. Deshalb hier kurz mal 
den Ablauf, welchen ich verwende:

Erstellen eines neuen Files:

1

f_open(&g_sFileObject, g_pcTmpBuf, FA_WRITE | FA_CREATE_ALWAYS);// öffnen File mit Namen in g_pcTmpBuf

2

f_lseek(&g_sFileObject,FILESIZE);// Pre-allocate Clusters, so gross wie File effektiv wird

3

f_lseek(&g_sFileObject, 0); // Pointer an Anfang des Files

Schreiben in das File:

1

f_write(&g_sFileObject, buffer, size, 0); // Schreiben des Buffers in das eröffnete File

2

f_sync(&g_sFileObject);  // The f_sync function flushes the cached information of a writing file.

Schliessen des File:

1

f_truncate(&g_sFileObject);           // Truncate unused area

2

f_lseek(&g_sFileObject, 0);           // Put file header

3

return f_close(&g_sFileObject);

Ist das so korrekt, dass ich zuerst ein Cluster "Pre-allocate", damit 
das System weiss, wie gross diese Datei wird? Wie müsste man dies jetzt 
mit der Fast_Seek Methode erweitern?

Vielen Dank für eure Hilfe.

Grüsse
Peter

Peter schrieb:

> Ist das so korrekt, dass ich zuerst ein Cluster "Pre-allocate", damit
> das System weiss, wie gross diese Datei wird?

Ja, das hilft dir aber kein bissel. Das verlagert nur die gesamte 
Sucharbeit, die normalerweise (quasizufällig) verteilt über die 
Schreibzeit einer Datei anfällt, auf den Moment, in dem du die Datei 
öffnest. Das ist alles. Sprich: das Öffen dauert genau so viel länger, 
wie später das Schreiben insgesamt schneller geht.

Das ist, wie viele kleine Scheisseberge auf einer 100m-Stecke einfach so 
umzustapeln, dass der ganz große Berg schon direkt am Startblock im Weg 
liegt...

Natürlich hat auch dieser Ansatz seinen Sinn, nämlich immer dann, wenn 
das eigentliche Schreiben möglichst schnell erfolgen können muss, die 
Zeit, die zum "Öffnen" der Datei benötigt wird aber irrelevant ist.

Das ist aber nicht dein Problem. Für dein Problem hat ElmChan keine 
Lösung mitgeliefert. Du hast zwei Möglichkeiten: 1) Du machst es dir 
selber oder 2) du bezahlst jemanden dafür, dass er es dir macht. So 
einfach ist das.

Moin.

Was spricht dagegen die sd carte mit einem Windows Tool mit Dateien und 
Verzeichnissen zu versehen. Der Controller arbeitet dann nur noch mit 
den bereits bestehenden Dateien und überschreibt nur den Inhalt. Dabei 
nicht die Dateigröße verändern. Oder Dateien umbenennen. Der overhad um 
freie Cluster zu suchen entfällt damit.

Formatierungparameter prüfen. Clusregrösse fals das hier überhaupt 
relevant ist. Die Position des ersten Datensektors prüfen, die sollte 
2^n sein. Neuere Windows Systeme formatieren bereits entsprechend. Unter 
Linux kann man das angeben. Hat was mit dem in der sd carte verbauten 
flash zu tun. Sektoren eines Clusters sind  dann nicht über 2flash 
Kacheln verteilt.

Der sd Card mitteilen welche Sektoren gelöscht sind. Gibt glaube ich ein 
sd Card Commander dafür. Nicht nur auf der fat Ebene. Damit kann die sd 
Card die ggf vorher schon mal löschen und das Schreiben geht dadurch 
etwas schneller. Bzw kopiert die nicht benötigten Daten im Hintergrund 
dumm mit.

Gruss.

123 schrieb:
> Die Position des ersten Datensektors prüfen, die sollte
> 2^n sein.
Nein, die ist fix (iirc 4096 Sektoren).

123 schrieb:
> Neuere Windows Systeme formatieren bereits entsprechend. Unter
> Linux kann man das angeben. Hat was mit dem in der sd carte verbauten
> flash zu tun.

Besser so:

Dr. Sommer schrieb:
> Richtig, und zwar mit dem Tool von
> https://www.sdcard.org/downloads/formatter_4/index.html , nicht den
> Standard-Tools vom OS.

123 schrieb:
> Gibt glaube ich ein
> sd Card Commander dafür.
Nein. Man kann höchstens explizit löschen. Das Mitteilen von nicht 
benötigten Sektoren geht über die FAT (die dazu natürlich an der 
richtigen Stelle stehen muss - daher mit dem Spezial Tool formatieren).

S. R. schrieb:

> Du hast eine Lösung vergessen:
> 3) Du nimmst eine Plattform, die dieses Problem nicht hat.

Das ist immer die Lösung aller Idioten: wenn wir keine Ahnung vom 
Programmieren haben und auch nix dazu lernen wollen oder können, nehmen 
wir einfach eine Hardware mit mehr Resourcen...

Und dann fallen diese ganzen Pisser irgendwann reihenweise auf die 
Schnauze, wenn sie merken, dass Systeme, die reichlich 
Hardware-Ressourcen haben, vor allem auch noch was anderes haben: einen 
sehr viel höheren Energiebedarf...

@Dr Sommer.
Zum Löschen von sektoren
Sd Card specification sagt da was anderes. Cmd32 cmd33 und cmd38. Acmd23
Die Karten können auch anders formatiert sein oder sogar partitioniert. 
Da darf die Karte nicht von selbst irgend welche Sektoren als leer 
betrachten und für was anderes verwenden. Hab ich auch noch nicht 
beobachtet.
Und erlichgesagt nem frisierten 8051 trau ich das auch nicht zu 
nandflasch Verwaltung, Wareleveling und dann noch fat auswerten.

Zur Position des ersten Daten Sektors. Kann ich mich täuschen wir hatten 
da nur deutliche Unterschiede bei USB sticks festgestellt bei XP vs W7 
FAT32 Formatierung. Und das gleiche Zeit auch bei einer sd Card auf. Im 
Hintergrund werkelt immer ein grosser nand flash

123 schrieb:

> Die Karten können auch anders formatiert sein oder sogar partitioniert.

Das können sie natürlich.

> Da darf die Karte nicht von selbst irgend welche Sektoren als leer
> betrachten und für was anderes verwenden.

Richtig, das dürfen sie nicht.

> Hab ich auch noch nicht
> beobachtet.

Richtig, machen sie auch nicht.

Was sie aber machen: sobald die Partitionierung/Formatierung vom 
Auslieferungsstandard abweicht, schalten sie in den "Sägemodus", d.h.: 
sie schalten alle Optimierungen ihrer wear-levelling-Strategie ab, denn 
die passen eben nur genau zu einem: dem Auslieferungszustand.

Der Erfolg ist eine sehr schnell auf unglaublich grottige Werte 
absinkende Schreibrate und auf längere (aber nicht wirklich lange) Sicht 
ein deutlich vorzeitiges Verenden des Mediums. Mit ein wenig Glück haben 
wenigstens einigermaßen kompetente Entwickler die Firmware gebaut, die 
die Sache dann so lösen, dass nach Vebrauch des letzten Spare immerhin 
noch jeder beliebige Lesezugriff auf den quasi eingefrorenen letzten 
gültigen Zustand möglich ist, jedenfalls solange kein Schreibzugriff 
erfolgt. D.h.: man kann den Scheiß immerhin noch RO mounten und die 
Daten abziehen.

Die Hardcore-Datenvernichter hingegen unterbinden ab dem Crash jeden 
Zugriff. Die Daten sind dann also definitiv unerreichbar im Nirvana des 
Flashcontrollers verschwunden.

Und das alles passiert genau so bei praktisch allen Flash-Medien, die 
man heute kaufen kann. Egal ob USB-Stick, SD-Card oder sonstwas. Der 
Hintergrund ist natürlich eine reine Kostenfrage. Wenn ich z.B. ein 
32GB-Medium verkaufen will, dann ist da immer mehr Flash-Speicher 
drinne. Wieviel mehr, das ist der Knackpunkt bei den Kosten. Mit nur 
noch ganz wenigen Ausnahmen haben heute deswegen 32GB-Medien alle 
gerade mal nur 32GiB Flash. Da bleibt echt nicht viel Platz für Spare 
und den Index für das wear-levelling.

Und genau letzteres ist das Hauptproblem und hier setzen die 
Optimierungen der Flashcontroller an. Sie versuchen, den benötigten 
Platz für diesen Index zu verringern, damit wenigstens etwas mehr für 
den ohnehin sehr knappen Spare bleibt. Und das tun sie, indem sie 
verschiedene Bereiche des Mediums unterschiedlich behandeln (bezüglich 
der Granularität der im Index gespeicherten Informationen). Und das 
funktioniert eben nur so lange, wie die Struktur des Mediums den 
Erwartungen entspricht. Tut er das nicht mehr, wird einfach alles mit 
der gröbsten Granularität verwaltet. Sprich: die zuvor differenzierte 
Tiefe des Indexbaums wird vereinheitlicht auf das geringste Niveau.

Das ist dann genau das, was ich oben als "Sägemodus" bezeichnet habe. 
Das bedeutet nämlich nichts anderes, als das sehr viele, eigentlich 
unnötige Lösch- und Schreibvorgänge auf dem Level der Flashpages 
passieren müssen. Einfach nur deshalb, weil es der Controller mangels 
eines hinreichend detaillierten Index nicht mehr besser wissen kann.

Und das sorgt dann kurzfristig für drastisch absinkende Schreibraten und 
längerfristig halt zum vorzeitigen Ausfall des Mediums.

Wie auch immer: Flash war und ist von vornherein Beschiss. Kein 
zuverlässiges Medium, sondern eher Verbrauchsmaterial wie etwa 
Klopapier. Eigentlich noch schlimmer als Klopapier, da kann man nämlich 
das Ende der zumutbaren Nutzung immerhin recht zuverlässig abschätzen...

Nunja, bei SSDs gibt's ja immerhin S.M.A.R.T. Aber selbst da lügen viele 
Anbieter wie die Politiker. Wenn sie hier die Wahrheit melden würden, 
wäre das Modell ja auch noch nichtmal annähernd abverkauft, wenn die 
ersten Warnungen im Netz erscheinen und potentiellen Kunden für den Rest 
des Schrotts unter die Augen kommen könnten...

S. R. schrieb:

> Was du beschreibst, ist zwar möglich, halte ich aber für
> unwahrscheinlich (oder zumindest extrem selten). Ich halte es für
> wesentlich wahrscheinlicher, dass sie sämtliche Optimierungen
> beibehalten, obwohl das Dateisystem ein anderes ist.

OK, diese Interpretation ist tatsächlich (mindestens) genauso denkbar 
und würde wirklich (fast) zum gleichen Ergebnis führen. Und ich habe 
auch keine hinreichenden Untersuchungen vorgenommen, um das eine vom 
anderen unterscheiden zu können. Wäre aber mal spannend, dies zu tun. 
Schöne Anregung für den anbrechenden Winter...

> Ich traue den Chips nicht zu, dass
> sie intelligent programmiert sind oder sich das Dateisystem anschauen.

Das wäre aber wirklich trivial umzusetzen. Man braucht nur ein bis 
maximal zwei Sektoren zu überwachen, um das zu tun. Das könnten auch 
völlig blöde Firmware-Programmierer sicher noch hinbekommen. Aber, wie 
du völlig korrekt angemerkt hast: warum, zum Teufel, sollten sie 
eigentlich diesen Aufwand treiben? Das ergibt aus ihrer Sicht 
tatsächlich keinerlei Sinn. Und wie sollten sie auch überhaupt nur auf 
die Idee dazu kommen?

Dementsprechend neige ich jetzt doch sehr stark dazu, deine 
Interpretation der Sache als die sehr viel Wahrscheinlichere anzusehen. 
Vielen Dank für diesen neuen Blickwinkel, den du mir da gegeben hast.

Wenn nämlich deine Interpretation zutrifft, könnte man mit (entsprechend 
angepassten) alternativen Dateisystemen ja sogar durchaus einen nicht 
unerheblichen Nutzen aus diesem Verhalten ziehen...

Hallo zusammen

Besten Dank für die interessanten Kommentare die ihr zum Thema 
geschrieben habt. Sehr interessant zu lesen.

In der Zwischenzeit habe ich noch einige weitere SD-Karten getestet und 
es sind tatsächlich gewaltige Unterschiede feststellbar. Die 
Vorgeschlagene SD-Karte von Samsung (Samsung EVO) schlägt sich wirklich 
recht gut. Allerdings dauert es auch mit dieser SD-Karte teilweise zu 
lange, so dass mein System nach wie vor abschaltet. Dennoch ist eine 
deutliche Besserung sichtbar.

Was mich auch noch wunder nimmt ist, weshalb die einzelnen 
Speicherkarten so drastisch in deren Grösse unterscheiden, obwohl beide 
Karten exakte genau gleich formatiert wurden (SD-Tool, 32KB Cluster). 
Die Karten unterscheiden dabei direkt nach der Formatierung um knapp 1 
GB an verfügbarem Speicher. Woran liegt das? Welcher Platz steht da bei 
der einen zur Verfügung und bei der andern nicht? Hat das damit zu tun, 
wie viel Speicherplatz für das FAT benötigt wird?

Besten Dank für eure Hilfe.

Gruss
Peter

Peter schrieb:
> Was mich auch noch wunder nimmt ist, weshalb die einzelnen
> Speicherkarten so drastisch in deren Grösse unterscheiden, obwohl beide
> Karten exakte genau gleich formatiert wurden (SD-Tool, 32KB Cluster).
> Die Karten unterscheiden dabei direkt nach der Formatierung um knapp 1
> GB an verfügbarem Speicher. Woran liegt das? Welcher Platz steht da bei
> der einen zur Verfügung und bei der andern nicht? Hat das damit zu tun,
> wie viel Speicherplatz für das FAT benötigt wird?

Hmm, die FAT Größe sollte sich nur ändern, wenn sich die Clustergröße 
ändert. Da die bei dir fix 32kB ist, sollte das eigentlich keine 
Auswirkung haben.

Haben beide vor der Formatierung wirklich die selbe Größe gehabt? Hast 
du in beiden Fällen das selbe Formatierungstool mit exakt den selben 
Einstellungen benutzt? Waren da vielleicht schon Daten drauf?