RE: [gridcpr-wg] 12/8/03 draft of GridCPR Use Cases

["Nathan Stone" <stone@psc.edu>]

Hi Paul, et al.

	Here are some of my thoughts about your draft.  (Sorry for the delay.)
Thanks for posting this.  It looks great -- and I particularly agree with
this approach as opposed to the simple "laundry list" of use cases.

Cheers,
	Nathan.


- lines 66-69: The use of this paragraph is unclear.  Nothing is built upon
the supposition in question...  In other words, you could probably leave it
out.

- line 88: should be "to stable *storage*"

- line 90: I would recommend using the term "transparent" mechanism (as
opposed to "low-level".  This allows for other software solutions that are
not explicitly part of the OS, but are capable of co-opting the resources of
a running application transparently.  Admittedly, there are few of these,
but we are already at the prototype stages of such a solution under an NSF
ITR.  All that said, we're basically drawing the line along the "modify your
code" / "don't modify your code" axis...  Which is what we want, right?

- line 202: other thoughts about services:
  * storage or "I/O" daemons -- to serve up CPR storage resources
  * file transfer services (this is distinct in PSC's implementation, but
might be as simple as UNIX "cp" elsewhere)
  * checkpoint state manatement (like a DBMS)

- line 211: also may want to note that minimal overhead when *writing*
checkpoints is more important than when *recovering*.  One expects some
penalty (and would probably be willing to pay performance) for the recovery
step.  (It just so happens that the PSC solution refunds both the "lost"
time and the "recovery" time...  But there's no need to mention that in the
document.)



> -----Original Message-----
> From: owner-gridcpr-wg@gridforum.org
> [mailto:owner-gridcpr-wg@gridforum.org]On Behalf Of Paul Stodghill
> Sent: Monday, December 08, 2003 6:09 PM
> To: gridcpr-wg@gridforum.org
> Subject: [gridcpr-wg] 12/8/03 draft of GridCPR Use Cases
>
>
> Here it is. I have also submitted it to GridForge, so it should appear
> there shortly as well.
>
> I chose not to include the submitted use cases directly into this
> document. I saw certain common features between many of them, so I tried
> to weave them together to highlight the various ways in which people are
> interested in using checkpointing. I also tried to distill these
> scenarios into requirements that were consistent with our charter and
> with our discussions.
>
> Please don't be shy about telling me that I missed the mark! Sooner
> rather than later!
>
> Post your comments on the draft to this list so that we can generate
> some discussion about some of the issues that this draft raises. In
> order to make reference to the document easy, it is dated "December 8,
> 2003", and contains line numbers. Please use this information, because
> there will be future drafts!
>
> I am especially interested in hearing from the people who submitted use
> cases: does this document capture what you had in mind?
>
> Thanks to everyone for your help.
>
>