From e70be2c63882bbd365600935f46cb250aceac9da Mon Sep 17 00:00:00 2001 From: Erin Abicht Date: Thu, 20 Apr 2023 17:26:40 -0400 Subject: [PATCH] Free chunk list --- src/development/design/filesystem.md | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/src/development/design/filesystem.md b/src/development/design/filesystem.md index 404a5da..c404073 100644 --- a/src/development/design/filesystem.md +++ b/src/development/design/filesystem.md @@ -105,7 +105,7 @@ Also, we are able to verify data. Before passing off the data, we re-hash it usi If it does, we simply pass it along like normal. If not, we refuse, and send an error [message](/development/design/actor.md#messages). ### Writing -Writing uses a similar process. An *Actor* can request to write data. If it has proper capabilties, we serialize the data, allocate a free chunk[^free_chunk], and write to it. +Writing uses a similar process. An *Actor* can request to write data. If it has proper capabilties, we serialize the data, allocate a free chunk, and write to it. We *hash* the data first to generate a checksum, and set proper metadata. ### Permissions @@ -119,12 +119,15 @@ will be determined via [capabilities](/development/design/actor.md#ocap) ### Indexing Created in-memory on startup, modified directly whenever the filesystem is modified. It's saved in the *Index Sector* (which is at a known offset), allowing it to be read in easily on boot. -It again simply uses `bincode` and compression. The index is simply an `alloc::` [BTreeMap](https://doc.rust-lang.org/stable/alloc/collections/btree_map/struct.BTreeMap.html). +We also have a simple `Vec` of the chunks that are free, which we modify in reverse. + ```rust -let mut index = BTreeMap::new(); +let mut index = BTreeMap::new(); // Basic Actor index +let mut free_index = Vec; // Index of free chunks + struct Location { partition: Uuid, // Partition identified via Uuid chunks: Vec, // Which chunk(s) in the partition it is @@ -136,9 +139,16 @@ let new_data_location = Location { } index.entry(&actor.uuid).or_insert(&new_data_location); // Insert an Actor's storage location if it's not already stored +for i in &new_data_location.chunks { + free_index.pop(&i); // Remove used chunks from the free chunks list +} + index.contains_key(&actor.uuid); // Check if the index contains an Actor's data index.get(&actor.uuid); // Get the Location of the actor index.remove(&actor.uuid); // Remove an Actor's data from the index (e.g. on deletion) +for i in &new_data_location.chunks { + free_index.push(&i); // Add back the now free chunks +} ``` This then allows the index to be searched easily to find the data location of a specific `Uuid`. @@ -179,5 +189,3 @@ struct PackedExecutable { ``` [^encryption]: Specific details to be figured out later - -[^free_chunk]: Need to figure out how to efficiently do this. **XFS** seems to just keep another index of free chunks. It also uses a **B+Tree** rather than a hashmap - to look into.