ts-7000
[Top] [All Lists]

Re: [ts-7000] Hardening a TS-5700

To:
Subject: Re: [ts-7000] Hardening a TS-5700
From: Andy Warner <>
Date: Wed, 6 Apr 2005 09:08:06 -0500
Jim Jackson wrote:
> [...]
> > Although slightly off-topic as it's not a 7000 series, hopefully this
> > is a more generic question.  I would like to know if anyone can point
> > me to information on how to "harden" a Linux implementation so it can
> > handle unscheduled power cycles a bit better.  I'm toying with the
> > idea of trying to tar the entire filesystem and loading it into a
> > RAMDISK on bootup or trying to migrate to a journalling filesystem.
> 
> I've been given this advice in the past, Don't use journalling file
> systems with flash based filestore like cfdisk - far too many writes.

Jim speaks the truth here, though there are filesystems designed
to work directly on flash (e.g. jff2, yaffs) which will be
more friendly.

A lot will depend on your requirements (as usual.)

A very common and effective approach is to boot the
system from read-only media, this can be either a
ext2/romfs/cramfs image that resides on a /boot style
partition (if it is ext2, then the resulting / filesystem
after the image is copied to a ramdisk can be read/write),
a romfs/squashfs/cramfs image stored directly in a flash
partition, or even a romfs/squashfs image that exists as
a section of the bootable linux elf file. The key attribute
to all these is that the original filesystem image is
read-only, so you just load it on boot and off you go.

If you run from one of the read-only filesystems, you will
want to have a disposible r/w file system too (usually a
ramdisk.) Mechanisms like these are used by zillions of
embedded linux devices every day. 

The complications arise when you start storing data
as a result of system operation, there tend to
be two classes of data you will need to write:

1. occasional writes (e.g. config changes) - these are
   often handled by having a r/w flash partition (e.g. jff2/yaffs
   or even mount/umounting an ext2 partition) that the data
   is written to. The only special handling required is
   knowing what to do when the data is corrupted due to
   power failure during a write (there are ways to mitigate this
   too.)

2. frequent writes as a result of normal device operation.
   For example, if the purpose of the device is to be a data
   logger, then you need to find a way to write data that meets
   your requirements - this is where the easy answers run out and
   it all depends on your particular requirements. Many embedded
   Linux devices never have to deal with this issue.

-- 


Andy Warner             Voice: (612) 801-8549   Fax: (208) 575-5634


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/ts-7000/

<*> To unsubscribe from this group, send an email to:
    

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 



<Prev in Thread] Current Thread [Next in Thread>
Admin

Disclaimer: Neither Andrew Taylor nor the University of NSW School of Computer and Engineering take any responsibility for the contents of this archive. It is purely a compilation of material sent by many people to the birding-aus mailing list. It has not been checked for accuracy nor its content verified in any way. If you wish to get material removed from the archive or have other queries about the archive e-mail Andrew Taylor at this address: andrewt@cse.unsw.EDU.AU