More filesystem design stuff

src/development/design/README.md

@@ -34,6 +34,6 @@ Most of the code will be implemented as libraries, enabling for them to be used
 - [ferrite](https://git.lavender.software/mercury/ferrite-kernel) - The core microkernel code
 - [hermes]() - The package manager
 - [meteor]() - The [actors](/development/design/actor.md) library/implementation
-- [gravitas]() - The library for working with [storage](/development/filesystem.md)
+- [gravitas]() - The library for working with [storage](/development/design/filesystem.md)
 - [pulsar]() - Networking code
 - [photon]() - GUI library

src/development/design/filesystem.md

@@ -12,42 +12,47 @@ I don't want to provide a simple filesystem interface to programs like **UNIX**
 Instead, all data should be just stored in *actors*, then the actors will decide whether or not they should be saved.
 They can save at any time, save immediately, or just save on a *shutdown* signal.
 
-Therefore, the "filesystem" code will just be a library that's simple a low-level interface for actors to use.
+Therefore, the "filesystem" code will just be a library that's simple a low-level interface for the `kernel` to use.
+*Actors* will simply make requests to save.
 
 
 ## Filesystem Layout
 ### Partition
 A virtual section of the disk.
-- **BOOT Partition:** Fixed-size partition at the beginning of the disk, containing the kernel code, and info about the other partitions.
-- **DATA Partition:** Fixed-size partition containing misc. *Actor* data
-- **USER Partition:** Contains all data from the `User` [namespace](/development/design/actor.md#namespaces)
+It's identified simply by numerical order.
 ```rust
-enum PartitionLabel {
-    Boot,
-    Data,
-    User,
-}
+const BOOT_SIZE: u64; // How large the BOOT partition will be
+const LABEL_SIZE: u64; // Number of characters that can be used in the partition label
 
 struct PartitionHeader {
-    label: PartitionLabel,
+    boot: bool, // Boot flag
+    label: [char; LABEL_SIZE], // Human-readable label. Not UTF-8 though :/
     num_chunks: u64, // Chunks in this partition
 }
 ```
 
 ### Chunk
 Small pieces that each partition is split into.
-Contains fixed-length metadata (checksum, dates) at the beginning, and then arbitrary data afterwards.
-If the saved data exceeds past a single chunk, the metadata lists this.
+Contains fixed-length metadata (checksum, extension flag, uuid) at the beginning, and then arbitrary data afterwards.
+If the saved data exceeds past a single chunk, the `extends` flag is set.
+
+Additionally, it has a **UUID** generated via [lolid](https://lib.rs/crates/lolid) to enable identifying a specific chunk.
+
 ```rust
+const CHUNK_SIZE: u16; // Example static chunk size
+
 struct Chunk {
     checksum: u64,
     extends: bool,
-    data: [u8; 512],
+    uuid: Uuid,
+    data: [u8; CHUNK_SIZE],
 }
 ```
 This struct is then encoded into bytes and written to the disk. Drivers for the disk are *to be implemented*.
 It *should* be possible to do autodetection, and maybe for *Actors* to specify which disk/partition they want to be saved to.
 
+Compression of the data should also be possible, due to `bincode` supporting [flate2](https://lib.rs/crates/flate2) compression.
+
 ### Reading
 On boot, we start executing code from the beginning of the disk (the boot partition, although that's meaningless at this point).
 The `kernel` then reads in bytes from the first partition *(as the **BOOT** partition is fixed-size, we know when this starts)* into memory, serializing it into a `PartitionHeader` struct via [bincode](https://lib.rs/crates/bincode).