Vore_Microcomputers/website
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

add btrees_and_refactoring post

Browse source
This commit is contained in:
husky 2023-09-10 19:10:51 -07:00
parent d8fa817589
commit dc56099ed5
No known key found for this signature in database
GPG key ID: 6B3D8CB511646891
2 changed files with 113 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

BIN
blog/posts/btrees_and_refactoring/btrees.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 7.7 KiB

113
blog/posts/btrees_and_refactoring/index.html Normal file
View file

@ -0,0 +1,113 @@
<html lang="en">
<head>
<title>vore microcomputers development blog - B-Trees and Refactoring: Week 4 of VoreStation Development</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<link rel="stylesheet" href="/microsoft.css"/>
<link rel="icon" type="image/x-icon" href="/favicon.ico">
</head>
<body>
<div class="container">
<div class="container-item">
<a href="/"><img src="/assets/logo_typeset.svg" alt="vore microcomputers logo"/></a>
<h1>B-Trees and Refactoring: Week 4 of VoreStation Development</h1>
<h5>2023-09-10</h5>
<h4>written by Niko Chow-Stuart (Lead Developer)</h4>
<img src="/blog/posts/btrees_and_refactoring/btrees.png" alt="drawing of the vap mascot laying on their stomach, watching a tree sapling grow"/>
<p>
so, depending on how many people reading this are experienced in either filesystem design or osdev in
general, some of you may have seen this coming. i've decided to scrap the "infinite indirect blocks" design
as it was way too complex and was adding a lot of hard-to-read code to the implementation. instead, i've
gone with a more conventional design of having a fixed number of indirect blocks.
<br/>
<br/>
within each inode, there are 32 fields for direct blocks, single indirect blocks (pointer to a block of u64
pointers that point to datablocks), and double indirect blocks (pointer to a block of u64 pointers that
point to single indirect blocks), followed by triple, quadruple, quintuple, and sextuple indirect blocks
(which i hopefully don't need to explain). this means that the maximum file size (assuming the minimum
block size of 2048 bytes, where each block can contain 256 (2048/8) addresses) is roughly
(32 + 256 + 256^2 + 256^3 + 256^4 + 256^5 + 256^6) * 2048 bytes, or 526300 terabytes.
<br/>
although this is a phrase that many in the past have said and regretted, i think that's probably a good
enough maximum file size.
<br/>
<br/>
this has massively simplified the codebase, and while my implementation of this design is a bit rushed,
it is way more readable than the previous design and can more easily be refactored later on to simplify the
code. one of the main ideas for refactoring later on would be to add an iterator for list blocks so that
i wouldn't need to copy-paste the same code for reading/writing a series of blocks, as this is currently
one of the main sources of code length in the filesystem (which can be seen by the amount of enclosing
brackets used so that i can collapse those sections in my IDE). this would likely be either preceded
or followed by an update to move a lot of stuff out of the main `lib.rs` file, as this file is way too long
and not easily readable.
<br/>
<br/>
the main other thing that was worked on in the last two weeks was the implementation of b-trees. very
early on, i made the decision to separate the b-tree code from the filesystem as that would greatly
simplify running tests on the b-tree code during development, as well as allowing for said code to be
easily reused if needed. the b-tree code is currently quite simple, being heavily based upon the example
code from geeksforgeeks.org (which i believe is either public domain or CCBY-SA, i'm not sure as their
website is awful to browse if you don't want to make an account, and their legal information is spread out
weirdly). currently, the b-tree implementation only supports insertion, searching, deleting, and ordered
listing. this should hopefully be enough for the filesystem, however i'll likely need to either add more
functionality in the future, or at least refactor the code to be less C++-like (as quite a bit of it is -
as stated before - a somewhat hacky manual conversion of the C++ code from geeksforgeeks.org).
<br/>
<br/>
i've also started to hook the b-tree code into the filesystem code somewhat, it is still very much a
work-in-progress effort as i started writing it before i had finished the b-tree code, and as such, i
have not added a deletion wrapper yet. this will likely be done in the coming weeks, and hopefully
shouldn't take too long. hopefully, i may even be able to get a basic FUSE demo running within that
timeframe as well, as i feel like i've spent way too long working on this filesystem driver and haven't
even written a single blog post about anything else. once the filesystem is complete, i'll likely start
working on both ELF binary loading and basic memory management for the vap kernel, which means that i'll
probably be able to get a somewhat bootable operating system soon!
<br/>
<br/>
by the time this blog post is up, the updated source code for the filesystem should be available on our
<a href="https://git.voremicrocomputers.com">git server</a>, and hopefully the b-tree code should be posted
as well!
<br/>
<a href="https://git.voremicrocomputers.com/voremicrocomputers/vap/vapfs/vapfs_ufs">filesystem git</a><br/>
<a href="https://git.voremicrocomputers.com/voremicrocomputers/vap/ondisk_btree">b-tree git</a>
<br/>
<br/>
and that's about it! very big thanks to the person who donated $20 to us on LiberaPay this week, it's
very much appreciated! if you want to donate to us, you can do so on our LiberaPay here:
<br/>
<script src="https://liberapay.com/voremicrocomputers/widgets/button.js"></script>
<noscript><a href="https://liberapay.com/voremicrocomputers/donate"><img alt="Donate using Liberapay" src="https://liberapay.com/assets/widgets/donate.svg"></a></noscript>
<br/>
<br/>
other than that, i'll see you all next week! happy voring!
</p>
<hr/>
<p id="footer">
<br>contact us at <a href="mailto:nikocs@voremicrocomputers.com">nikocs@voremicrocomputers.com</a> <a
href="/pgp.asc">pgp key</a>
<br>
for abuse, copyright, or other legal issues, contact <a href="mailto:devnull@voremicrocomputers.com">devnull@voremicrocomputers.com</a><br>
<!-- or, call at <a href="tel:1-888-519-0437">+1 (888) 519-0437 (toll-free)</a> or <a href="tel:1-507-767-9433">+1 (507) RMS-YIFF (local)</a> -->
(our phone system is currently down, sorry!)
<br><br>
Vore Microcomputers is an unregistered trademark of Real Microsoft, LLC. all references to "the company"
are in reference to Real Microsoft, LLC and the name Vore Microcomputers is only a reference to the
hardware/software focused development project held under Real Microsoft, LLC. Real Microsoft, LLC is
in no way associated with the Microsoft Corporation or its products/projects.
<br><br>
<a href="https://climate.stripe.com/4MO1d9">Our Carbon Footprint</a>
</p>
</div>
<div class="container-item">
<div class="credit">
<img src="/xenia.png" alt="image of xenia, an anthropomorphic fox who was a contender for the linux mascot"/>
<span>image made by <a href="https://twitter.com/cathodegaytube/">@cathodegaytube</a>!</span>
</div>
</div>
</div>
</body>
</html>