Subject: Re: Building an alternate backing store.
To: Andrew Sporner <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 07/14/2000 11:09:57
In message <8D18C4F9CBA1D311900F00A0C990C97F67C964@neimail.networkengines.com>A
ndrew Sporner writes
>I am hoping that the season is more ripe for this because when I was
>asking questions some months ago I got no responses from the illustrious
>members of this list. I hope I do better this time... :-)
What kinds of answers are you hoping for?
There is a lot of prior art in this area, though not specifically with
NetBSD. Some of the tradeoffs and design choices have been fairly
Answers suitable for someone familiar with, say, the Sprite papers
and some of the implementation (or even comparison with other
contemporary distributed-system projects) won't be very useful
if you're not familiar with that work.
From that viewpoint, "Migrating processes using sockets" (paraphrase)
isn't a completely clear description: if you migrate a process twice,
does it depend on socketstate kept on both previous systems, or only
on the original host system? What crash-recovery operations are
needed after failure, and how long do they take?
Similarly, re DSM ("processes attached to shared memory"), what's
your design target? Release consistency, or something stronger?
Also, what's a "low latency interconnect"? Gigabit ethernet,
or something like Myrinet?