Your SlideShare is downloading. ×
OpenZFS code repository
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

OpenZFS code repository


Published on

Discussion of a platform-independent OpenZFS code repository at the 2013 OpenZFS Developer Summit. …

Discussion of a platform-independent OpenZFS code repository at the 2013 OpenZFS Developer Summit.

Published in: Technology

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Platform-independent code repository
  • 2. Goals ● Simplify getting changes into every platform ● Simplify SPLs (Solaris Porting Layers on non-illumos platforms) ● All code in OpenZFS repo can be pulled by all platforms with zero local modifications ○ This might be a stretch for day one
  • 3. What code is included? ● Must be testable on any platform ● Must be testable in userland ● Today, can include most of: ○ SPA, DMU, DSL, ZAP, ZIL ○ tested by ztest ● With userland ioctl work, can also include: ○ send/recv, diff, allow, zfs_ioctl.c, /sbin/zfs, libzfs ○ tested by testrunner test suite ● Makefiles? ● First goal: everything except: ○ ZPL, ZVOL, and vdev_disk.c
  • 4. Interfaces consumed ● All interfaces consumed by code in repo should be well-defined ● All functions should be prefixed with zk_* ○ zk_mutex_enter, zk_kstat_install, zk_kmem_alloc ● Repo will include code that implements these in userland (libzpool) ● Each platform (including illumos) will have a “porting layer” that implements these for their kernel
  • 5. Specific examples ● ZK_SYSCTL_UQUAD ○ declares tunables in FreeBSD style ○ other platforms can ignore ● zk_sleep_until ○ instead of cv_timedwait_hires(t_delay_cv, … ●
  • 6. What libs are included? ● To implement zk_* in userland, what about the libraries: ○ libnvpair, libavl, libumem ● Include them in the Repo? ● Require them as external dependencies?
  • 7. Procedures ● What code changes can be integrated? ○ Testing requirements? ■ Must be tested in one kernel? ■ Must add tests to test suite? ○ Review requirements? ■ pre- vs post- push review? ■ who must review? ○ Usefulness requirements? ○ Platform neutrality requirement? (“#ifdef LINUX”) ● What is the process? ● How are changes documented? ○ bug report? commit comment? commit notes?
  • 8. Proposed Procedure ● All changes must be reviewed before integration ● Changes should be tested in userland and in one kernel ● Relatively few committers initially (~3-10) ○ committers responsible for ensuring code is reviewed adequately by subject area experts ○ expected to be available to review code ● Changes documented in bug reports
  • 9. Coding rules What constraints need to be applied? ● Small stack allocations (linux has 8k stack) ○ create bigger stacks for sync/zio threads? ● ● ● ● language (C99) compiler (gcc & clang?) lint-clean (w/which flags?) strict lock order (FreeBSD’s WITNESS) ○ must be checkable in userland on other platforms
  • 10. Tools ● Github ○ but not pull requests ● Code review ○ Github? ReviewBoard? Webrev? ● Bug Tracking ○ Github? Jira? ● Makefiles ○ Each platform seems to have their own
  • 11. How to get there from here ● Create repo with files identical to illumos ● Reduce diffs between repo and other distros ○ upstream (to repo) or revert changes ○ e.g. add freebsd tunable declarations ○ e.g. convert linux to C99 ● Convert to zk_* wrappers gradually ● Testrunner on libzpool ○ finish userland ioctl work ○ add dd-like API to userland