ed/TimothyLottes.github.io
1
0
Fork 0
mirror of https://github.com/gomson/TimothyLottes.github.io.git synced 2026-08-04 14:48:49 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add files via upload

Browse Source
This commit is contained in:
TimothyLottes
2016-11-12 21:48:29 -05:00
committed by GitHub
parent bec646c367
commit 17793d2b31
2 changed files with 49 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
20151021.html
+48
View File
@@ -0,0 +1,48 @@
<html><head><link rel="stylesheet" href="style.css"></head><body><div class="page">
<h1>20151021 - Thoughts on Minimal Filesystem Design</h1>
<br>
<i>One of the problems that modern systems have which I suspect a minimal single user system would not have is ultra high file counts in a file system.
I make this statement under the grounds that minimal design is carried out through the system from OS through applications.
There is a practical limit to either the amount of "things" consumed by an individual or produced by an individual.
Also when quantity becomes ultra high, often it is better to have application manual packing instead of splitting "things" into separate files.</i>
<br>
<br>
<b>Goals</b>
<br>
Minimal design as always.
Files are always linear (no fragmentation).
Files written in groups as a linear stream can be re-read as a linear stream (no seeks between files).
Only one seek (one write) to finalize (in storage) adding of a file entry (or group of entries) to the file system.
Writing or reading to a file that has an existing entry, only costs the read/write (no extra metadata modifications).
<br>
<br>
<b>Simplifying</b>
<br>
Storage device split into two regions: path stack (starts at the beginning of the device), and file stack (starts at the end of the device, grows towards the path stack).
When a device is mounted (aka opened),
the path stack is loaded into RAM and remains in RAM.
This contains the entire filesystem structure.
The path stack contains {path of file, offset of file on device, size of file on device, deleted flag}.
Files are created by adding an entry to the top of the path stack,
allocates room for the file on the top of the file stack.
Files are deleted by just marking the delete flag.
Files are moved or renamed by changing the path in the file entry.
Files can be resized smaller by adjusting the size entry.
When the path stack or the drive fills up,
either clone the device (empty device fills fully compacted),
or run a local compaction.
Minimal OS runs 100% in RAM anyway so drive crunching away compacting after long time of usage is not a problem IMO.
<br>
<br>
Challenge to conventional design: why bother with organizing file structure in storage to match directory structure?
RAM and compute (to keep organized forms in RAM) is super cheep.
Complexity is super expensive.
So just load the complete file structure (path stack) into memory on mount.
Then create acceleration structures to serve basic access patterns.
Hash table (key = path, value = index to path stack entry) when the application knows name of file to open, etc.
</div></body></html>
index.html
+1
View File
@@ -111,6 +111,7 @@ and attempting to restore what I can from prior lost images.
<a href="20151113.html">20151113 - Rethinking the Symbolic Dictionary</a><br>
<br>
<a href="20151025.html">20151025 - Finer Points of Living in the Raleigh North Carolina Area</a><br>
<a href="20151021.html">20151021 - Thoughts on Minimal Filesystem Design</a><br>
<br>
<a href="20150930.html">20150930 - Tonemapping and Slot Mask Simulation</a><br>
<a href="20150915.html">20150915 - Bacon Wrapped Sour Cream</a><br>