[cap-talk] Styles of persistence

[Jonathan S. Shapiro]

On Fri, 2008-04-04 at 03:14 -0700, Jed Donnelley wrote:
> Regarding:
> 
> At 02:17 AM 4/4/2008, Jonathan S. Shapiro wrote:
> >On Thu, 2008-04-03 at 19:06 -0700, Bill Frantz wrote:
> > > jed at nersc.gov (Jed Donnelley) on Thursday, April 3, 2008 wrote:
> > >
> > > >Perhaps Bill can explain what makes the KeyKOS space bank unusual
> > > >in this regard.  I'm afraid I don't know what a "space bank" is
> > > >or how it is organized internally.  Is that relevant to this
> > > >discussion?
> >
> >As an analogy, imagine converting some application from one database
> >(e.g. Oracle) to another (e.g. Sybase) under the constraint that you
> >cannot take the application down during conversion.
> 
> I can see some difficulty there, but isn't it true that in this case
> that the KeyKOS system can be restarted?  Are you suggesting that once
> a KeyKOS system starts it can never restart?

For purposes of our current conversation that is exactly the case.

>   What about power outages?

That is not a *logical* restart. Computation is logically uninterrupted
by power outage.

> If it can be restarted (as I must believe) then it can be restarted
> with different code.  The code that recovers the system state can be
> changed to modify the form of the space bank metadata and then restart
> the space bank with the updated code - it seems to me.

I can rewrite a file system from VFAT to NTFS using offline techniques.
But this relies on the fact that no active computation is currently
underway that manipulates those data structures. In a persistent system,
active computation *is* underway, so offline techniques are never quite
offline in the same sense.

> >There is a boot-strapping problem here, since you (a) you cannot convert
> >without allocating storage,
> 
> The above is what I'm questioning.  You certainly can (though possibly
> unpleasantly) do a conversion without allocating storage through the
> space bank.  All the state is stored on disk.  A code can run and do
> any sort of manipulation of that state on disk that is completely
> independent of any "space bank" or capabilities or even KeyKOS - though
> of course the object is to create a new disk state that will be
> ready for an updated KeyKOS to start with the new space bank
> metadata and code.

In practice, it cannot, because any such manipulation would violate the
dependency assumptions of the space bank code that is executing (at
least logically) against the old data structures at any moment when you
might be converting.

> One aspect of things that I could see would make them much more
> complex would be if the space bank "process" (state) included
> stack space for threads that might have it in the middle of
> processing requests (e.g. blocked on semaphores, etc.) and
> those blocked requests had to finish properly after the system
> is restarted.

But this is almost certainly the case.

> Is that the situation that KeyKOS
> must deal with?  That would make things complex enough that I
> think I would try to get around it - e.g. by restarting all
> pending space bank requests.

How? You have no means to deliver exceptions to the space bank code that
will allow it to restart requests in an orderly way.

> >and (b) you cannot allocate storage until
> >you convert...
> 
> the above part I believe - though even there you are meaning
> "allocate storage" through the space bank code I think.
> Storage can of course be 'allocated' through other means.

It cannot, since the space bank is the ultimate arbiter of storage.


shap