IMFS_statvfs: API to get IMFS statistics

Over the past few weeks, I had the opportunity to implement the IMFS_statvfs function in the RTEMS kernel. This was an engaging and educational experience that gave me a deeper understanding of how virtual file systems work and how the IMFS (In-Memory File System) is structured within RTEMS. The project involved studying existing infrastructure, learning how system calls are routed through the kernel, and eventually writing a missing backend for an existing API.

To start with, statvfs is a POSIX system call that retrieves information about a mounted file system. When invoked, it fills a struct statvfs with statistics such as total blocks, free blocks, block size, and so on. This information can be extremely useful to applications that need to monitor storage usage, enforce quotas, or make decisions based on available space.

The struct statvfs, as defined by POSIX, contains several important fields. Some of the key fields include:

• f_bsize: The file system block size. All data in the filesystem is organized in fixed-size blocks, and this field represents that unit.

• f_frsize: The fragment size. This is often the same as f_bsize, but it can differ in filesystems that support block fragmentation.

• f_blocks: The total number of data blocks in the filesystem.

• f_bfree: The total number of free blocks in the filesystem.

• f_bavail: The number of blocks available to unprivileged processes.

• f_files: The total number of file nodes (inodes) that can be created.

• f_ffree: The number of free file nodes.

• f_favail: Number of free file nodes available to unprivileged processes.

• f_flag: Mount flags, indicating read-only status, etc.

• f_namemax: The maximum length of a filename.

I frequently referred to the manual pages using the man 3 statvfs command to understand the behavior and expectations of the interface. These pages were instrumental in guiding my implementation, especially when it came to ensuring compatibility with POSIX standards.

RTEMS already has a centralized implementation for the statvfs system call in the file cpukit/libcsupport/src/statvfs.c. This file contains the public statvfs() function, which takes in a logical path and a pointer to the struct statvfs. The core logic of this function is to resolve the logical path to a mount point and then delegate the actual work to the appropriate file system's statvfs implementation.

Internally, statvfs() uses rtems_filesystem_eval_path() to resolve the given path and determine which mounted file system is responsible for handling it. Once the node and mount point are identified, the call is passed to the specific filesystem’s statvfs_h handler, which fills out the statvfs struct accordingly.

However, at the time I began working on this, the IMFS file system in RTEMS had no implementation for the statvfs operation. The statvfs_h function pointer in its mount table entry structure was left as rtems_filesystem_default_statvfs, which means any attempt to call statvfs() on an IMFS path would result in an ENOSYS (Function not implemented) error.

My task was to implement this missing handler for IMFS.

To begin with, I studied how other filesystems, such as ext2. The implementation required tracking and computing block-related statistics for the in-memory filesystem. Since IMFS doesn't persist to disk, many of its values had to be either derived from internal allocation counters or hardcoded to reflect system constraints.

Some challenges included determining how to represent f_blocks and f_bfree in a memory-based file system. 

The implementation itself was added to the IMFS source code under cpukit/libfs/src/imfs. Once implemented, I built RTEMS and tested my changes using a small application psximfs01 that creates files in IMFS and calls statvfs() on created file path. This verified that the values were reasonable and dynamically updated as files were added or removed.

In my next blog post, I’ll go into further detail about how exactly the IMFS_statvfs function was implemented. Until then, thank you for reading!