Re: How to protect DoC 2000 from power fail?

Charles Manning
2002-03-19T11:52:41Z

On Tue, 19 Mar 2002 01:10, David Woodhouse wrote:
> wil@wtms.nl said:
> > I am looking for some rigid means of power fail protection for a DoC
> > 2000 based embedded system. From what I have read so far I understand
> > that almost any brand of journalling file system should do well but,
> > then again, those readings also mention raw FLASH and not DoC, in
> > other words, I think I am lost. Would someone be so kind to enlighten
> > me?
>[snip]
> CompactFlash also uses such a pseudo-filesystem, but does it completely
> internally. Electrically, it behaves just like an IDE drive. Reportedly CF
> devices are very bad w.r.t to power failure and wear levelling though, but
> the concept is similar.

CF should have at least 15ms of good power after the last write. This is
required to complete the write internally.

Dunno what goes on in a DOC, but basically it needs some power to complete
the last write. Dunno how clever it is at fixing itself. Maybe read the
msystems www. They have some good application notes - maybe one covers these
issues.

Hard disks get around the power issue by using the inertia of the spinning
disk to generate sufficient power (well that's what I believe anyway). No
such luxury with flash. You either need a resiliant file system - preferably
one designed specifically for flash - or some way to guarantee power to
complete a shutdown.

I've done both in various situations.

One way to guarantee good power into the FS is to do something like follows:
* Have the hardware report an early warning of imminent power failure. eg. if
you have a two-stage switchmode, detecting the regulation loss flag on the
first stage might do the job.
* Protect all critical FS entry points with power checks:
write_func()
{
while(power is bad) { /* spin */}
rest of function
}
* If you've done this right, you never go into a critical section with bad
power. If power turns bad during the run of the function then hopefully the
residual energy in the rail etc will be enough to power the system through
the rest of the function call.

This can work well if your hardware supports this kind of detection and has
sufficient residual energy. Dunno how long you need for a DOC, but I would
hunch that 100ms would be enough.

> If you want to be able to write to it then the correct solution, IMO, is to
> write a _real_ file system which operates on flash directly instead of
> operating on a block device. Build in the wear levelling, journalling, etc.

Too right!

-- Charles