Re: [gentoo-embedded] file system question

[David Relson <relson@osagesoftware.com>]

Hello, All!

The many suggestions have been very helpful.  This afternoon,
'sync' was added to fstab.  No problems have been seen since.
While not conclusive, the indication is good and we're helpful.

The device in question is a medical device that continuously takes
readings, graphs them, and every 30 seconds appends a 34 byte data
record to each of two files.  It's not exactly disk intensive :->

FWIW, often the files hit by the "Stale NFS file handle" problem are
symlinks in /usr/lib.  Since _nobody_ writes that directory it's odd
that the problem often shows up there.  That's not the only place, but
seems to be the most common one.

The suggestion of separate partitions for program and data is one I
like and shall implement.  Thanks for the idea!

The power cord isn't a problem -- there's an onboard battery.  However
the power button can be pressed at any time.  'Tis something that we'll
live with.  Adding fsync() calls, in addition to 'sync' mounting, should
help.

Ciao!

David


On Tue, 30 Mar 2010 15:28:59 +0200
Karl Hiramoto wrote:

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