Re: Persistence Pros and Cons

[Jonathan S. Shapiro]

Martin: good to see you here!

On Tue, 2005-11-08 at 00:00 +0100, Martin Schoenbeck wrote:
> It was mentioned here, being unable to cure a hanging program by reboot, 
> was one of the disadvantages of persistence. That's true, but if you do 
> a reboot with conventional systems, you loose the context of most of 
> your programs and for those programs, which remember the context, *you* 
> must remember, to start them again. I'm regurlarly loose several open 
> browser windows with not yet read contents in such situations.

Yes. I also wanted to respond to this point.

If a program is hung, you should be able to kill it. Rebooting is kind
of like using a nuclear bomb to open the bedroom door when it is humid
and the wood has swelled very slightly.

This, of course, is not true for critical system programs at the level
of things like the storage allocator. In EROS (and, I suspect, in Eumel;
can you comment, Martin?) these programs are extremely simple and VERY
carefully designed. Fortunately there are very few programs where this
degree of care is required.

Ironically, it is the *presence* of persistence that allows these
programs to be simple. Think, for a moment, about a conventional (ad-hoc
persistent) file system. You have two basically simple issues (space
allocation, file structure management) that are intertwined with an
ad-hoc transaction processing system (in order to ensure consistency).
The need for consistent I/O makes things complicated, but also slow, so
next you make the file system concurrent, which compounds the problem of
complexity by several orders of magnitude. Next, you decide that waiting
for all of the disk writes is slow and highly synchronizing, so you
migrate some of the burden into fsck. This lets you do fewer
synchronizing I/O operations, but at the cost of making the relaxed I/O
ordering invariants *extremely* complicated to maintain.

I just ran my lines of code tool on parts of the linux-2.6.12.4 source
tree. The Linux fs/ext3 directory alone contains 10,447 NCLOCS, and this
code does NOT include argument processing. fs/reiserfs is 18,534 lines.
Hell, guys, the entire EROS *microkernel* is only 21,563 NCLOCS
(excluding kernel debugger).

For comparison, the EROS file server implementation contains 498 NCLOCS
(non-comment, non-blank lines of code). The directory implementation is
another 418 NCLOCS. These counts **include** the IPC message processing.
They do no synchronous I/O, and therefore have no need to be
multithreaded. I would bet that the Eumel file system is not very much
different in its complexity.

Antrik: earlier I was a bit impatient with your assumptions about the
complexity of orthogonal persistence, and I probably should apologize.
Now that you see the actual numbers and some of their consequences, does
the argument in favor of persistence at least seem a little clearer? In
my opinion, if this result was the *only* benefit of persistence, it
would probably be worthwhile.

Martin: how are similar things handled in L3/Eumel, and do you see
similar complexity reduction in these very critical pieces of code?


shap