The Certifiable File System can be mounted and unmounted at runtime. It is possible to mount the CFS into the root directory of an existing POSIX file system. CFS is designed to run on block devices with a configurable block size. The device driver has to provide block read and write functions to CFS. They are passed as callback functions to CFS upon mounting.

In addition to the callback functions, a handle is passed to CFS that will be provided as an argument at each call of the callback functions. This handle can either represent the memory area on which the block device runs, or a PikeOS file descriptor. This allows the block read and block write functions to be implemented by a PikeOS file provider. CFS then resides within a PikeOS file, without PikeOS knowing anything about the CFS directory tree representation.

Figure 1: CFS linked to an application using a disk driver

Figure 2: CFS linked to an application using a PikeOS file provider

To assure a fail safe file system, all changes within the CFS lead to an immediate device access. Furthermore integrity checks of the file system meta data are performed by the CFS at mounting.

CFS is provided as a library that can be linked to a PikeOS or POSIX process. Each CFS instance is mounted by a single PikeOS process. Parallel access from different threads is forbidden. However, the PikeOS external file provider concept makes it possible to use CFS in a more versatile way. If CFS is linked to an external file provider, multiple threads can access the external file provider in parallel and so the CFS access is serialized.