More filesystem design stuff

main
~erin 2023-04-17 21:26:02 -04:00
parent 1eacd4683d
commit 04140376fa
Signed by: erin
GPG Key ID: 9A8E308CEFA37A47
2 changed files with 19 additions and 14 deletions

View File

@ -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 - [ferrite](https://git.lavender.software/mercury/ferrite-kernel) - The core microkernel code
- [hermes]() - The package manager - [hermes]() - The package manager
- [meteor]() - The [actors](/development/design/actor.md) library/implementation - [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 - [pulsar]() - Networking code
- [photon]() - GUI library - [photon]() - GUI library

View File

@ -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. 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. 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 ## Filesystem Layout
### Partition ### Partition
A virtual section of the disk. 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. It's identified simply by numerical order.
- **DATA Partition:** Fixed-size partition containing misc. *Actor* data
- **USER Partition:** Contains all data from the `User` [namespace](/development/design/actor.md#namespaces)
```rust ```rust
enum PartitionLabel { const BOOT_SIZE: u64; // How large the BOOT partition will be
Boot, const LABEL_SIZE: u64; // Number of characters that can be used in the partition label
Data,
User,
}
struct PartitionHeader { 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 num_chunks: u64, // Chunks in this partition
} }
``` ```
### Chunk ### Chunk
Small pieces that each partition is split into. Small pieces that each partition is split into.
Contains fixed-length metadata (checksum, dates) at the beginning, and then arbitrary data afterwards. 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 metadata lists this. 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 ```rust
const CHUNK_SIZE: u16; // Example static chunk size
struct Chunk { struct Chunk {
checksum: u64, checksum: u64,
extends: bool, 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*. 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. 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 ### Reading
On boot, we start executing code from the beginning of the disk (the boot partition, although that's meaningless at this point). 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). 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).