Lecture: exokernel II

Application Performance and Flexibility on Exokernel Systems, SOSP 1997

Question

Consider an application running on top of an exokernel with its own libOS/libFS. The application wants to append some data to a file /README. The libFS thus needs to allocate a new block from disk and update the file’s inode (which contains a list of block numbers for the file content). Remember that the exokernel doesn’t understand the layout of the file system. How can the libFS convince the exokernel that the new inode’s content is correct? For instance, it should include the newly allocated block, it shouldn’t be able to “steal” another file’s block, and it shouldn’t corrupt other parts of the inode.

Similarly, suppose the application wants to read the content of /README. How can the libFS prove to the exokernel that it does own this file’s content? What checks will the exokernel perform?

Question

What crash-safety guarantees does an exokernel provide? To be more specific, after the machine crashes, is it possible for one libFS to contain disk blocks that belong to another libFS?

Question

The Cheetah HTTP Server performs a set of optimizations. Do you think one can implement these optimizations in a server running on a conventional OS (e.g., Linux), or are they exokernel-specific? Feel free to discuss other types of applications in this context.

Question

Provide a list of questions you would like to discuss in class. Feel free to share your thoughts on the exokernel architecture.

For instance, if you are interested in code downloading, check Chapter 6, “Reflections on Downloading Code” in Dawson Engler’s PhD thesis. It discusses several code downloading mechanisms and domain-specific languages described by the two papers: DPF (dynamic packet filters), ASH (application-specific handlers), wakeup predicates, and XN templates.

why do we read this paper
- how to write an experience paper
- solid engineering
- file system multiplexing through code downloading
  - “kernel” to inspect data structures it doesn’t understand
  - what kinds of systems have this problem?
  - examples: use eBPF with FUSE (ExtFuse) or hypervisors (hyperupcalls)
background
- unix file systems
  - abstractions: files, directories, symlinks
  - on top of a block device: read, write, flush (and trim)
  - structure: superblocks, inodes, free bitmap, data blocks
  - example: append a block to a file
  - example: today’s storage stack
- correctness
  - data structure
  - crash safety
    - use append as an example
    - approaches: journaling, copy-on-write, soft updates
    - will see more in the crash consistentcy paper
strawman approaches for multiplexing
- goal: flexible storage with minimal kernel support
- store block metadata separately: space, performance
- store metadata within the block: hard to fit, flexibility
key ideas
- use per-FS UDFs in the kernel
- UDFs are written in a domin-specific language with limited power
  - owns(b): a list of blocks owned by b
  - refcnt(b): reference count of b
- validation (and determinism)
example: append a block to a file
- goal: find a free block; update the inode with a new size & the new block number
- how does the kernel ensure the new inode content is correct: it doesn’t understand the format
- approach: validate (rather than computing) the updates using UDFs
  - check if a requested block is free
  - the size is updated to the correct value
  - the new block number is added
  - no other fields are modified
- optimizations?
example: file lookup
- approach: inductively infer the type of a block from root using UDFs
- locate the inode of the root directory from superblock
- read data blocks - permission checks
- find directory entry with the given name
why a central buffer cache registry in the kernel
- is this against the exokernel approach?
- shared blocks, crash safety
- (block, physical page) mappings and state
- order writes
  - who can insert mappings? user either proves it owns the block or asks the kernel
  - who can evict mappings?
  - a block cannot be freed until it’s not referenced by any other block: how to achieve this using UDFs?
  - a block cannot be written to disk unless it contains no pointers to a dirty block
  - implications?
- what about inconsistent reference counts?
  - when can this happen?
  - how to recover?