1 |
Hello, All! |
2 |
|
3 |
The many suggestions have been very helpful. This afternoon, |
4 |
'sync' was added to fstab. No problems have been seen since. |
5 |
While not conclusive, the indication is good and we're helpful. |
6 |
|
7 |
The device in question is a medical device that continuously takes |
8 |
readings, graphs them, and every 30 seconds appends a 34 byte data |
9 |
record to each of two files. It's not exactly disk intensive :-> |
10 |
|
11 |
FWIW, often the files hit by the "Stale NFS file handle" problem are |
12 |
symlinks in /usr/lib. Since _nobody_ writes that directory it's odd |
13 |
that the problem often shows up there. That's not the only place, but |
14 |
seems to be the most common one. |
15 |
|
16 |
The suggestion of separate partitions for program and data is one I |
17 |
like and shall implement. Thanks for the idea! |
18 |
|
19 |
The power cord isn't a problem -- there's an onboard battery. However |
20 |
the power button can be pressed at any time. 'Tis something that we'll |
21 |
live with. Adding fsync() calls, in addition to 'sync' mounting, should |
22 |
help. |
23 |
|
24 |
Ciao! |
25 |
|
26 |
David |
27 |
|
28 |
|
29 |
On Tue, 30 Mar 2010 15:28:59 +0200 |
30 |
Karl Hiramoto wrote: |
31 |
|
32 |
> On 03/30/2010 12:42 AM, David Relson wrote: |
33 |
> > G'day, |
34 |
> > |
35 |
> > I'm porting the software for an embedded medical device from DOS to |
36 |
> > Linux and am wondering which file systems are appropriate and which |
37 |
> > are not. The device's mass storage is a Disk-on-Module solid state |
38 |
> > flash drive. Data is presently written at approx 100 bytes every |
39 |
> > 30 seconds but that might change to 100 bytes every second. The |
40 |
> > device has a watchdog (recently activated) and during today's |
41 |
> > session it was triggered and wiped out my file system. |
42 |
> > |
43 |
> It sounds like some kind of data logging application. If this is |
44 |
> the case what i would do is. |
45 |
> |
46 |
> 1. Mount read only a partition that contains the main system, to |
47 |
> ensure you can always boot and to avoid damage to the systems file |
48 |
> |
49 |
> 2. Mount read/write the partition that data gets written to. On boot |
50 |
> you can detect errors in this partition and reformat it if is totally |
51 |
> hosed. |
52 |
> |
53 |
> 3. In your application call fsync() on the file and perhaps the |
54 |
> directory after the writes to make sure the data gets to the flash. |
55 |
> If you are in fact logging, rotate your logs files so after they are |
56 |
> X size write to a new file. Files that are most likely to be |
57 |
> damaged are ones that are opened and being written to the moment the |
58 |
> power cord gets yanked. |
59 |
> |
60 |
> As Manual said, using the 'sync' option may help. Also see "man |
61 |
> mount" and /usr/src/linux/Documentation/filesystems/ext3.txt |
62 |
> |
63 |
> Other options the improve reliability are data=journal and barrier=1 |
64 |
> |
65 |
> |
66 |
> I've used ext3 and riserfs on CompactFlash but neither seems to be |
67 |
> 100% error proof. I've wanted to try NILFS2 but haven't done it yet. |
68 |
> |
69 |
> -- |
70 |
> Karl |
71 |
> |
72 |
> |
73 |
> |