RE: FreeBSD's embedded agenda

From: James Mansion <james_at_wgold.demon.co.uk>
Date: Sat, 27 May 2006 13:27:25 +0100
>On the other hand, if you're building an embedded system for a lunar
>lander for Apollo 13, or a real time control system, then I would argue
>that you should squeeze in as many engineering cycles as you can,
>because a dependable system is only as robust as its weakest link.

I disagree.  What you are building does not change the truism.  All that
happens is that 'good enough' has a more stringent definition - that's
the whole point.

>Having said that, I don't think James initially knew that a CF does
>wear-levelling - so perhaps he doesn't have that much direct experience
>with these devices.

I thought I made the point that I believe many do.  But once again the
issue here is not whether the do or not, its whether wear-levelling
is a requirement.  A modern flash device will handle many updates
per sector, and a device that runs from flash is presumably intended
not to be update-heavy.  So long as you don't perform unnecessary
housekeeping IO's such as flushing access times frequently, then
you'll generally be fine.  Do the maths.  Systems tend to update
/tmp and /var quite a lot, even then if you can avoid flushing the
sectors with directories and delaying them, then you can get
to a the point where the design life is not limited by the flash
device.

>Putting on my selfish hat I'd love to have a filesystem that could run
>directly on raw flash.

Why?  Lets remember we're talking about an embedded system that can be
sensibly implemented with a general purpose OS.  I'd put it to you that
normally where this is very desirable, its because the run rate is
quite low so the project overall is very sensitive to ease and cost of
development.  But if the run rate is low, then you also need to consider
what hardware will be available in volume at go-live, and CF-to-IDE
is very cheap now in conjunction with system-on-a-chip designs for
set top boxes.  For big bulk, we have PIC, Atmel, Rabbit, and assorted
80186 designs (including one very cute thing I saw built into an
ethernet PHY)

If you really must wear level, then why not access through a layer that
divides the whole CF into 'n' partitions, uses 'n-1' of them, re-
presents the 'n-1' through a RAID0-like mapping, and allows the logical
sector 0 in each partition to be changed (with wrap-around).

Then you can use a real filesystem on top of the block-mapping layer,
and the mapper can move the hotspot around the disk much as a RAID
array can rebuild under a real system.
Received on Sat May 27 2006 - 12:09:06 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:56 UTC