Storage Drivers

In one sentence: The layer-stacking machinery itself sits behind a pluggable storage driver interface — overlay-style file-level drivers by default, snapshot-based block-level drivers (btrfs, zfs) where the filesystem offers native CoW — chosen once per engine, invisible to images.

Same verbs, different physics

Every storage driver answers the same five questions: create a layer from a parent, mount a stack, capture a diff, apply a diff, delete a layer. What differs is the physics underneath. Overlay-style drivers work at file granularity: simple, fast to set up, but first-write copy-up is proportional to file size. Snapshot-style drivers (btrfs, zfs, devicemapper) use the filesystem's native copy-on-write at block granularity: modifying one block of a 5 GB file copies kilobytes, not gigabytes — but they demand that specific filesystem under the engine's storage directory. Images don't care: layers are just tars (Lesson 7); the driver is a per-host deployment decision, not part of the image contract.

flowchart TB
  E["engine"] --> IF["storage driver interface
create · mount · diff · apply · delete"]
  IF --> OV["overlay-style (default)
file-level CoW
works on any host"]
  IF --> SN["snapshot-style (btrfs / zfs)
block-level CoW
needs that filesystem"]
  OV --> D1["copy-up cost:
whole file"]
  SN --> D2["copy-up cost:
changed blocks only"]
  IMG["images (layer tars)"] -. "identical regardless
of driver" .-> IF
    

sequenceDiagram
  participant B as Builder
  participant IF as Driver interface
  participant OV as overlay driver
  participant SN as snapshot driver
  B->>IF: diff(layer) — what changed?
  alt overlay backend
    IF->>OV: diff
    OV-->>IF: walk upperdir, tar the files
  else snapshot backend
    IF->>SN: diff
    SN-->>IF: filesystem reports changed blocks → tar
  end
  IF-->>B: identical tar format either way