zfs

ZFS Port: Midterm Report

Blog post by GeneralMaximus on Tue, 2011-07-19 09:44

My midterm goal was porting libzpool -- which contains most of the ZFS code -- to Haiku. Another midterm goal was to get ztest -- the ZFS testing tool --- to run on Haiku. Being able to run ztest in a loop for an entire day means that about 80% of the ported code is working fine (though the remaining 20% is the most difficult part of the entire porting process). ztest is a userland test, so actual file system modules or disks are not involved in the testing procedure -- ztest creates block files in a temporary directory and treats them as disks.

It took me days of fighting with the linker and the compiler, but I'm happy to report that both ztest and libzpool build on Haiku without errors! Does that mean I can run ztest for a day without problems? Sadly, that is not the case. ztest is unable to create ZFS storage pools and fails within a second of starting up. I am currently trying to investigate and fix this crash. Fixing this one crash will reveal more crashes, and running ztest with several threads will reveal subtle threading issues. This means I have my work cut out for me ;)

Meanwhile, I have also started porting libzfs, which is the library used by the zfs and zpool administration tools to communicate with ZFS code in the kernel. This communication occurs as ioctl() calls on /dev/zfs. My goals for the quarter term are getting libzfs, along with zpool and zfs, to build on Haiku. Of course, an additional goal is to get ztest to run without crashing.

You can follow the project at http://github.com/GeneralMaximus/zfs-haiku. Building ztest is as easy as cloning the repository, changing into the zfs-haiku directory, and typing "jam ztest". The ztest executable is generated in the debug.X86 directory.

ZFS Port: Quarter Term Report

Blog post by GeneralMaximus on Fri, 2011-06-17 03:32

My quarter term goals for the ZFS port included porting all the libzpool dependencies to Haiku. Out of four major dependencies -- libavl, libnvpair, libuutil and libumem -- I already have two -- libavl and libnvpair -- building on Haiku. libumem and libuutil will take another few days, which puts me at least a week behind my original schedule.

I'm currently working on porting libuutil, which is presenting a few roadblocks but nothing that can't be fixed in one day's work.

When I have some free time, I want to take a break from working on the port and do some cleanup. So far I've indiscriminately copied all the Solaris headers I need into my own repository. This is bad. I eventually want to use as many Haiku headers as possible, only importing those definitions from Solaris that are missing from the Haiku headers.

After all the libraries are working, the next step is porting libzpool itself.

My source repository is located at http://github.com/GeneralMaximus/zfs-haiku.

ZFS Port: Community Bonding Report

Blog post by GeneralMaximus on Mon, 2011-05-30 19:39

I was busy with finals throughout the Community Bonding period, which left me with little time to work on GSoC-related tasks. I still have 3 exams left with the last one being on June 7. That's when the fun starts. For now I'm merely playing with ZFS on FreeBSD on a virtual machine. I still need to make my way through at least the ZFS On-Disk Specification. Even though the information contained in this document is not strictly required for porting ZFS to Haiku, it's a useful read nonetheless. It also makes me look like a rockstar when I open it in coffee shops.

According to my proposal, this is what comes next:

  • Finish porting dependencies (libavl, libnvpair, libuutil, libumem).
  • Begin writing an OpenSolaris compatibility layer. This involves studying how threads, mutexes, condition variables etc. work on Solaris and then writing wrappers that behave in a similar manner around the Haiku API.

This means approximately one week spent on porting and testing dependencies and a fair bit of time spent on learning about low-level Solaris interfaces. One week is an optimistic estimation for a port of any kind, but some of the dependencies are merely libraries that implement useful data structures. This means they might build on Haiku without major changes. I can't say anything further unless I've taken a better look at them myself. The end result of the quarter term should be an OptionalPackage that contains all the external ZFS dependencies.

June 7 is not far :)

Syndicate content