mercury/book
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Activity

More filesystem ideas

Browse source
This commit is contained in:
~erin 2023-04-19 13:25:58 -04:00
parent b25983dcd6
commit 20bff5af7e
Signed by untrusted user: erin
GPG key ID: 9A8E308CEFA37A47
1 changed files with 12 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17
src/development/design/filesystem.md
View file

@ -17,14 +17,21 @@ Therefore, the "filesystem" code will just be a library that's simple a low-leve
## Filesystem Layout
| Name | Size | Header |
|------|------|--------|
| Boot Sector | `128` | `None` |
| Kernel Sector | `1024` | `None` |
| Config Sector | `u64` | `PartitionHeader` |
| User Sector(s) | `u64` | `PartitionHeader` |
### Partition
A virtual section of the disk.
It's identified simply by numerical order.
```rust
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
const LABEL_SIZE: u16; // Number of characters that can be used in the partition label
let NUM_CHUNLKS: u64; // Number of chunks in a specific partition
let NUM_CHUNKS: u64; // Number of chunks in a specific partition
struct PartitionHeader {
boot: bool, // Boot flag
label: [char; LABEL_SIZE], // Human-readable label. Not UTF-8 though :/
@ -63,8 +70,8 @@ Compression of the data should also be possible, due to `bincode` supporting [fl
Similarely **AES** encryption can be used, and this allows for only specific chunks to be encrypted.[^encryption]
### 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).
On boot, we start executing code from the **Boot Sector**. This contains the assembly instructions, which then jump to the `kernel` code in the **Kernel Sector**.
The `kernel` then reads in bytes from the first partition *(as the sectors are fixed-size, we know when this starts)* into memory, serializing it into a `PartitionHeader` struct via [bincode](https://lib.rs/crates/bincode).
From here, as we have a fixed `CHUNK_SIZE`, and know how many chunks are in our first partition, we can read from any chunk on any partition now.
On startup, an *Actor* can request to read data from the disk. If it has the right [capabilities](/development/design/actor.md#ocap), we find the chunk it's looking for[^find_chunk], parse the data (using `bincode` again), and send it back.