Datei mit bestimmter größe allozieren - FAT16 Dateisystem

Im Grunde ja, bei FAT 32 muss man aber aufpassen, da ich da soetwas wie 
einen Eintrag für alle freien Cluster gesehen habe. Bei FAT 16 Kannst du 
die Bytes im Datensektor ruhigen Gewissens ändern. das interessiert das 
Fatsystem nicht die Bohne

Hi Marcus, konntest nicht auf meine E-Mail Antwort warten ?

Na gut, dann machen wirs halt hier.

>Da ich jedoch jede Sekunde logge und somit leider auch die Dateigröße
>sich jede Sekunde ändert, leben meine SD - Karten nicht lange.

Sterben die wirklich ? Das wär ja mal was für die ct.

>Verstehe ich das jetzt richtig, dass ich lediglich die endgültige
>Dateigröße (eine Datei pro Tag) in den FAT Eintrag (Filesize) eintragen
>muß und sollange, freie Cluster allozieren kann, bis die Dateigröße
>erreicht ist?
>Anschließend wie unter Linux auch die Datei mittels fseek quasi füllen?
>Was hab ich übersehen? Kenne mich leider nicht soo gut mit FAT aus.

FileSize steht im Verzeichniseintrag! Nicht in der FAT.
Fummel nicht selber an FileSize rum, das ist nur meinen FAT
Routinen erlaubt. Lesen darfst du es. Das allozieren von Clustern
machen die auch selbstständig. Du solltest nicht versuchen dies auf
eigene Faust zu tun. Fseek über FileSize hinaus alloziert bei meinem
FAT System (noch) keine neuen Cluster. Fseek geht bisher nur bis
FileSize.

Du willst einmal pro Sekunde Daten schreiben. Dann solltest du nicht
die Datei öffnen, schreiben und gleich wieder schließen. Beim schließen
werden neue FAT Einträge und der Verzeichniseintrag der Datei 
aufgefrischt.
Und das dann jede Sekunde. Halte die Datei einfach so lange offen wie du
es vertreten kannst. Schließe sie z.B. nur alle 60s,120s,240s... oder
rufe in diesen Zeitabständen Fflush auf ohne die Datei zu schließen.

Wenn du Schreibzugriffe auf die Karte minimieren willst gibt es
mehrere Möglichkeiten:

1. Lass 11MB Leerdateien schon von Win/Linux schreiben.
   Dann sind keine Schreibzugriffe auf FAT-/Verzeichnissektoren mit
   meinem FAT Programm mehr nötig.

2. Erzeuge mit meinem FAT Programm erstmal eine 11MB Leerdatei.
   Das wird allerdings einige Sekunden/Minuten je nach Karte dauern.
   Der Verzeichniseintrag mit FileSize wird dann aber nur ein mal 
gemacht.

3. Benutze den FAT Buffer
   Im Idealfall wird bei FAT16 dann nur alle 256 Cluster, bei FAT32
   nur alle 128 Cluster ein FAT Schreibzugriff nötig. Solange die Datei
   offen bleibt! Fclose schreibt den FAT Buffer.

4. Formatiere die Karte mit möglichst großen Clustern
   Je größer die Cluster sind, desto weniger FAT Zugriffe sind nötig.

Es ist zur Zeit nicht möglich mit meinem FAT Programm eine Datei
bestimmter Größe zu erzeugen ohne die Dateisektoren zu
beschreiben. Da werd ich mal drüber nachdenken ;)

Gruß
 holger

Nachtrag:

>1. Lass 11MB Leerdateien schon von Win/Linux schreiben.
>   Dann sind keine Schreibzugriffe auf FAT-/Verzeichnissektoren mit
>   meinem FAT Programm mehr nötig.

Das war jetzt nicht ganz richtig :(
Fclose schreibt auf jeden Fall den Verzeichniseintrag.
Das ist nötig um die Zeit des letzten Schreibzugriffs zu speichern.

Verbesserung: Halte die Datei so lange offen wie es vertretbar ist.

Hallo Holger,

doch, hätte auch auf die Antwort von Dir noch gewartet, aber der 
Basteldrang hatte "vorrang". Hab gestern abend schon versucht da was 
dran zu ändern bzw. das auszuprobieren und Deine Routinen so anzupassen. 
Nur leider stand ich mir beim FAT auf dem Schlauch, daher die Frage an 
die Allgemeinheit.

Deine Idee mit den 11MB großen Dateien ist nicht gerade schlecht.

Leider mußte ich bei den letzten Tests mit PC und AD - Wandler via UART 
als Logger feststellen, dass zwei Karten abgeraucht sind. Beide hatten 
512MB und waren eher von der Sorte sehr alt. Aber trozdem ist es 
unschön, wenn ein großer Teil der Daten verloren geht. Daher hab ich mir 
gesagt, ich bau es jetzt mit einem AVR - braucht weniger Strom - und ich 
hab mehr Möglichkeiten da direkt Einfluß drauf zu nehmen.

Die Dateien kann ich grundsätzlich einen Tag lang offen halten, muß nur 
regelmäßig den Puffer schreiben, und das dann so alle 5 - 10 Sekunden.
Daher auch die Idee mit der Dateigröße, dann kann eigentlich passieren, 
was will, lediglich der letzte Schreibzugriff wird falsch geloggt. Was 
aber meiner Meinung nach kein wirkliches Problem darstellt, da ich ja 
aus der Verzeichnissstruktur ersehen kann, welche Daten da sind und 
welche nicht.

Es wäre für mich wichtiger, eine gültige Struktur zu haben und ein 
Handel für die Datei (=> möglich wenig Speicherverbrauch), so dass nur 
max ein Cluster Müll ist, denn die Dateigröße ist ja fix.

In wie weit ist das denn mit Deinem jetzigen Library möglich?

Gruß Marcus

PS: gern auch per PM

>Es wäre für mich wichtiger, eine gültige Struktur zu haben und ein
>Handel für die Datei (=> möglich wenig Speicherverbrauch), so dass nur
>max ein Cluster Müll ist, denn die Dateigröße ist ja fix.

>In wie weit ist das denn mit Deinem jetzigen Library möglich?

Wenn die Datei bereits existiert, alle Cluster in der FAT
eingetragen sind, sowie die Dateigröße fix ist, kannst du eigentlich
nur einen Sektor an Daten verlieren. Wenn der Strom ausfällt
können aber ganz merkwürdige Dinge passieren wenn dabei auf
die Karte geschrieben wird :( Da sollte ne Notstromversorgung
mit Stromausfallerkennung dafür sorgen das wenigstens alle
gesammelten Daten noch geschrieben werden können. Das Problem
ist dann zu erkennen wie viele Daten in der Datei gültig sind.
Z.B. mehr als vier Nullen nacheinander bedeutet Dateiende.
Oder sowas in der Art. Bei dynamischer Erweiterung der Datei
und mit FAT Buffer kann es ganz übel kommen bei Stromausfall.
Das sind halt die Tücken bei FAT. Bei NTFS oder EXT3 hast du da aber
auch die Ars..karte gezogen ;)