| 1 |
On 03/30/2010 12:42 AM, David Relson wrote: |
| 2 |
> G'day, |
| 3 |
> |
| 4 |
> I'm porting the software for an embedded medical device from DOS to |
| 5 |
> Linux and am wondering which file systems are appropriate and which are |
| 6 |
> not. The device's mass storage is a Disk-on-Module solid state flash |
| 7 |
> drive. Data is presently written at approx 100 bytes every 30 seconds |
| 8 |
> but that might change to 100 bytes every second. The device has a |
| 9 |
> watchdog (recently activated) and during today's session it was |
| 10 |
> triggered and wiped out my file system. |
| 11 |
> |
| 12 |
It sounds like some kind of data logging application. If this is the |
| 13 |
case what i would do is. |
| 14 |
|
| 15 |
1. Mount read only a partition that contains the main system, to ensure |
| 16 |
you can always boot and to avoid damage to the systems file |
| 17 |
|
| 18 |
2. Mount read/write the partition that data gets written to. On boot |
| 19 |
you can detect errors in this partition and reformat it if is totally |
| 20 |
hosed. |
| 21 |
|
| 22 |
3. In your application call fsync() on the file and perhaps the |
| 23 |
directory after the writes to make sure the data gets to the flash. If |
| 24 |
you are in fact logging, rotate your logs files so after they are X size |
| 25 |
write to a new file. Files that are most likely to be damaged are ones |
| 26 |
that are opened and being written to the moment the power cord gets yanked. |
| 27 |
|
| 28 |
As Manual said, using the 'sync' option may help. Also see "man mount" |
| 29 |
and /usr/src/linux/Documentation/filesystems/ext3.txt |
| 30 |
|
| 31 |
Other options the improve reliability are data=journal and barrier=1 |
| 32 |
|
| 33 |
|
| 34 |
I've used ext3 and riserfs on CompactFlash but neither seems to be 100% |
| 35 |
error proof. I've wanted to try NILFS2 but haven't done it yet. |
| 36 |
|
| 37 |
-- |
| 38 |
Karl |
Archives