[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Jonathan S. Shapiro
Mon, 31 Oct 2005 09:19:58 -0500
On Sun, 2005-10-30 at 23:20 -0600, William Grim wrote:
> I haven't thought about all the details, but in my mind you would just
> have to have some way to store all the process (task) contexts
> (servers+data/registers) as they run and keep checkpointing them.
This is basically right. The trick to it is to ensure that all of the
definitive kernel data structures are easy to export. By "definitive", I
mean "any state that the kernel cannot easily reconstruct".
> if this happens frequently doesn't this
> greatly reduce performance?
> I don't know how KeyKOS/EROS handle persistance, but I'm quite curious
> how they do it without providing lots of overhead due to overloading
> the bus bandwidth (i.e. IDE, SCSI, etc).
Ruud was asking about excessive checkpoint frequency. In answer to your
answer, the issue isn't bus bandwidth; it's sustainable disk throughput
**at the disk**. Overall, checkpointing does better at using and
managing this than conventional file systems. For the full story you
really need to look at the paper, but here is a hint: the two ideal
conditions for I/O are (1) linear, and (2) sortable bulk. Essentially
*all* checkpoint-related I/O meets one of these two conditions.
No compression is used. This would actually make matters much harder,
because it would have the effect of making block sizes variable.