From: Ed W <lists@wildgooses.com>
To: gentoo-embedded@lists.gentoo.org
Subject: Re: [gentoo-embedded] file system question
Date: Tue, 30 Mar 2010 15:36:49 +0100 [thread overview]
Message-ID: <4BB20C81.5010102@wildgooses.com> (raw)
In-Reply-To: <20100329184215.539920eb@osage.osagesoftware.com>
On 29/03/2010 23:42, 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.
>
> Anybody have recommendations on which file system to use and the
> appropriate settings?
>
> Anybody have suggested readings so I can educate myself?
>
In addition to what everyone else has already noted you really need to
state your tradeoff between lifetime of the flash cards and minimising
the risk of loosing data. Fundamentally you can buffer the data and
write less frequently to the device (your device has a finite number of
writes before it perishes), or you can write more frequently, hence less
risk of dataloss
Any journal'ed fs is *supposed* to be reasonably robust against disk
crashes during writes, but often there are layered levels of safety, eg
ext3 has three write modes depending how you want to trade safety for
speed (hint newest defaults are probably not optimal if your data is
very precious)
I think one of the issues you will face is that whilst a journaling fs
with appropriate options should be very safe against you flipping the
power off whenever you feel like, long term your failure mode with flash
appears to be random files disappearing and getting corrupted - the wear
levelling appears to mean that unrelated files can get trashed as the
flash shuffles data around to maximise wear levels until the card
basically pretty much gives up? I haven't experienced this yet...
I guess just plan ahead for this.
Good luck
Ed W
next prev parent reply other threads:[~2010-03-30 15:10 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 [this message]
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
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=4BB20C81.5010102@wildgooses.com \
--to=lists@wildgooses.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