vore microcomputers logo

Filesystems and APM: Week 1 of VoreStation Development


written by Niko Chow-Stuart (Lead Developer)

drawing of the vap mascot in a drawer with two manila folders to the right

a large part of almost every operating system is its interface with storage mediums, and in almost all modern operating systems, this is done through a filesystem. this presents an impactful choice for the design of vap: what filesystem should we use?

initially, we were planning on using the ext2 filesystem. it's relatively simple, pretty well-designed for UNIX-like systems, and is also one of the only filesystems on the OSDEV wiki with an article containing enough information to actually implement it. however, while an implementation of ext2 was being worked on at first, it was quickly discovered that some of the design choices made in ext2 were not ideal for a new operating system, mainly the apparent lack of support for 64-bit POSIX time (which i cannot actually confirm, as i've seen conflicting information on this).

this led us to consider the berkley fast filesystem (ffs), which is a filesystem based upon the UNIX filesystem (UFS) used in BSD. it's main advantage over standard UFS is that it tries to allocate data more efficiently according to a physical hard disk layout, and also beats ext2 by having support for 64-bit POSIX time. however, while we were once again initially considering to use this filesystem, we decided against it as the documentation for it is very sparse, and all the implementations of it that we could find are very fine-tuned to the operating systems they were designed for (leading to how they're often referred to as "FreeBSD FFS" or "NetBSD FFS").

after this, we decided to finally cave in and design our own filesystem. as this is a very large task, we've estimated that this may add a week or two onto the total development time of vap, but we believe that it will be worth it in the end. as the filesystem is heavily based off of the ideas of UFS, we've decided to currently refer to it as VapUFS (which may not be the final name), and in the true style of UNIX, VapUFS carries the UFS name while not necessarily being compatible with any of the other UFS implementations! the main differences between VapUFS and standard UFS implementations are that VapUFS by default journals all writes and stores directory contents in a b-tree. we may at some point change journaling to be more efficient as i am concerned about the potential performance impact of journaling everything, however we're planning to continue with these ideas until we can get a proper implementation that we can benchmark.

as our work-in-progress implementation of VapUFS is not yet finished, the git repository hasn't been published. however, it will likely be public soon (possibly some point this week) and i'll leave an addendum here when it is.

in other news, we've also gotten our implementation of the Apple Partition Map (APM) working! it will likely be made public along with the release of VapUFS, however it's currently not in a state where we're confident in its stability, so we're going to hold off on publishing it for now. we're also planning on working on a block device interface extension for our Rust OpenFirmware API, which will allow us to actually test our filesystem implementation on real hardware, which will be very exciting! i personally have a bit of experience with block devices on OFW, so i'm hoping that this will be a fairly quick task.

that's all for the development progress of vap so far! i'm hoping that i'll be able to publish these blog posts on a weekly basis, however i'm not sure if i'll be able to keep up with that schedule. i should mention that as i'm currently the only developer working on vap, there may be some delays in the coming week as i'm expecting to be fairly busy with other things. otherwise, i'll hopefully be writing another post next week!

image of xenia, an anthropomorphic fox who was a contender for the linux mascot image made by @cathodegaytube!