Introducing the PierreFS file system
It’s been a long time since the last blog update. One of the reasons for such an absence was that I was really busy at CERN. During my internship there (at LHCb experiment), my mission was to improve the way their diskless farm is working.
It was previously relying on the Red Hat diskless tools to allow ~15 nodes to run without disk, gathering their OS & their data from another server. But, this system and its implementation by Red Hat is really limited. Furthermore, starting with RHEL6 (Red Hat Enterprise Linux 6), the support for those tools has been dropped. The LHCb was to switch to another method.
One of the solution that was immediately looked at is file systems union. File systems union allow merging several directories (called branches) into one, in a transparent way. Some of those directories can be in read-only mode. Then, changes will only be applied to the writeable directories. So, for LHCb, the underlying idea was to use file systems union to provide easily manageable nodes. One shared root file system would be managed, and then snapshots (one per node) would be merged with shared root into different directories (one per node). And then nodes would boot on their directory. That was, you have each node with its personality and own file system easily. Without the constraints of the Red Hat tools.
We evaluated several file systems union drivers to select the one that was fitting our needs the best. Unfortunately, if several weren’t that easy to deploy, they were even worse to use. They were designed for totally different use (like, for example, LiveCD).
This is why, during a weekend, I designed a new union file system that would match their needs. As I was more creative for concepts than for names, I temporarily called it “PierreFS”. Feel free to find another one. If this file system takes most of its concept from the legacy UnionFS file system, it adds more features that are designed to highly reduce useless/redundant copyups (ie, files that were copied from read-only branch to read-write one, to be editable). One of the major feature of the PierreFS file system is its ability to split data & metadata when performing a copyup. It can handle both separately, to prevent data redundancy and allow easy updates of data, while metadata are modified. It has also a feature that permits the deletion of some copyups when it detected their are useless. Finally, this file system comes with some limitations since it’s targeting specific configurations. It can only merge one read-only & one writeable branches.
All the features described upper (including those from UnionFS) were implemented as a FUSE file system, to test viability of the file system and to validate the concepts. Unfortunately, this doesn’t include all the thought features. Some more like caching were first considered (and are still not dropped yet). The driver successfully passed our tests, and met LHCb expectations.
I’ve started portage to the Linux kernel as a driver for CERN. I hope I’ll be able to release it quickly. This work is once again based on UnionFS team work. This is a good basis to learn and understand.
You can find the FUSE driver at sourceforge.net (no packaging has been done - won’t be done).
This file system has been presented during the ICALEPCS11 conference at Grenoble, and has been described in the WEMMU05 paper & poster (with a comparison with the other file systems). All the conference material will be available on the conference site.
Tags: cern, copyup, driver, file, hat, icalepcs, lhcb, Linux, metadata, PierreFS, red, system, union