Persistence

[BRIAN SPILSBURY]

> Brian Spilsbury <zhivago@iglou.com> wrote:
> > Personally I'd vote for a transparent POS, transparent to the point
> > where the disk _is_ memory, and we're just using ram for cache,
> > then it should be relatively easy to add in persistence of execution.
> 
> Please remember that in many practical cases, there are important
> semantic differences between having something in memory and having
> it on disk. Think of a multi-user database with concurrent nested
> and independent transactions, where after immediate hardware crash
> (where the disk is still usable), the data on the disk must contain
> every committed transaction, and restart must back out everything
> else. Assume that this must be possible in a system operating near
> the limits of the disk's io performance. You might not worry much
> about a system crash while you're editing your source code in memory,
> but there are systems where changes are more expensive, and where
> changes have non-reversible real-world consequences and commits do
> occur with a much higher frequency.

With a little care this shouldn't be a problem. We could for example
have a global commit for all dirty pages, with the ability to roll back
the system to the state of the last commit. And for special purpose
programs like transactional databases you'll want memory-level features
like allocating memory in 'synchronous space' where dirty pages are
immediately written to disk while you block.

I'm sure there are better solutions than 'sync' blocks, but that idea
should cover your objection, you won't be able to go faster for writes
than the physical media in any case if you want reliable storage.

But the loss of transparency here is over a much smaller domain than
restricting persistence to special applications which explicitly access
a database. Casual persistence is useful and nice for most applications.

Brian