On 13 Jul 2008, at 13:50 , Jim Jackson wrote:
>
>
>> The selection of the 7400 was based on having the resources provided
>> by a full debian distribution (not TSLinxu). So if
>> I can't reliably boot from SD Card given inadvertent power cycles,
>> then its not a viable platform for me.
>
> This seems like a non-seuqitor. Do you think that a Debian Linux
> distribution would give you ability to reliably boot given
> inadvertant power cycles? Because it won't. Most "normal" linux
> setups barf if randomly restarted, especially in restarted during
> file system repair. And I doubt if any writable filesystem can
> guarantee NOT to fail under the conditions you indicate.
I am newbie using embedded linux. I am just trying to figure out how
other's manage the problem.
It seems though that you have provided a key suggestion. I was not
sure if it was reasonable to mount the root file system read only.
Apparently from you suggestion below, it is.
By reliable I don't mean foolproof. Just recoverable.
If "barf" means the file system is unrepairable then it must be a
really bad idea to run fsck automatically on boot for an embedded
linux system =).
Its just thats the way the distribution was set up out of the box so I
didn't know any better.
>
> It sounds like you need battery backup, and main power detection,
> so that you can arrange to have long enough to shut down cleanly.
Is that what most do? I don't see much evidence of anyone using
battery backup for TS 7XXX embedded linux devices.
>
> Having the main OS partititon(s) read only with volatile ramdisks
> for the variable data is probably only foolproof way I can think of,
> without extra hardware. If you have networik connectivity, you could
> use nfs, with sync writes, to a server for storing any variable data.
Your suggestion is what I was looking for. I haven't tried running
with the the root file system read only. I will have to figure
out how to do that and fix all the stuff that is likely to complain
when I do. Is a read only root fs common practice to avoid
corruption? I could still mount the root read/write for development
when needed and have the advantages of a full debian distribution but
mount it read only for deployment. I suspect that I do this by
modifying the fastboot linuxrc script and other stuff as well.
NFS upon deployment is not an option.
For data, I could put, log data on another partition from the root
file system and even store
stuff redundantly. Its ok if I lose some log data just not all of it.
The inadvertent power cycles rarely happen when the application is
running a mission, but happen frequently during configuration and
setup of other components. So its when the system is just sitting
there booted but
not doing anything that its most likely to suffer power cycles. The
whole system is battery powered, it just that the system is composed
of multiple embedded
devices and every time someone wants to do maintenance or anything on
any device they power the system down. There is no mechanism for
telling devices
in advance that a power down is about to occur. Everything else on the
system is robust to this sort of behavior.
I am not sure how a ram disk helps because you lose everything on
power loss? Is it just to minimize the number of write cycles? It
seems to me that this has more to do with lifespan of the flash. Even
with a ram disk you have to write to flash sometime if you want to
save the data.
Do you use the ram disk to store things like dmesg boot logs, and /
proc that are rebuilt anyway on the next boot?
In reading up on JFS it appears that you can lose the tail end of the
data but the file system is still intact. Thats an acceptable level of
failure for log data since its very rare to lose power during a
mission. So it seems like a good idea to use JFS for the log data
partition.
Thank you very much for the feedback. It gives me someplace to start.
**************************************************************************************************
Samuel M. Smith Ph.D.
Founder
ProSapien LLC
2966 Fort Hill Road, Eagle Mountain Utah 84005-4108 USA
1.801.766.3527 x112 (voice) 1.801.766.3528 (fax)
1.801.592.8230 (mobile)
mailto: (email)
http://www.prosapien.com/ (web)
*************************************************************************************************
NOTICE: This electronic mail message, together with any attachments
contains information
that may be copyrighted, confidential, proprietary, and/or legally
privileged of and/or by
ProSapien LLC. This electronic mail message is intended solely for
the use of
the individual or entity originally named as the intended recipient.
If you are not the intended
recipient, and have received this message in error, please return
immediately this message
by email and delete it.
***************************************************************************************************
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|