Filesystems and APM: Week 1 of VoreStation Development
2023-07-30
written by Niko Chow-Stuart (Lead Developer)
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 made by @cathodegaytube!