+
+ 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!
+ 
-
-