From: David Relson <relson@osagesoftware.com>
To: gentoo-embedded@lists.gentoo.org
Subject: Re: [gentoo-embedded] file system question
Date: Wed, 31 Mar 2010 07:30:47 -0400 [thread overview]
Message-ID: <20100331073047.19c76dc0@osage.osagesoftware.com> (raw)
In-Reply-To: <20100331112649.7365bb19@sth491dt.servo.net>
On Wed, 31 Mar 2010 11:26:49 +0200
Nebojša Ćosić 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.
> >
> > Anybody have recommendations on which file system to use and the
> > appropriate settings?
> >
> > Anybody have suggested readings so I can educate myself?
> >
> > Thank you.
> >
> > David
> >
> After having problems with EMC and usb storage, I finally fixed the
> problem with following solution:
> - data storage, in my case usb stick, has at least 2 partitions
> - second partition is without file system. It is divided in a number
> of slots, each large enough to store all of my data
> - all work is performed on data stored on ram disk
> - periodically (triggered by time and/or data change), I compress ram
> disk and dump it in a next slot on unformatted partition
> I have a small battery, which I use to do one final dump at shutdown
> time.
> On startup, I go through all of the slots in second partition,
> searching for latest uncorrupt data, and use this to populate ram
> disk. If you can live with some data loss, you don't even need
> battery backup. No matter wear leveling implementation on your
> storage, this solution works optimally.
> It works even on your directly accessible flash storage.
> Since there is no real file system on partition, there is no need for
> it's recovery - besides searching for latest and greatest set of data
> on startup
> And it is implemented as a ash script, using tar and gzip, so your
> data is actually better verified than on normal file system (the
> usual one do not actually checksum data. I don't consider jffs2 to be
> "the usual filesystem":)
> Nebojša
Wow! That's a robust solution!
prev parent reply other threads:[~2010-03-31 12:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-29 22:42 [gentoo-embedded] file system question David Relson
2010-03-30 8:40 ` Ingo Krabbe
2010-03-30 11:47 ` David Relson
2010-03-30 12:17 ` Manuel Lauss
2010-03-30 14:01 ` Relson, David
2010-03-30 13:06 ` Karl Hiramoto
2010-03-30 13:28 ` Karl Hiramoto
2010-03-30 14:14 ` Arkadi Shishlov
2010-03-30 15:07 ` Karl Hiramoto
2010-03-30 16:29 ` Arkadi Shishlov
2010-03-30 14:19 ` Peter Stuge
2010-03-30 14:28 ` Arkadi Shishlov
2010-03-31 0:44 ` David Relson
2010-03-31 6:33 ` Arkadi Shishlov
2010-03-30 13:53 ` Peter Stuge
2010-03-30 14:36 ` Ed W
2010-03-30 18:11 ` wireless
2010-03-31 1:05 ` Peter Stuge
2010-04-01 16:48 ` Ed W
2010-03-31 9:26 ` Nebojša Ćosić
2010-03-31 11:30 ` David Relson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100331073047.19c76dc0@osage.osagesoftware.com \
--to=relson@osagesoftware.com \
--cc=gentoo-embedded@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox