Svenska ElektronikForumet

OK, jag antog att det finns saker som processorn behöver avsluta
och att man inte vill påbörja en ny I/O, stänga öppna filer o.s.v
under tiden som man "stänger ner snyggt". Det blir svårt om
processorn inte ens vet om att ordinarie matning har försvunnit.

Nu så var ju frågan specifikt om SD-kortet och kanske att
skrivningarna *där* sker säkert på något sätt, men *FAT*
har nog mer med hur FAT-stacken i processorn hanterar det.

Naturligtvis beror det på många saker, vissa kan man styra, exempelvis skrivningarna från processorn till kortet, vissa kan man inte styre, dvs de interna skrivningarna i kortet.
Vill man stänga snyggt, så skall man naturligtvis se till att FAT är uppdaterad, innan processorn dör, därefter måste man se till att kortet ifråga har matning tillräckligt länge för att hinna med de interna skrivningarna.

TomasL skrev: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.

Det är både sant och falskt, och beror lite på kortets interna organisation. Oftast har du "erase blocks" som är avsevärt större än sektorstorleken, men SD använder NAND minne så erase är relativt snabb iaf.. och 32MB är väldigt ovanligt, mer vanliga är 4MB eller mindre. En intressant punkt där är att ofta har högprestanda-kort större erase block size, då det ger bättre sekventiell prestanda, men i detta fall är det kontraproduktivt.

Det leder också till att man får vara lite försiktig i hur man använder systemet. Bäst ur prestanda-synpunkt är att se till att dina partitioner är alignade till erase block-storleken, och att filerna också är det. Tyvärr är det väldigt få FAT-implementationer som stödjer detta out-of-the-box.. men inget förhindrar eg en implementation från att göra det.

Det andra man kan tänka på om man vill ha snabba skrivningar är att en skrivning i slutet av en fil (att lägga till i en logg t.ex.) resulterar i en skrivning dels av fildata, dels läs-modifiera-skriv till FATen då filens storlek (och vilka block den upptar) ändras. Därför är det bättre att preallokera ett utrymme (fseek/fallocate o.dyl beroende på vilken kod du har för FAT-hantering) och sen skriva över i "mitten" av filen. Detta gör också att din idé om att öppna ny fil var 5e sekund leder till onödigt mycket skriv-accesser då FATen måste uppdateras.

Slutligen så har (FAT iaf) inget koncept om "öppna" filer, och det skrivs ingen "EOF" till filen när den stängs utan det mest troliga (på en MCU-implementation som inte cachar FAT-uppdateringar i RAM utan gör dem direkt till kort osv) är att som "värst" förlorar du senaste skrivningen och/eller uppdateringen av filstorlek/använda block, och därmed blir den senast skrivna datan inte åtkomlig. En vettig implementation ska dock se till att du inte förlorar mer än så, även utan backup-konding (vilket dock kan vara en god idé).

Det finns ett bibliotek för NTFS men det krävs väl en hel del RAM och flash för att få plats med det.

I En fil i FAT systemet består av en pekare från listan av filer till det första klustret (4 kB?) därefter hittar man nästa kluster mha allokeringstabellen som också visar vilka block som är upptagna (FAT16 = 16-bits per klusterpekare osv-). Så det man förlorar är det klustret som skulle reserverats. Skrivs data först, och allokering efteråt så hittar man ej datat. Är det tvärtom så hittar man blocken men kanske inte alla data är på plats. Så när man endast "fyller på" en fil slutar det nog med en ofullständig sådan. Men ingen korruption egentligen. Skapar man filer är det däremot mycket värre eftersom fillistorna skall länkas samman osv.
En risk är dock när man skapar utrymme för en större lista av filer. Går det fel där kan det bli riktigt jobbigt.

Verkar dock som att om minneskortet ej slutför överföringen av ett block korrekt så blir det mest oreda eftersom det sannolikt sträcker sig över flera filsystemskluster.