RE: Persistence Pros and Cons

[Christopher Nelson]

> > Once you start implementing persistence by degrees you run into a 
> > whole bunch of edge cases where it's just easier to implement 
> > system-wide persistence anyway.  That's been my experience, in any 
> > case.
> 
> I guess so.  Have you been working on 
> persistence/checkpointing mechanisms?
> 

Yes.  Using the spoon microkernel as a starting place 
(http://www.djm.co.za/spoon/) I've been experimenting with capabilities and 
persistence.  I was talking with the kernel's author about several things we'd 
like to implement, one of them being a more generic IPC mechansism that will 
support map, grant, and copy for all IPC.  There's also a very fast copy 
operation that simply transfers 6 dwords to a vector in the receiving thread.  
All operations are asynchronous.  However, we both feel that we would like to 
make some changes to the API to make some things more secure.  For example, 
instead of having global thread and process ids, all ids will be local and a 
translation table will exist in the kernel's thread structure to map those to 
the kernel's global process/thread id.  This should essentially confine all 
communication between executable objects, and it also provides a way to check 
if a given thread can communicate with any other given thread, or any thread at 
all.  I'm still thinking about the introduction problem (how do two threads get 
a hold of each other to perform some communication without a global nameserver.)

Regarding persistence, I've been working on a streaming protocol that would let 
the kernel checkpoint a process (and all of it's threads) on the fly.  At first 
the idea was to just stream binary data through IPC's to a trusted user-land 
process that treats the whole disk like a circular transaction log.  The 
problem with that involves performance: copying data, and formatting and 
reformatting data on the inbound/outbound.  The plus was going to be that some 
kernel structures could be persisted (transacted) while others weren't, 
hopefully allowing for a finer-grained transactions that didn't require 
stopping the world. Or the whole process, at a minimum.  The problem isn't that 
an incremental and partial persistence mechanism is hard to make, it's that the 
recovery mechanism is hard to make.  Each aspect has dependencies that must be 
checkpointed before it is in order to ensure a stable recovery image.  Once you 
walk the dependency chain and checkpoint each of those pieces, you might as 
well have checkpointed the whole thing.

My other idea regarding that is to simply have a transaction log of the 
*operations* performed.  So that when a thread is deleted you first note the 
thread deletion in the log.  Once that completes, you delete the thread.  A 
similar operation would happen for all significant operations, but the only 
actual data that would be retained would be memory contents.  The difference is 
like the difference between the old .3ds format that stored the 3d-model, and 
the new .max format that stores the commands to rebuild the model.  I'm not 
convinced that this is performant.

-={C}=-