Opinions on error recovery?

[Christopher Quinn]

 > Hello people... I would really like people's opinion on what the behaviour
 > of LPSM on checkpointing failure (disk full, for example) should be.
 > Checkpointing failure is detected asynchronously, so returning an error
 > the obvious way isn't possible.
 >
 > Currently, LPSM sends SIGABRT to the master process; a bit crude, and not
 > safe if another checkpoint process has since been started.
 >
 > It seems there are only a small handful of options:
 >
 > a) Send a signal to the main process; make sure interlocks are in place so
 > that any further checkpoint processes are terminated without writing any
 > commit records.
 >
 > This minimizes the processing that can actually take place without
 > anywhere to put the data.  It also makes sure that on restart we will roll
 > back to the last consistent state we could actually store on the backup
 > medium.
 >
 >
 > b) Reconstruct the dirty mask and keep running, hoping that a future
 > checkpoint will succeed.
 >
 > This requires some pretty complicated tracking in the main process of what
 > has actually been committed by which process, but that's not too bad to
 > deal with.  It also means that we can continue running uninterrupted and
 > after manual intervention to clear the problem checkpoint all data.
 >
 > The problem is that it allows for an unbounded amount of computation to
 > happen without a backing store.
 >
 >
 > I would appreciate to hear what people think.
 >
 >


Hi,

In writing my own persistent store stuff I took the view that if there was any
chance of user intervention being viable then provide a handling hook.
Returning from the function is interpreted as continue as normal (unbounded
computation case), and up to the function whether to launch a thread continuation
or simply block  ie. a) display a window message and block further processing by 
not returning immediately, or b) launch thread to display message, while 
returning from handler.

Perhaps I could solicit opinion on something?
I see that by using a file based log, as does lpsm, it is trivial to detect its 
end. But what if you were to use a block device?
Then it is not so simple because there is the matter of previously written log 
material being wrongly interpreted as part of a valid log record.
I use a double root block scheme which reserves space at the head of the log device.
But I am not happy with it since it entails a change of disk head position after 
the regular log record write. The alternative I guess is to include some sort of 
checksum with the last record written so as to provide a measure of protection 
against inadvertent collision with previous logging. But what is a 
computationally inexpensive operation and what degree of certainty is enough!?
Have you thought about this issue at all?

Cheers,
Chris Q.