Skip to main content
Version: 4.0.8

Dev Guide

Development Environment

Currently, we target 22.04 Ubuntu LTS for releases. However, we don't recommend using your host machine for development (due to the fact that setting up tests modifies your host system and requires root privileges). Instead, we recommend using a virtual machine to develop and test SaunaFS. In the future, we will probably provide a Docker image for development instead.

You can use any virtualisation software you like.


You can use any editor you like. The core team uses various editors, including Visual Studio Code, CLion and Vim.


Sharing the source code with the VM

If you want to use the editors on your host machine, you should share the source directory with the VM and do your building/testing/running on the VM. You'll need to check your virtualisation software's documentation for how to do this.

For example, in KVM you can add a filesystem passthrough in virt-manager or by editing the VM XML file directly. If using virt-manager, you should use the virtiofs driver, the source path should be the path to the SaunaFS source code on your host machine, and target path something like saunafs.

You can then mount the shared directory with the following command:

sudo mkdir /opt/saunafs
sudo mount -t virtiofs saunafs /opt/saunafs

To mount every time you start the VM, add the following line to /etc/fstab:

saunafs /opt/saunafs virtiofs defaults 0 0

Dependencies/Installing Tests

You can use the following script to both install the dependencies and the testing environment:

tests/ /mnt/hda /mnt/hdb /mnt/hdc /mnt/hdd /mnth/hde /mnt/hdf

You can also run the script without arguments, and it will explain what it does.


We use CMake for building. There are some useful options you can pass to CMake:

  • DCMAKE_COMPILE_COMMANDS=ON: This will generate a compile_commands.json file which is useful for editors and tools to understand the build system. It should work fine on the host machine, as long as you have the necessary dependencies installed on the host (otherwise, it might show missing dependencies). Check the previous script code for the dependencies for Ubuntu LTS 22.04.
  • DENABLE_TESTS=1: This will enable building the tests.
  • DENABLE_DOCS=1: This will enable building the documentation.

In the source directory, you can run the following commands to build the project:

mkdir build && cd build
make -j4 # Generally 4 is a safe option, see below

The number of jobs you should use for make depends on the number of cores your VM has (i.e if you have less than 4 cores, you should use less than 4 jobs) and the amount of RAM you have. If you use too many jobs, you could run out of RAM pretty quickly. For example, with 32 cores, you could use 32 jobs, but you'll need about 100GB of RAM.

After make finishes, you can install SaunaFS with the following command:

sudo make install

You can also sudo make -j$(jobs) install to both build and install in one command. However, you'll need to use sudo every time you want to build.

Configuring SaunaFS/tests

We use a mixture of unit and integration tests. The integration tests require some more setup. Assuming you ran the script, you need to edit the /etc/saunafs_tests.conf file, uncomment the part with SAUNAFS_ROOT, and set that to /usr/local/ (or wherever you installed SaunaFS).

You also need to setup networking a bit. Currently SaunaFS forbids communication with master on localhost. You need to add a new IP address to your loopback interface. You can do this with the following command:

sudo ip addr add dev lo

To make this change permanent, you can add the following line under ethernets in /etc/network/00-installer-config.yaml (if you installed Ubuntu Server):


Generate the configuration with the following command:

sudo netplan --debug generate

Restart the network service with the following command:

sudo systemctl restart systemd-networkd

Verify localhost works with both and with ping.

You should then set sfsmaster in /etc/hosts to that IP address for ease of remembering the IP address. sfsmaster

Running the tests

Running unit tests is easy, in the build directory after building, run the following command:


For the integration tests, there are test suites available. These are managed by gtest and are simple shell scripts. You can see all of the test suites in the tests/test_suites directory, but the most important one is the SanityChecks suite. This should be run to ensure nothing is broken and before submitting a pull request.

To run the SanityChecks suite, you can run the following command:

saunafs-tests --gtest_filter="SanityChecks.*"

Others of note are the LongSystemTests and the ShortSystemTests. These are run by the CI system. The ShortSystemTests take about an hour to run, and the LongSystemTests can take up to a day.

Submitting Pull Requests

See the file for more information on how to submit pull requests.

Git specific settings

Code Style

We use clang-format to enforce a consistent code style. You can run something like git-clang-format to format your changes before committing.

git add <your changes>
git clang-format --style=file

Ignore revisions

Sometimes you want to ignore certain revisions when running git blame (i.e large rename commits). You can use the .git-blame-ignore-revs file to do this.

git config blame.ignoreRevsFile .git-blame-ignore-revs