Free chunk list
This commit is contained in:
		
							parent
							
								
									af21da0fe1
								
							
						
					
					
						commit
						e70be2c638
					
				
					 1 changed files with 13 additions and 5 deletions
				
			
		|  | @ -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<u64>; // Index of free chunks | ||||
| 
 | ||||
| struct Location { | ||||
|     partition: Uuid, // Partition identified via Uuid | ||||
|     chunks: Vec<u64>, // 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. | ||||
|  |  | |||
		Loading…
	
		Reference in a new issue