Guys when should I update files when working with them. Like it would be very wasteful to write data back to the storage media everytime I do a putc.
WM.
The question should be made clearere, I'm looking advise on when to update files that are opened. For example, when using putc into a file using FAT32.
I dont run a version control program like I did when I wrote code for money, although I have one in a box I have never installed. What I do these days is create a new project when I am going to do some major changes to an existing project and append a version identifier to the project name. That way I can always get back to a working project if the major changes I have made result in something that wont compile or run. For smaller changes I always seem to be able to get back to something that works. Instead of deleting changed code in a file I comment it out so I can get back to it when things break. I store all my files in dropbox so I have backup of everything current on 3 laptops and the cloud, and I rarely delete anything. Since it is just code it doesn't take up that much space. This system has been working for me for a number of years now.
Sorry, I'll to refine the question to make it clearer. I've designed a fat32 filing system and I'm wondering when I should update files that I writing to.
depends on the use case. It's a tradeoff between filesystem integrity, available memory and performance. One assumption might be to flush everything to disk on a file close. Then there's how much you cache, how you flush the cache and so on.
some common use cases:
write a lot of data infrequently - the overhead of the file open/close is usually tolerable.
write a little bit of data frequently - file open/close usually imposes a significant overhead, so caching even a sector might be wise. Then there's the issue of when you update the fat and directory.
For devices like Android tablets that run off a battery and the battery is managed, then you can cache more aggressively as you have fair warning of when the system is forced to shutdown and can flush the cache back to storage. For systems without batteries, there's the issue of the system being powered off at random intervals. Then it becomes a balance of data integrity vs caching/performance.
I think fatFs puts it back on the coder - minimal caching and you need to close the file to ensure filesystem integrity. This has the advantage of simple code and minimal ram usage.
Depends, Fianawarrior, on how much the data matters to you. What's it worth?
Like all engineering, it's a tradeoff. If every character is vitally important, then yes, write every putc and live with swiftly-trashed storage. It's only money and time to replace it. If it's not that important, write every couple of hours, and if there's a power (or other) failure somewhere in there live with the fact that you just lost a couple hours data. There is no 'magic number'.
There's other helpful ideas, like backup power that detects a power failure and as quickly as it can dumps what it hasn't stored yet to permanent storage, but that also costs more money and is still not infallible.
How much money (and hassle) do you wish to spend making sure every item is saved?
S.
Engineering is the art of doing for a shilling what anyone can do for a pound.
Attributed to Nevil Shute Norway, more famous under his pen name, "Nevil Shute".
It's a tradeoff. If you have RAM then buffer as much activity as you can then do one big burst write when you are happy the data is accumulated and ready to flush (like buffering an entire AU then just flushing as you hit the AU boundary). HOWEVER if you are caching stuff in RAM and there's a power fail (or someone ejects the storage media or something) then the amount that never got written to the disk is larger than if you just had a single sector buffer or something.
FatFs works with a single sector buffer. So if you are doing lots of putc()s it's when you do the 513th that the previous buffered sector is flushed to disk.
In Windows/Linux on the other hand these work on systems with gazillions of bytes so they may have MB sized disk caches. (but they are probably also doing the stuff to flush the buffers as a DMA process in a separate task to the buffer filling too!)
We need to talk to the powers that be on this forum (Hi, clawson!) and ask if we can get another button, like the Bold, Italic, underline, and strikethough buttons that when we click on it it just puts into the post, "It's a tradeoff". S.
It's a tradeoff
Indeed, it's a tradeoff.
Is that like a bakeoff?
lol
Is that like a bakeoff?
I guess it's when the bakers are professional - so doing it by way of trade ... ?
Boy, my comment sure makes me look like a boob, but everyone here knows that already. It's my birthday in a couple of days. I will be 70. That's my excuse. I'm old and getting senile. Lots of people die in their 70's. My doctor is always shocked when I get blood work done once a year. All my numbers are perfect.
