cbloodsworth commented 1 week ago

Semantics

TBF will refer to "The Big File", or the file on disk storing our system. Additionally, in the context of our file system, when I say "file", I mean either a file or a directory, as they should be interchangeable.

Background

The way that typical Unix implements their filesystem is a lot different than what we have. We hold the entire filesystem in memory, which is a great first start. However, when we transition to storing the filesystem on-disk, we will want to be smart about how what data we load, and when we load it.

I-nodes

Linux uses an abstraction called i-nodes to represent files. An i-node can be thought of as just a struct with a file's metadata, and a pointer to where its data can be found in TBF. Each i-node is actually stored on-disk in its own section -- this way, we can load a filesystem from TBF, and keep the data persistent between sessions.

The Big File (TBF)

The file on disk stores all our files and metadata -- this is an overview of what it looks like.

Directories

Okay, so an i-node has metadata and points to a file on disk. What about directories? As it turns out, a directory is just a file! On disk, it stores the filenames and i-node IDs of its children.

What needs to be done

This issue is a bit broad, but ideally at the end of this we will be able to use FileSystemAPI nearly exactly how we have been previously, except that it will make calls to Disk, our abstraction over TBF. The implementation of FileSystemAPI may be very different, as we won't be holding the entire tree in memory -- but the API should remain at least similar.

TODO: Add more

JacobNickerson commented 4 days ago

This issue sucks, closing for >:(