Introduction
 

Persistence


Charles Gray

cgray@cse.unsw.edu.au
Introduction
1

Standard persistence - write
  
open(...)
while( obj != NULL )
{
    write_obj(obj);
    obj = obj->next
}
close()
Standard persistence
2

Standard persistence - read
  
open(...)
while( !eof )
{
    buf = malloc();
    read_obj();
    parse_obj(buf);
    if( prev )
        prev->link = buf;
    prev = buf;
}
close()
Standard persistence :: Standard persistence - read
3

World of Pain
 
  • Error-prone operation

  • Anything other than a linked list is much harder

  • What if...

    • Out of disk space

    • malloc() fails

    • We can't parse it?

Standard persistence :: World of Pain
4

A better model
  
open(...)
region = mmap( SOME_FIXED_ADDRESS )

foo = root_obj( region );

while( foo->chain != NULL )
     foo = foo->next;

foo->next = region_alloc( region );

close()
A better model
5

Notes
 
  • A far simpler programming model

  • Won't work in multiple address spaces

  • We can still do better

A better model :: Notes
6

Orthogonal persistence
 
  • Developed for long-running simulation
    • Tolerance of node failure required
  • Take a whole system snapshot
    • Threads and all
  • On failure, roll back to the last snapshot

Orthogonal persistence
7

Orthogonal persistence is cool
 

... so why doesn't everyone use it?
Orthogonal persistence :: Orthogonal persistence is cool
8

Implementing OP
 
  • Laptop hibernation is essentially OP

  • Device drivers and kernel structure can make it hard

  • Persistent abstractions like files make it harder

Orthogonal persistence :: Implementing OP
9

True OP is impossible
 
  • Network sockets

  • Device drivers

Orthogonal persistence :: True OP is impossible
10

OP is very inefficient
 
  • Checkpoints more often than needed
    • Else you will lose work
  • Checkpoints more data than needed
    • Caches and variable heap sizes
  • Databases are a pain, as usual

  • Checkpoints on a network are horrible
    • Stop all work, asynchronous checkpoints
  • Scientific applications don't communicate
    • Shared state is tricky. Message loss is bad.
Orthogonal persistence :: OP is very inefficient
11

What we want...
 
  • A nice programming model

  • Safe, independent checkpoints

  • Efficiency

Orthogonal persistence :: What we want...
12

Can it work?
 
  • I think so!
    • In one form or another...
  • The trick is Consistency Domains

Orthogonal persistence :: Can it work?
13

Consistency Domains
 
  • Thread state
    • Registers and stack
  • Heap

  • Shared objects

  • Connection semantics

Orthogonal persistence :: Consistency Domains
14

Consistency Domains
 
  • Annotate points of domain crossings with hints
    • Writing files, window managers, etc.
  • Annotate points where consistency doesn't matter
    • Fits closely with security model
  • Use these hints to enforce consistency of checkpoints

  • Tailor protocols to applications

  • All can be done at user-level!

Orthogonal persistence :: Consistency Domains
15

[Very] End
 
Questions?
[Very] End
16