Google Summer of Code 2013 - DragonFlyBSD

Hello guys, welcome to next part of my series about  Google Summer of Code 2013. You might wanna read previous ones: 

Google Summer of Code 2013 - Introduction
Google Summer of Code 2013 - NetBSD


This time, I will write about another well-known BSD based OS - DragonFlyBSD. 

DragonFly BSD   

What is DragonFlyBSD?

DragonFly BSD is a operating system project organized around modernizing the BSD style of operating system.  Our current focus is the Hammer filesystem, designed for instant filesystem snapshots and long-term file history, able to mirror drives over the Internet.  It runs on i386 and x86_64 processors.
DragonFly currently uses pkgsrc for a packaging system, and is trying an experimental system called dports, based on FreeBSD's ports system.

So, this year, DragonFlyBSD got 5 accepted projects. If you wondering what were other ideas they wanted to make via GSoC, head to Ideas webpage.  

1. Block compression feature in HAMMER2 

Daniel Flores Tafur, mentored by Matthew Dillon

This project aims to add block compression feature to HAMMER2. It consists of 2 parts: first, implementing an algorithm capable of compressing a physical block to 50% or less of its original size (in powers of 2, like 32 KB, 16 KB; the original size being 64 KB) and, second, adding a hammer2 utility command to set the compression mode on any directory, which will try to compress any written content in that directory and its subdirectories using the implemented algorithm. If the algorithm can’t compress a particular block to 50% or less of its original size, the block is written uncompressed.

HAMMER2 is a feature-filled file system which is in active development phase right now. One of its features is a block compression feature that will allow users to easily save disk space and will work on-the-fly without any intervention from user other than setting it on a directory or the whole drive.

Physical block allocations in HAMMER2 are always power-of-2, so the compressed block has to be 32KB, 16KB, 8KB, etc., since the original block size is 64KB.

Thus, the compression algorithm has to offer both good compression ratio and high compression/decompression speed, so that the user wouldn’t be able to perceive any decline in the performance. At the same time, not all types of data can be efficiently compressed at all, so in case that a block can’t be compressed down to, at least, 32KB, it has to be written without compression.

At the current stage, there are 3 modes planned for this feature - #0 meaning no compression, #1 meaning zero-checking compression and #2, which will be a more complex compression algorithm. It’s possible that several complex algorithms will be implemented and users will be able to choose a specific algorithm.

 2. Capsicum kernel implementation

Joris GIOVANNANGELI, mentored by Alex Hornung

Capsicum is a fine grained capability framework for unix systems. It can be use to sandbox applications by restructing their access to various global namespaces. Capsicum is currently implemented in FreeBSD kernel. The goal of this proposal is to add capsicum support to the DragoFlyBSD kernel

3. Implement hardware nested page table support for vkernels 

 Mihai Carabas, mentored by Venkatesh Srinivas

The aim of this project is to implement support for extended/nested page tables virtualization extension in order to improve page table walkings in the vkernels.

This project wants to take advantage of the extended page table virtualization extension in order to obtain better perfomance in the virtual kernels from DragonFLY This will be done by providing hardware page table walking for the guest system (vkernel). Right now the page table walking is done in software.
The first step is detecting if the undelaying hardware supports EPT/NPT. Than I will start implement the virtualization extension for Intel hardware. In the end I will prepare a test suite to measure the gain of performance between hardware and software page table walking for vkernels.
More details you can find in my public proposal at [1].

[1] https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/mihaicarabas/14001

4. Make vkernels checkpointable 

 Pawel Dziepak, mentored by Samuel Greear

This project aims to make it possible to generate a checkpoint file of a vkernel and restore it later in a manner unnoticeable for the virtual processes it runs.

5. Userland System V Shared Memory / Semaphore / Message Queue implementation 

 Grigore Larisa-Ileana, mentored by Markus Pfeiffer

Implement some or all of these subsystems in their entirety, or as completely as possible in userland.

The project aims to implement System V Ipc mechanism (shared memory, semaphores and message queues)  as completely as possible in user-space in order to achieve good performance for heavy consumers such as PostgreSQL.  More details can be found in [1].  

 [1] https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/larisagrigore/12001

  

Good luck to all students ;] 

 

Small reminder, the progress of these GSoC projects can be tracked at this blog.
 

SHARE

JH

software developer - guitar player - poetry lover