Earlier this year, two friends and I set out to build a UNIX-based OS for a RISC-V processor. Delegating the work amongst us left me primarily working on the file system for the operating system.
The file system I designed and built was based on the ex2 file system. Introduced in 1993, ext2 (second extended file system) was a widely used Linux file system until roughly the year 2000, after which it was replaced by its successors.
Ext2 organizes the disk into block groups to minimize fragmentation. These block groups are, in turn, managed by indirect nodes, or “inodes”, which provide a system to organize, point to, and relate data blocks. To support the file system, I also created a write-through cache to allow for efficient reads and writes.
Due to the complex nature of the file system, its implementation alone ended up spanning almost 2000 lines of code. Combined with the intricacies of the rest of the operating system and the fact that the file system was the backbone for the actual execution of processes, meant that the file system’s reliability was of the utmost importance.
Though I knew this, robustly testing the file system to the extent of use that it would see in practice proved a challenge nonetheless. In a few instances, what I thought to have been complete testing turned out to have gaps in it. Problematically, this was only discovered after painfully debugging the whole system, since the issues appeared to be from other components. Working on the file system thus greatly improved my skills when it came to testing, maintaining, and documenting sizable codebases.
Leave a comment