[cap-talk] CapROS checkpoint design available

[Bill Frantz]

shap at eros-os.com (Jonathan S. Shapiro) on Thursday, April 10, 2008 wrote:

>On Wed, 2008-04-09 at 18:43 -0700, Bill Frantz wrote:
>> Charles Landau and I have produced a design for the checkpoint
>> system on CapROS.au and I have produced a design for the checkpoint
>> system on CapROS.ailed.
>
>
>Bill, Charlie:
>
>...
>
>The overwhelming majority of what is described in this checkpoint design
>document is simply the EROS design as CapROS inherited it. The changes
>are fairly insignificant. I am disappointed that the document
>appropriates my work without giving proper credit. This design predates
>CapROS by many years. It wasn't designed for CapROS or by the CapROS
>team.

I will note that your copyright is still on the paper. I don't know
of a better way of giving credit, but I am somewhat ignorant in
this area.


>You cite the KeyKOS paper, but you do not cite the EROS paper on
>checkpoint, which is significantly more detailed.

What paper? Is it online? I'll be happy to add a reference.

In this regard, I had a debate with Charles about how far the EROS
checkpoint implementation had gotten. He thought it had not gotten
much beyond the design stage, while I saw various indications in
some of the documentation and program comments that it had gotten
far enough to actually turn up bugs. You mention in your email,
"You will find on measurement that the EROS decision in this regard
remains correct for disk checkpoint." Was determined by measuring
an implementation, or by simulation?


>You should specify what is meant by the term "full size lid".

Our examples use a 64 bits for both the lid and the oid. That is,
56 bits of disk frame address and 8 bits of object index within
frame. Full size means a lid is the same size as an oid. I'll try
to clarify it in the web page.


>A couple of points on how EROS handled the log directory and lid ranges:
>
>EROS's use of a two-level hierarchy was a pragmatic implementation
>choice that was appropriate to the machines of the day. A different
>design would certainly be appropriate now.
>
>EROS did not linearize the directory because the long-term design
>strategy envisioned log designs in which linear checkpoint image storage
>in the log might not be possible. This is notably true if the Snocrash
>design is adopted. The problem is that checkpoints in the Snocrash
>design may be retired out of order, and it may not be possible to
>guarantee linear storage of the log. I definitely agree that this is not
>a factor for CapROS. I simply wanted to explain the motivation so that
>the decision might make some sense.

We had a design which had a number of chain-heads in the checkpoint
header for the directory. Each directory frame had a link to the
next in the chain. This design gave us both a degree of parallel
data reads, and random locations for the individual frames. We
decided on a linear directory when we didn't see an advantage to a
random one. If we adopt something like Snocrash or holes in the log
range, we might go back to that scheme, but will enjoy the
simplicity of the linear scheme for now.


>If holes are permitted in the lid range, note that removing a linear lid
>range from the log can run you into situations where you are no longer
>able to linearize the directory within any sequential lid range that is
>actually available...

Indeed. An important issue.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | I like the farmers' market   | Periwinkle
(408)356-8506      | because I can get fruits and | 16345 Englewood Ave
www.pwpconsult.com | vegetables without stickers. | Los Gatos, CA 95032