ZFS Channel Programs
Proposed Project
Background: Administrative Ops & Synctasks
● ZFS administrative operations are done
transactionally as part of “synctasks”. Examples:
● zfs create
● zfs snapshot
● zfs set
● ‘zfs’ command sends ioctl to kernel
● Kernel queues operation’s synctask for execution
● synctasks are processed at the end of each txg in
syncing context (holds config lock for write)
● User must wait for txg to complete
What are the problems?
● The time between txgs can be 10+ seconds.
a. When doing consecutive operations each one
blocks for 10+ seconds.
b. Example: Delphix stores VMs on ZFS and
keeps metadata in ZFS properties, simple
operations like “create VM” take 30+ seconds
waiting for synctasks
What are the problems?
● Only transactionally consistent within synctask.
a. Forces logic into user space that could be
more efficiently/correctly implemented in the
kernel
b. Example: zfs destroy -r gathers the list of
snapshots to destroy in open context from
userland. Also destroy of snapshots and
destroy of filesystem are separate
transactions.
What are the problems?
● Encourages more and more complicated
synctasks in the kernel for correct behavior
● zfs destroy -p
● zfs rollback -p
● zfs snapshot <snap>,<snap>,...
● zfs snapshot (unless property is set)
Solution: ZFS Channel Programs
● Send a stream of instructions into the kernel for
execution by ZFS in syncing context.
● Being in syncing context guarantees atomicity,
consistent state changes, single-TXG execution.
● Enables rapid development of new “sync tasks”
from existing intrinsics.
Sample Channel Program
zfs destroy -r
for snap in zfs.snapshots_of(target)
zfs.destroy(snap)
zfs.destroy(target)
Plan of Action
Refactor existing sync task code to unify shared
execution paths.
Add Lua interpreter to kernel, implement ZFS
intrinsics (destroy, snapshot, etc) as extensions to
the Lua language that call into refactored sync tasks.
Add ZFS Lua iterators, e.g. children(fs), snapshots
(fs), etc.

OpenZFS Channel programs

  • 1.
  • 2.
    Background: Administrative Ops& Synctasks ● ZFS administrative operations are done transactionally as part of “synctasks”. Examples: ● zfs create ● zfs snapshot ● zfs set ● ‘zfs’ command sends ioctl to kernel ● Kernel queues operation’s synctask for execution ● synctasks are processed at the end of each txg in syncing context (holds config lock for write) ● User must wait for txg to complete
  • 3.
    What are theproblems? ● The time between txgs can be 10+ seconds. a. When doing consecutive operations each one blocks for 10+ seconds. b. Example: Delphix stores VMs on ZFS and keeps metadata in ZFS properties, simple operations like “create VM” take 30+ seconds waiting for synctasks
  • 4.
    What are theproblems? ● Only transactionally consistent within synctask. a. Forces logic into user space that could be more efficiently/correctly implemented in the kernel b. Example: zfs destroy -r gathers the list of snapshots to destroy in open context from userland. Also destroy of snapshots and destroy of filesystem are separate transactions.
  • 5.
    What are theproblems? ● Encourages more and more complicated synctasks in the kernel for correct behavior ● zfs destroy -p ● zfs rollback -p ● zfs snapshot <snap>,<snap>,... ● zfs snapshot (unless property is set)
  • 6.
    Solution: ZFS ChannelPrograms ● Send a stream of instructions into the kernel for execution by ZFS in syncing context. ● Being in syncing context guarantees atomicity, consistent state changes, single-TXG execution. ● Enables rapid development of new “sync tasks” from existing intrinsics.
  • 7.
    Sample Channel Program zfsdestroy -r for snap in zfs.snapshots_of(target) zfs.destroy(snap) zfs.destroy(target)
  • 8.
    Plan of Action Refactorexisting sync task code to unify shared execution paths. Add Lua interpreter to kernel, implement ZFS intrinsics (destroy, snapshot, etc) as extensions to the Lua language that call into refactored sync tasks. Add ZFS Lua iterators, e.g. children(fs), snapshots (fs), etc.