[Oberon] persistence-across-reboot

[John Drake]

The best system I've heard of for such persistence is the eros-os
(extremely reliable operating system).  

http://www.eros-os.org/

Here's an anecdote from the project website:

===================================================

EROS persistence is a kernel service. While this makes the EROS
kernel larger than non-persistent kernels such as QNX, non-persistent
kernels do not provide a comparable means of transparent recovery.
A (true) story about keykos may provide some sense of the value of orthogonal persistence:
At
the 1990 uniforum vendor exhibition, key logic, inc. found that their
booth was next to the novell booth. Novell, it seems, had been bragging
in their advertisements about their recovery speed. Being basically
neighborly folks, the key logic team suggested the following friendly
challenge to the novell exhibitionists: let's both pull the plugs, and see who is up and running first.
Now one thing Novell is not is stupid. They refused.
Somehow,
the story of the challenge got around the exhibition floor, and a crowd
assembled. Perhaps it was gremlins. Never eager to pass up an
opportunity, the keykos staff happily spent the next hour kicking their
plug out of the wall. Each time, the system would come back within 30
seconds (15 of which were spent in the bios prom, which was
embarassing, but not really key logic's fault). Each time key logic did
this, more of the audience would give novell a dubious look.
Eventually,
the novell folks couldn't take it anymore, and gritting their teeth
they carefully turned the power off on their machine, hoping that
nothing would go wrong. As you might expect, the machine successfully
stopped running. Very reliable.
Having successfully stopped their
machine, novell crossed their fingers and turned the machine back on.
40 minutes later, they were still checking their file systems. Not a
single useful program had been started.
Figuring they probably
had made their point, and not wanting to cause undeserved embarassment,
the keykos folks stopped pulling the plug after five or six recoveries.
In the end, the issue comes down to this.
Suppose you had perfect software and hardware (if you find some, be sure to let us know). Even
so, your computer will fail four to five times a year due to random
background radiation.
So when your computer fails, do you want to
be told that all your files are intact and you can now resume your
painstaking work (having lost your latest session), or would you rather
have all of your windows, (complete with word processor, web browser,
and solitaire) reappear with a few minutes lost work. Take your pick.
=======================================================




----- Original Message ----
From: Paul Reed <paulreed at paddedcell.com>
To: oberon at lists.inf.ethz.ch
Sent: Thu, April 15, 2010 6:50:16 AM
Subject: [Oberon] persistence-across-reboot

Hi folks,

Another reason to use a filesystem driver with flash memory is to take
advantage of the implementation of wear-levelling (assuming it isn't
handled by the hardware), although this would of course be less important
if the memory was solely used for persistence across reboots.

Checkpointing the system state every couple of minutes would be a useful
defence against power failure, too - but then you would definitely want to
look at how many write cycles your device claims to last for :)

Cheers,
Paul

> Message: 1
> Date: Wed, 14 Apr 2010 18:29:55 +0200
> From: Peter Matthias <PeterMatthias at web.de>
> Subject: Re: [Oberon] Re (3): persistence-across-reboot
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Message-ID: <201004141829.55153.PeterMatthias at web.de>
> Content-Type: Text/Plain;  charset="iso-8859-15"
>
> Am Mittwoch 14 April 2010 schrieb peasthope at shaw.ca:
>> All the non-volatile storage I've heard of organizes
>> data as files in a filesystem.  Does anyone sell
>> flash memory which is accessed by an address just
>> as RAM is?
>
> You can use a block device driver and mmap it to the address space, as it
> it
> done in Linux.
>
> Peter
>
>
> ------------------------------
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>
> End of Oberon Digest, Vol 76, Issue 2
> *************************************
>


--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon