[cap-talk] Styles of persistence

[Jed Donnelley]

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?  What about power outages?
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.

At 02:20 AM 4/4/2008, Jonathan S. Shapiro wrote:
>On Fri, 2008-04-04 at 01:48 -0700, Jed Donnelley wrote:
> > But just like any process (program?) on the system can't it be
> > restarted by some other controller?
>
>No, because the durable capabilities all point to the old one.

The "controller" that I'm referring to is part of the checkpoint
recovery process.  It of course has to operate without any space
bank capabilities or any space bank allocations of storage space.

> >   Restarted with different
> > code that, as Jonathan noted, reads in it's old format data
> > and writes out new format data.
>
>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.

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.  While still not impossible, that would make
the job much more difficult.  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.

>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.

I hope I'm not missing the point here.

--Jed  http://www.webstart.com/jed-signature.html