Delphi Datenlogger zerstört CompactFlash (CF) Karten

[rhuber]

Hallo zusammen,nach einer langen Zeit als nur-Leser brach ich jetzt doch mal eure Hilfe!
Leider hab ich keinen besseren Bereich im Forum gefunden, deshalb versuch ich's mal hier:

Hab ein gröberes Problem mit meinem Datenlogger, der im Minutentakt ca. 10 Temperaturwerte in ein .csv-File schreib. Von 5 Datenloggern ist nach wenigen Monaten bereits bei 3 die CF-Karte defekt(Zugriffsfehler auf Logfile-Ordner,nach aut. Scan durch Win2k alle bisherigen csv-Files weg...)

Das System sieht so aus:
- Embedded-PC Alix 3.d3 (500MHz Geode LX, 256MB RAM,CF-Festplatte)
- Windows 2000 SP4 (praktisch sämtliche Schreibzugriffe unterdrückt)
- Windows und Logs laufen auf CF-Karte (SLC-Typ,sollte >1Million Schreibzugriffe ertragen)
- Alle 60s werden in Logfile neue Werte eingetragen, nach 24h wird neues Logfile erstellt (also max. 1500 Schreibzugriffe auf gleiche Datei,max.600kbyte)
- FileMon gibt jede Minute jedoch 4 Schreibzugriffe an, also max. 6000 auf selbes Logfile

Weshalb sich die CF-Karten so schnell verabschieden ist mir ein Rätsel! Sind es evtl. einfach schlechte Karten, oder liegt es an meiner suboptimalen Schreibfunktion? Ich verwende folgende:

Code:

If FileExists(fileName) Then Begin //fileName=.csv-File des aktuellen Tages
  try
    AssignFile(TxtFile, fileName); //.csv-File Laden
    Append(TxtFile);
    WriteLn(TxtFile,messwerte);    //Neue Zeile mit Messwerte in Logfile hinzufügen (ca.300 Zeichen)
    CloseFile(TxtFile);

[Nersgatt]

Flashdisks haben 10.000 bis 2.000.000 Schreibzyklen - je nach Typ, die vom Hersteller garantiert werden. Ist nunmal so, muss man einplanen.

[mkinzler]

Ich würde die Datei nicht bei jedem Schreibzugriff Öffnen/Schliessen.

[rhuber]

Hmm,die verwendeten SLC-Karten müssten >1.000.000 Schreibzyklen aushalten, im Gegensatz zu den üblichen MLC (>10.000 bis >100.000). Hätte daher eigentlich ausreichend Reserven...

Ok,also am Besten bei Programmstart Logfile öffnen, und dann erst beim Beenden wieder schliessen? Könne ich denn so Schreibzugriffe sparen? Lesezugriffe sollen ja unproblematisch sein.

Danke!

EDIT: Wird etwa erst mit dem Aufruf von CloseFile() geschrieben, solange ich nur WriteLn()ausführe bleibt alles im RAM??

[Medium]

Zitat:

Zitat von rhuber (Beitrag 1182461)

EDIT: Wird etwa erst mit dem Aufruf von CloseFile() geschrieben, solange ich nur WriteLn()ausführe bleibt alles im RAM??

Das kommt auf die Einstellungen von Windows bzw. des Schreib-Caches an. Manche Controller cachen ebenfalls. Bis kein Flush oder Close ausgeführt ist, kann man daher allgemein erstmal nur sagen: Die Daten könnten schon geschrieben sein, vielleicht auch nicht.

[himitsu]

Was loggt denn der Datenlogger?
Nur Zugriffe auf DateiAPIs, die Zugriffe auf den Datenträgercontroler, oder die realen Zugriffe auf die Speicherzellen?


Jupp, beim Öffnen wird das Ende der Datei aisgelesen, dann nochmal darin nach einem "Dateiendezeichen" gesucht, der Zeiger auf das Ende gesett und wenn du dann die Datei schleißt, wird natürlich der komplette Cluster neu beschrieben und womöglich noch ein Annpassung im Volume Bitmap und dann auch noch die Anpassung der Dateigröße und des Änderungsdatums im Verteichnis und womöglich auch noch in allen übergeordneten Verzeichnissen. (Letzteres wurde in Windows 7 mal abgeschafft, vermutlich zum Zeitgewinn und in Hinblick auf SSDs)

Wie stabil läuft denn das System und wie wichtig sind die geloggten Daten?
Erstmal die Datei nicht ständig öffnen/schließen, dann auf Streams ausweichen, welche keine eigene Cache implementieren, so wie so alten Dateifunktionen, womit dann beim Absturz des Programms keine Daten verloren gehen.
Je nach Schreibverhalten und Speicherauslastung werden hier, über die WindowsFileCache, wenn man die Datei nicht ständig schließt, auch die physischen Dateiuzugriffe verringert.

Oder wenn das Schreiben nicht so wichtig ist, dann mit einer größeren eigenen Cache zwischenspeichern und die Dateizugriffe minimieren.

Sind die Daten ganz wichtig, dann müßte man sogar noch die Schreibcache vom Windows und des Datenträgers ausschalten, was aber die realen Zugriffe noch erhöht.

[rhuber]

Vielen Dank für eure Antworten!!!

Das mit dem Schreibcache hab ich gar nicht überlegt; FileMon (zur Überwachung der CF-Zugriffe) loggt ziemlich sicher nur die Datei APIs und nicht die realen Zugriffe...

Das System läuft extrem stabil (im Labor seit über einem Jahr), startet sich jeweils um Mitternacht selbst neu und schreibt die Logfiles des letzten Tages auf einen USB-Stick.
Es ist nicht tragisch wenn mal ein Tag verloren geht, viel wichtiger ist dass das System nicht hängen bleibt (was es aber im Falle eines CF-Defekts tut,dann hängt nämlich mein AutoReboot-Tool ->gemacht mit ExitWindowsEx,gibts da eine "Hardcore-Variante"?).

Nun, ich kenne mich leider mit den Datei APIs nicht sehr gut aus; gibts eine einfache Alternative zu "WriteLn()", mit welcher vorerst noch nichts geschrieben wird? Also zuerst nur in den RAM speichern und erst später die Änderungen schreiben,ohne zuviel am Code ändern zu müssen?

[Klaus01]

Zitat:

Zitat von rhuber (Beitrag 1182486)

gibts eine einfache Alternative zu "WriteLn()", mit welcher vorerst noch nichts geschrieben wird? Also zuerst nur in den RAM speichern und erst später die Änderungen schreiben,ohne zuviel am Code ändern zu müssen?

.. die TStringList
mit der Methode saveToFile zu speichern.

Die LogDaten im ram zu halten nützt natürlich nichts, wenn das Programm abstürzt.


nicht schön ...

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

uses
  SysUtils, classes;
var
  sl : TStringList;

procedure writeLn(s: ansiString);
begin
  sl.add(s);
end;

begin

  { TODO -oUser -cConsole Main : Insert code here }

  sl := TStringList.Create;
  try
    writeLn('test');
    sl.SaveToFile('filePath+fileName');
  finally
    sl.Free;
  end;
end.

:wink:
Grüße
Klaus

[Medium]

In dem Fall würde ich auch fast sagen: Logs in StringListen, und speichern bei Programmende, Ausnahmefehlern die sich früh genug abfischen lassen und zu einem definierten Zeitpunkt. Und zwar direkt auf den Stick, dann ist die CF Karte überhaupt nicht mehr an Bord.
Hat natürlich den Nachteil, dass Logs flöten gehen, wenn mal einer mutwillig den Stecker zieht, aber die Hardware lässt an der Stelle dann einfach nicht arg viel Spiel für Datensicherheit. Im Zweifel könnte man noch an einen externen DB Server denken, der dann z.B. via WLAN alles schön in Tabellen speichert.

[divBy0]

Es ist ja auch möglich die Stringlist alle 2 Stunden oder so mal zu speichern.