Svenska ElektronikForumet

Hej, håller på med ett projekt där vi behöver lagra data på ett SD kort. Vi kommer att ha ett FAT filsystem på kortet, vad jag undrar är helt enkelt, vad händer med den öppna filen vid ett strömavbrott? Vad händer med övriga filer? Blir endast den öppna filen korrupt?

/MVH Björn

Beror helt och hållet vad som sker vid avbrottet, eftersom dessa kort endast kan skrivas i klumpar är det mycket stor risk att allt blir korrupt (oavsett filsystem)

En fil kan rent faktisk inte vara "öppen". Filsystemets variabler i µC'n kan vara i beredskap till att skriva en buffer som kanske inte är full än eller den kan ha skrivit och vara klar för nästa klump.

Håller µC'n inte på att skriva när avbrottet sker är det mest sannolikt att det inte sker värst mycket med existerande filer och den "öppna" filen kan vara delvis sparad.

Men då man inte kan beställa när avbrott ska ske måste man ha lite backup-energi som håller strömmen kvar under en skrivning, sedan kan den stänga ner. Utan denna back-up kommer situationer ganska säkert att uppstå där hela FAT'en är ganska förstörd vilket alltså betyder att alla/många data förstörs.

Ok, finns det något sätt att minimera chansen för att all data blir förstörd? Vad jag hade tänkt göra var att spara sensor data i 5 sekunders block som filer, så vid strömavbrott hoppades jag på att bara den sista filen skulle bli korrupt... Vilka lösningar brukar användas i sådana fall som detta?

Brukar man kunna få ut ett par instruktioner när microcontrollern förlorar strömmen? Isåfall skulle det kanske räcka med att kolla om man har ström och skriva EOF ifall man inte har det. Eller vore det bättre att inte skriva någonting alls för att inte riskera att det blir fel?

Tack för svaren

Du kan ju mäta ingående spänning. Försvinner den stänger picen filen och slutför det den bör medans den drar strömmen som finns i en konding som sitter närmare picen. Kräver en diod eller liknande emellan så inte strömmen rusar bakåt.

Jag funderar också (som Icecap) på det här med begreppet "öppen fil".
Är det något som filsystemet på själva SD-kortet alls känner till?
D.v.s, om man tittar efter (t.ex) ett strömavbrott, går det från kortet
enbart att avgöra att en fil var "öppen" när avbrottet inträffade?
Finns det något i FAT-strukturen som markerar en fil som "öppen"?

Min personliga uppfattning är att "öppen" är ett begrepp som programvaran
känner till. Någonstans i I/O rutinerna eller i drivers finns det flaggor som
markerar olika filer som t.ex "öppna" och det används t.ex om en annan
process/tråd försöker öppna samma fil. Men disken vet inget om det, den
ser bara att någon skriver och läser olika block hit och dit. Disken i sig vet
inte heller någonting om FAT eller liknande, allt är bara diskblock.

Så, om mina gissningar stämmer, beror konsekvenserna av ett elavbrott helt
på vad det var som pågick når avbrottet inträffade. Ett man bara har öppnat
en fil betyder ingenting, själva "öppnandet" ändrar inget på disken (förrutsatt
att det gäller att öppna en befintlig fil).

Om man öppnar en *ny* fil så kommer det att skriva lite data i katalogstrukturen.
Beroende på när avbrottet inträffat så kan det eventuellt göra katalogstrukturen
korrupt, jag vet inte hur säkra dessa uppdateringar är, i idealfallet så ska de
ju göras på ett sådant sätt att det "värsta" som kan hända är att filen inte
skapas. I inget fall *borde* det påverka även andra delar av katalogstrukturen.
Men där är jag lite osäker. Som Icecap sa, vill man vara säker så har man
batteribackup som klarar att slutföra den aktiva I/O'n innan man stänger ner.

Om man har öppnat en (ny) fil och håller på att skriva data till den, så sker det
ju blockvis. Och vid varje I/O så uppdatteras viss info som EOF pakare o.s.v.
Även i detta fall så *borde* det värsta som kan inträffa vara att man tappar
det senast blocket. Dels, så klart, ett eventuellt block som enbart har skrivits
i en (minnes-) buffert men inte till disk, men ä'ven en block där själva datat har
skrivits till disk men EOF pekaren inte har hunnit uppdateras. I båda fallan "tappar"
men det aktuella blocket. Men i inget fall *borde* det ha katastrofala följder
som gör hela disken korrupt.

Sen så kan det ju vara så att man buffrar data i minnet et tag innan man har ett
helt block att skriva. Om detta är kritiskt så får man ha en lösning som tar hand
om det, t.ex batteribackup. Eller att man har ett extra buffertminne som klarar ett
strömavbrott, FRAM eller liknande, som man sedan kopierar till SD-kortet då och då
på ett sådant sätt att man efter ett strömavbrott kan återuppta (eller starta om)
kopieringen till SD-kortet.

Med öppen fil menade jag endast det som programmet ser som öppen dvs den har inte skrivit någon EOF än. Förslaget med en buffer som har batteri var intressant, ska kolla lite på det, men skulle tro att det kommer bli att kolla om det fortfarande finns ström och agera utifrån det. Ska nog sätta en kondning där också isåfall som danielr112 föreslog.

Tack för alla svaren

/MVH Björn

> Vad jag hade tänkt göra var att spara sensor data i 5 sekunders block som filer...

Alltså en ny FAT fil var 5'te sekund? Det låter som en massa filer. Jag ser inte
att det skull vara något problem att skriva till samma fil, jag misstänker att du
i alla fall bara tappar slutet på filen, eller den senaste (ej avslutade) skrivningen.

> Brukar man kunna få ut ett par instruktioner när microcontrollern förlorar strömmen?

Från ett par till ett par hundra beroende på hastighet, hur mycket glättningskondingar
det sitter i "kedjan" samt vad mer som drar ström. Sen finns det ju lösningar med en
"supper-cap" som kan förse t.ex enbart processor och SD-kort med ström i 1-2
sekunder, tillräckligt för att "stänga snyggt" efter sig. Det finns även speciella
"CPU-monitor" kretsar som övervakar matningen, kopplar in reservmatningen
och skickar ett "interrupt" till processorn.

FAT är egentligen nog det sämsta filsystemet som används i nämnvärd utsträckning. Det används enbart för att det används, så att säga, d.v.s. "alla" använder det för att "alla andra" använder det.

Det bästa för att klara oväntade strömavbrott är journalfilsystem. Exempelvis NTFS i Windows (NT, 2000, XP, Vista, 7 o.s.v., men INTE DOS/Win 3.x/95/98/ME), Ext3/4 i Linux, eller för den som vill mörda sin fru ReiserFS i Linux. (Snubben som skapade ReiserFS, numera väl i princip överkört av Ext3/4, åkte dit för att ha mördat sin fru...). Journalfilsystem funkar i princip så att i en logg skrivs först "nu tänker jag göra den här ändringen", sen görs ändringen, och sist fylls loggen på med "nu har jag gjort den här ändringen". Vid uppstart så tittar man i loggen och ser om det ligger nåt "nu tänker jag..." som inte matchas av en "nu har jag...", och i så fall gör man lämpliga repareringar.

Det näst bästa är filsystem som åtminstone sätter en "dirty bit" före annat skrivs, och när allt är färdigskrivet släcker den bit'en. Vid uppstart så tittar man efter den bit'en och om den är satt så körs en kontroll av filsystemet innan det används. Det förutsätter att man inte har en stendum flashkontroller, annars skrivs väl just den platsen i flashkretsarna sönder, men det borde inte vara nåt problem med SD-kort.

För att emulera det här på FAT så skulle man antingen kunna ha en speciell "flaggfil" som innehåller en enda byte och där denna byte talar om "dirty: ja/nej", eller så kan man kanske tänka sig att man först skapar en "kraschat.txt" före man skriver nåt mer, och efter man skrivit klart raderar "kraschat.txt". Om filen "kraschat.txt" finns vid uppstart så behöver motsvarande chkdsk/scandisk köras.


Rent allmänt så kan man å andra sidan komma långt om man skriver FAT-drivern så att det bara "skrivs stängda filer", d.v.s. i varje skrivning så uppdateras allt på sd-kortet så att det ser ut som om filen är färdigskriven. Filen kan fortfarande vara öppen sett från applikationens synvinkel, och varje gång applikationen skriver till filen så gör filsystemkoden så att den öpnnar filen, skriver och stänger filen, varje gång.

Om man vill minska antalet skrivningar så kan man göra så att man en gång för alla skapar en fil som är max storlek (det som är minst av antingen 2GB eller kortets storlek) och sedan fyller i data i den filen efter att man vid skapandet fyllt den med t.ex. nollor, mellanslag eller ctrl-z ("dos") eller ctrl-d ("unix"). Då kan iaf filsystemet i sig inte bli korrupt av att strömmen bryts mitt i en skrivning, förutsatt att det inte blir knas på grund av vad nu flashkontrollern gör.

Filsystemet i sig är rätt ointressant, med tanke på hur dessa kort fungerar, även om man bara skriver en sektor (512B), så skriver kortet typ 32M, sker denna 32M skrivning mitt i ett spänningsbortfall, så kan vad som helst hända.

NTFS vore bra, men hur implementerar jag det på en microcontroller, har inte sett någon specification på det. Hinner inte heller koda det själv, så skulle behöva ett färdigt library isåfall. FAT finns bra dokumenterat och ett antal libraries att välja på.

Finns mig veterligen inga libs för NTFS, personligen tycker jag att det är overkill, och inte speciellt lämpligt i en uc-app.
Finns inga nackdelar med FAT, oavsett filsystem får du samma problem när matningen försvinner, ett mer avancerat filsystem gör det garanterat svårare att återskapa efter ett eventuellt haveri.

Vad jag skulle göra är att detektera eventuellt spänningsbortfall, tillräckligt med backup-kondingar för att se till att kortet stänger ned snyggt.
Det handlar inte om många ms.
Tror inte du behöver känna av spänningsbortfall ens, en diod i serie med matningen, samt en konding med lämplig kapacitans som matar kortet, du måste naturligtvis veta vad kortet drar, för att beräkna lämplig storlek, samt hur lång tid kortet behöver för att skriva färdigt.

> ...men hur implementerar jag det på en microcontroller?

Just precis, tänkte också på det när det började snackas om journal-filsystem.
Säkert skit-bra (jag är inte övertygad), men ganska out-of-context och
det är en annan diskussion

> Tror inte du behöver känna av spänningsbortfall ens,

Om man inte gör det så är all backup helt bortkastad.
Spänningen kommer i alla fall att (plötstligt) försvinna.
Självklart måste det finnas något som signalerar till
processorn att "nu kör vi på kondingen!" eller liknande.

Nja, inte nödvändigtvis, eftersom de interna skrivningarna i kortet är autonoma, men man kanske vill hålla processorn vid liv, så den skriver färdigt till kortet.