| 1 |
On Wed, 31 Mar 2010 11:26:49 +0200 |
| 2 |
Nebojša Ćosić wrote: |
| 3 |
|
| 4 |
> > G'day, |
| 5 |
> > |
| 6 |
> > I'm porting the software for an embedded medical device from DOS to |
| 7 |
> > Linux and am wondering which file systems are appropriate and which |
| 8 |
> > are not. The device's mass storage is a Disk-on-Module solid state |
| 9 |
> > flash drive. Data is presently written at approx 100 bytes every |
| 10 |
> > 30 seconds but that might change to 100 bytes every second. The |
| 11 |
> > device has a watchdog (recently activated) and during today's |
| 12 |
> > session it was triggered and wiped out my file system. |
| 13 |
> > |
| 14 |
> > Anybody have recommendations on which file system to use and the |
| 15 |
> > appropriate settings? |
| 16 |
> > |
| 17 |
> > Anybody have suggested readings so I can educate myself? |
| 18 |
> > |
| 19 |
> > Thank you. |
| 20 |
> > |
| 21 |
> > David |
| 22 |
> > |
| 23 |
> After having problems with EMC and usb storage, I finally fixed the |
| 24 |
> problem with following solution: |
| 25 |
> - data storage, in my case usb stick, has at least 2 partitions |
| 26 |
> - second partition is without file system. It is divided in a number |
| 27 |
> of slots, each large enough to store all of my data |
| 28 |
> - all work is performed on data stored on ram disk |
| 29 |
> - periodically (triggered by time and/or data change), I compress ram |
| 30 |
> disk and dump it in a next slot on unformatted partition |
| 31 |
> I have a small battery, which I use to do one final dump at shutdown |
| 32 |
> time. |
| 33 |
> On startup, I go through all of the slots in second partition, |
| 34 |
> searching for latest uncorrupt data, and use this to populate ram |
| 35 |
> disk. If you can live with some data loss, you don't even need |
| 36 |
> battery backup. No matter wear leveling implementation on your |
| 37 |
> storage, this solution works optimally. |
| 38 |
> It works even on your directly accessible flash storage. |
| 39 |
> Since there is no real file system on partition, there is no need for |
| 40 |
> it's recovery - besides searching for latest and greatest set of data |
| 41 |
> on startup |
| 42 |
> And it is implemented as a ash script, using tar and gzip, so your |
| 43 |
> data is actually better verified than on normal file system (the |
| 44 |
> usual one do not actually checksum data. I don't consider jffs2 to be |
| 45 |
> "the usual filesystem":) |
| 46 |
> Nebojša |
| 47 |
|
| 48 |
Wow! That's a robust solution! |
Archives