CO620 R ESEARCH P ROJECT

T ECHNICAL R EPORT

A File System in Erlang

James Forward

jf352@kent.ac.uk

supervised by
Professor Simon Thompson

March 30, 2017

 A File System in Erlang
James Forward
Department of Computer Science
University of Kent
Canterbury, England
jf352@kent.ac.uk
Abstract—Although there is no lack of number
and variety of file systems, new file systems must be
written to keep up to date with changing software
and hardware requirements. One such project is the
HydrOS project, developed at the University of Kent,
which is a multikernel OS, written entirely in Erlang,
designed to withstand complete software failure. Much
like any other OS, it requires a file system in order
for it to store and retrieve data. This report details the
background, design, development and functionality of
HydroFS, a file system written entirely in Erlang for
HydrOS, and how it can be extended in the future to
take full advantage of storage space.
I. I NTRODUCTION
S Dominic Giampaolo writes in his book
A Practical File Systems, a guide to designing
and implementing file systems, ”The main purpose
of computers is to create, manipulate, store, and
retrieve data” [1]. Because of this, every computer
Operating System (OS) needs a designed file system
to be able to fulfill the function of permanently
storing and retrieving data from a storage medium.
Although there are many file systems already in
existence, and most consumers have little to worry
about when deciding which file system to store
their everyday data on, when developing new OSs a
choice has to be made whether to adopt one of these
and restrict the functionality of the OS by abiding
by its limitations, or to develop a new file system
which, whilst requiring much more development
time than a simple driver, provides complete control
over the storage and retrieval mechanisms that the
OS can take full advantage of.
This report focuses on a proposal solution for
HydrOS, a research OS developed at the University
of Kent. It will begin by providing a background to
the language that the solution (and HydrOS itself)
is written in, and an explanation of how the OS
functions and what sets it apart from traditional OSs.
It will then move on to explain the motivation behind
1
the decision to develop a new file system rather
than rely on an already existing one, by weighing
up the pros and cons of both possibilities. It will
then move on to establish the aims of the proposed
file system, as well as the implications these aims
have on performance and storage space. The report
will then discuss the development of the file system
over time, and a complete explanation of how the file
system functions within the HydrOS environment.
It will then discuss how the structure of the file
system lays the groundwork for the further devel-
opment mentioned in the aims, with the goal of fully
achieving the stated aims and delivering a unique
Erlang-based file system which can be utilised inside
HydrOS.
II. BACKGROUND
A. Erlang
Erlang is a concurrent, functional programming
language developed in the 1980s by Ericsson.
Written by a small division of employees at
Ericsson with the intent to improve the way that
Telecom applications are developed [2], Erlang has
since become a majorly adopted language by a
wide variety of companies, such as Amazon for
their SimpleDB distributed database, Facebook
for their WhatsApp messaging service (although
this was adopted before the takeover), Yahoo for
the bookmarking service ”Delicious” among many
others.
The reason for Erlang’s adoption in these areas
are due to its features which separate it from other
languages. Its ability to be both fault-tolerant and
largely scalable is an incredibly useful feature to
have in the contexts it is usually deployed. Other
than these settings, however, it also has merit in the
usage as the foundation of an operating system.
B. HydrOS
The Erlang BEAM - the virtual machine on top
of which Erlang code is processed - also includes
typical Operating System functionality such as
process management, memory management and
scheduling. As a result of these features, alongside
the scalability and fault-tolerance of Erlang already
mentioned, this led to its adoption in HydrOS, a
research OS developed at the University of Kent
which intends to utilise these factors to provide
a system capable of tolerating both software and
partial hardware failure.
The operating system uses the multikernel
model to ”seperate a multicore computer into a
set of individual computing nodes, each capable of
withstanding the failure of the others” [3]. Each
node has its own kernel, and memory is not shared
between the nodes. Data and tasks are, therefore,
shared using Erlang’s message passing functionality
instead. Tasks are distributed across the cores,
with each of the nodes acting together as a virtual
network.
C. The need for a file system
Like all Operating Systems, data in HydrOS needs
to permanently be stored and retrieved by the user.
Since the OS is written from the ground up, and
not a fork of an already existing OS, it does not by
default include compatibility with previously existing
file systems such as NTFS, EXT4, FAT, or any other.
This means that, to accomplish the aim of
permanent data manipulation, one of two possibilities
has to be realised. The first possibility is the creation
of a custom driver for an already existing file
system. The second is the creation of an entirely
new file system, in addition to a driver for the
operating system to support it. This section of the
report will consider the pros and cons for both
cases, and come to a conclusion which explains why
ultimately, developing a new file system was the
chosen path. The report will then explain the way
in which the file system was is designed.
The advantages of creating a driver for an already
existing file system are immediately clear.
Firstly, by doing so, already existing data storage
mediums will not need reformatting (or other
necessary reconfiguring) in order to be able to
2
access the files stored on the disk. Not requiring the
user to reformat a storage medium in order to be
able to use it as part of a functioning system is a
major convenience - it requires less set up time, and
less effort.
Secondly, development time of writing a file
system driver, as opposed to designing a brand new
file system (and then having to write a driver for it),
is much lesser. Once the driver has been completed,
assuming it was done correctly, OS development can
turn to other matters; such as actually utilising the
file system in built-in and custom-made applications,
designing a graphical user interface for the user to
be able to use it, and so on.
This is not to say that writing a device driver is
a perfect solution, however. Since the developer has
had no say in the design, existing file systems may
not be able to take advantage of features of the OS,
or modern hardware running it. For example, FAT32
would not be a good fit for someone storing 4K
movies due to the 4GB size limit. EXT4 would not
be a good fit for someone concerned about security,
as even when ”securely deleting” files, sensitive
metadata remains on the disk[4]. Developing a
custom file system allows complete control over
what features are needed, as there is no need to
comply with previously existing limitations.
Besides the ability to implement features decided
ahead of time, another positive of developing a file
system from scratch is that as development goes
on, experimentation can lead to innovation that
was otherwise not considered. Since, as Giampaolo
points out, there isn’t a single ”correct” way of
writing a file system,[1], the possibilities in this
project are endless. Also, the learning experience
gained from designing and implementing a custom
file system is much greater than taking somebody
else’s work and adapting it.
Due to the time scale of the research project
meaning that results were not required ”as soon as
possible”, the option to design a new file system was
chosen for the learning experience, flexibility, and
desire to create a unique file system to match the
unique OS.
III. A IMS
The aims of the project can be described in
2 groups - ’core’ and ’extended’. Core aims are
the fundamental aims of the file system that are
implemented by the end of the development cycle.
Extended aims are not necessarily in the scope of the
project due to time restrictions, but are future goals
for the file system, drawing upon the functionality
proposed and design provided in this report.
The core aims of HydroFS are as follows:
• Provide a user-level interface module with the
file system, and backend file server module to
serve requests.
• Maintain a file table which dynamically grows
as needed.
• Store and retrieve blocks of data from disk.
• Store and retrieve files that exceed sector size
from a disk, using a file name as a reference.
The extended aims of HydroFS are:
• Provide a directory system.
• Provide extra functionality such as copying files.
• Provide a search functionality for files.
• Provide an immutable file system, where mul-
tiple revisions of a file only use extra space to
save differences, rather than wasting space.
• Utilise multiple kernels for improved perfor-
mance.
IV. D EVELOPMENT
A. Researching design
File systems can be implemented in a number
of ways. Arguably the most important decision
to make, as it will have the largest impact on
performance and efficiency, is how the blocks are
stored on disk. The most common methods are
contiguous, linked, and indexed allocation of blocks.
Each of these different methods come with their
own set of advantages and disadvantages.
Contiguous allocation refers to storing blocks of
files sequentially. They operate alongside a file
table, which contains information about what sector
the first block is stored at, and its length. So, for
example, a file whose first block is stored at sector
600, and is 14 blocks long will exist from block
600 to 613.
This method contains a number of advantages.
As Edwin Reilly mentions in his book Concise
Encyclopedia of Computer Science, this makes
3
directly accessing specific parts of a file stored on
disk rapid[5]. A downside, however, is that creating
files and expanding existing ones is difficult. If there
is another file a few sectors in front, growing the
file requires moving the file to a new sector of the
disk and updating the file table. It can also lead to
external fragmentation, since despite the disk having
enough space to hold a new file of, for example,
3GB, this 3GB is spread across the disk rather than
being a free, contiguous space[6].
Linked allocation is where blocks are not necessarily
stored contiguously, and each stored block points
to the next one. An advantage of this is that
fragmentation is not an issue, since the file system
can store files that are larger than the largest
contiguous free space, which makes disk utilisation
more efficient. They are easy to implement[7]. A
disadvantage to linked allocation is that directly
accessing a specific part of a file on disk is
impossible, as read requests much be sequential
(since the information about what sector stores a
block cannot simply be calculated, nor is it explicitly
stored anywhere)[8]. Read speeds may therefore be
impacted.
Indexed allocation refers to a system where, like
linked allocation systems, files can be stored non-
contiguously. Instead of each block pointing to the
next one, however, a single block contains the list
of pointers. An advantage to this is that, like linked
allocation, fragmentation is not an issue. Secondly,
it also has the ability for direct access, since the
blocks are explicitly declared in the inode. However,
the pointer overhead of this system is larger than
the linked allocation system[9].
Ultimately, the decision was made to employ
a linked allocation system. Firstly, the ease of
implementation makes this a good choice for this
project. Secondly, the lack of direct access to blocks
for manipulation purposes are not an issue, since the
file system is aiming towards immutability (meaning
no blocks are directly edited).
B. Compiling and running
Upon beginning the research as to how the file
system would be developed, the first thing to do
was understand how HydrOS itself is compiled
and ran. As the HydrOS project website mentions,
crosstool-ng is first required to build a toolchain
for the x86 64-unknown-elf architecture, which
can then be ran using bochs[3][10][11][12]. This
is relatively straightforward, and are compiled by In terms of the file system, the user-level code and
using gcc’s make with the appropriate flags. The file server back-end sits on top of HydrOS, which
enable-smp flag is required to simulate a symmetric contains the ISA driver and kernel which directly
processing machine[13] and the enable-x86-64 flag operate with the hardware.
is required to add support for the x86-64 instruction
set[14] - both features which HydrOS requires.
Once these requirements are satisfied, the OS can be
compiled and run (assuming Erlang/OTP 19.0.2 or
higher is installed on the system) by downloading
the source code, and running make sim in the project
source’s root directory.

C. Issues encountered during development

Throughout the research project, a number of
issues arose. Firstly, for the majority of the time
spent on the research project, it was not possible to
get the OS to run under the virtualisation software
Qemu/KVM, which would have significantly
improved the performance. The reasons for this are
unclear, since by the end compiling and running
Qemu/KVM worked, as did running HydrOS under
it (through the use of virt-manager). The file system structure. Blue background = handled
by HydroFS code, green = handled by HydrOS
This problem did not affect the development
significantly, however, as another virtualisation
software, bochs ran HydrOS. The performance of
HydrOS was often frustrating but did not seriously
damage development. E. Front-end and back-end

Secondly, the entire project being implemented

inside a custom OS made testing and debugging
very difficult. Since the keyboard buffer would often
lock, using in-line commands on the OS’ terminal
input often failed. It required to have debugging
methods implemented inside the written modules in
order to test implemented functions.
The detailed code for both the user-level interface,
as well as the file server, can be found in the
appendix. This segment of the report will detail how
they function generally, rather than explaining each
line of code.

1) User-level interface: The first thing considered

D. System Architecture
HydroFS is implemented using 4 Erlang modules.
These are fs, os file server, null and init file server.
fs.erl is the module the user directly interacts with
to store and retrieve files. os file server is the
back-end module which contains the file system
logic. null is a small module which checks if a
binary is null (used for checking free sectors), and
if required, can create a 512-byte binary full of 0s
(which could be useful for secure delete operations).
init file server is a small module, which starts the
file server upon booting the OS.
was how the user would interact with the system.
HydrOS currently exists as a terminal-only OS, so
there is no graphical interaction. Despite this, it is
still necessary that the user can read and write data
in the simplest way possible.
The interface was implemented as fs.erl, which is
stored and compiled from the stdlib directory.
To write a file/term (the two terms are interchange-
able in the context of this file system), the user
simply calls from the command line:
fs:write(Term, Filename)

4

Writing a file in HydrOS using HydroFS.
This function passes a message to the back-end file
server (which is mentioned below), with the file to
write, as well as the filename to write to. The file
server then handles the logic, and the file is written.
To read a term from the file system, the user calls:
fs:read(Filename)
Reading a file in HydrOS using HydroFS.
2) Back end file server: This is initialised at
boot from the init file server.erl module in the
os init directory. Upon startup, it checks if a file
table exists on the disk and if so loads it into
memory - otherwise, it creates a new file table. The
file server functions by using message passing to
receive requests from the user interface, such as
”read” and ”write”, and operate accordingly. It is in
this module that the file table, and the logic which
determines what blocks to read/write to, is contained.
One benefit of the Erlang language and the file
system’s design is that, due to the server-client
model, changes to the logic of the back-end
have no impact on the file server. This means
that the interface and back-end can be developed
5
asynchronously. In fact, using the same code from
the earliest commit, the file system read and write
functionality in fs.erl still works - despite at the time
this was designed for reading/writing to memory
rather than disk.
The file server functions by spawning a process
which is continually listening for messages passed
to it by the user-level interface module. The process
contains three parameters, which operate as follows:
• Filetable - The list of files and where they are
stored
• Num - The next sector to attempt to write to
• Bucket - The current ”bucket” the user is in.
This is explained later in the report.
The interaction between the user level interface
and the file server works as follows. The server
spawns, and listens for requests - currently, there are
13 possible options (a few of which are only for
debugging purposes). This is the server’s listening
functionality:
receive
{msg, write, File, Filename, Caller} ->
end.
F. File table
The file table consists of two parts. The first is the
”file table info”, which sits at sector 0 of the disk.
This is a small file containing the starting sector
of the file table (by default set to sector 1), and
the total size of the file table binary. Upon the file
server starting up, the file server checks if the ”file
table info” sector is blank, or contains information.
In the case of the former, it means this is a new file
table which must be created, and proceeds to create
a new binary. Otherwise, it loads the information
about the file table into memory, and reads the file
table starting at the defined sector, taking account of
the total size of the file table if it exceeds 512 bytes
- in which case, it loads the appropriate number
of following sectors, and recombines them into a
single file table which is loaded into memory.
The usage of memory to store a file table, as
opposed to keeping it on disk and only reading as
required, is to allow extremely high-speed access.
This is in part inspired by the ”bullet server” aspect
of the file system of the distributed OS Amoeba[15],
which also has a focus on immutability. Unlike this
file system, however, HydroFS does not store the
entire file system in RAM - only the file table itself.
 The file table itself is a small list of file entries,
which contain as little information about the file as
required to function. Currently, it contains the file
name, the first sector to read, and the total size of
the file. The following shows an example of a file
entry:
This equates to a file named ”helloworld.txt”,
which is 2740 bytes, and whose first sector is sector
352.
The file table grows in size if the list exceeds 512
bytes, and the file table info sector is automatically
updated and written in this case. Because of this, be-
sides the arbitrary choice of choosing to start writing
user-level files at sector 300, there is theoretically
no limit on the amount of files that this system can
handle. Of course, due to the file table needing to be
loaded into RAM, memory limitations may become
an issue if an incredibly large number of files are
needed to be stored. However, since this would likely
happen on a system with lots of RAM in the first
place, it should not cause any significant limitations.
G. Storing and retrieving files
To write data to the disk, the write function in the
os isa module in the os drivers directory is used.
This module is not part of the HydroFS project, but
the functionality for basic storage I/O was created
by the developer of HydrOS. This function takes
two parameters - the sector number to write to (with
the cylinder address pre-defined in the module), and
a binary of exactly 512 bytes. As such, passing a
normal term to this function does not write data to
the disk.
an END/STOP flag.
1) Storing a file:
In HydroFS, storing a file uses an algorithm to
calculate what sectors to store its binary in, as well
as how to organise the pointers. The process is
relatively straight forward. Firstly, the user requests
to store a file using the fs:write(Term, Filename)
function. This sends a message containing these
parameters to the file server, which then converts the
term into a binary, pads it to the nearest multiple of
508, then breaks the binary into multiple 508-byte
smaller binaries. The number of binaries produced
from this are then stored in a local term. It then
checks the disk for the next free sectors (the same
amount of binaries), signs these sector numbers as
4-byte binaries, concatenates them with the data
blocks accordingly, and then writes them to these
sectors. A new file entry, as defined earlier, is
then added to the file table in memory as a tuple
containing the file name, the first sector number,
and the size of the term. The file table is then also
written to disk (and the file table information sector
updated accordingly), to ensure that on successive
boots the file is still accessible by the file name.
For example, consider a list of 231 integers. The
file size of the list, due to the numbers involved,
is 1162 bytes. The diagram on the following page
shows how HydroFS calculates where to store the
files, and how they are stored.

In os file server, a function called convfull exists

to ”convert” a term into a 512-byte binary. It does
this by converting the term into binary, and then
padding the data by adding 0s to the end using
a recursive function, padit. The way this function
works is detailed in the Appendix.

The ability to store and retrieve files that exceed

the 512-byte size of a sector has been implemented,
marking all core aims of the project as achieved.
As already mentioned, files are stored in a ”Linked
List” structure - the sectors that contain data also
contain pointers, located at the end of the block,
which tell the file server which sectors to load next.
This carries on until a block’s pointer bytes (which
are always the final 4) contain all 0s, which act as

6
7
 2) Reading a file:
HydroFS’ loading method.
The diagram above shows how the example file
mentioned in the Section V (File Table) would be
loaded by the file system using the linked list system.
The file table contains a pointer to the first sector -
in this case, sector 352. The data contents of sector
352 are loaded, and the last 4 bytes are examined.
In this case, as it would point to sector 353 next,
the final four bytes are 0,0,1,97, which is the four-
byte signed representation of this number. Sector 353
would contain 0,0,1,98, so would then point to Sector
354 being loaded next. The process continues until
sector 357’s contents are loaded, where the final four
bytes are 0,0,0,0, and so the process stops. The file
server then extracts the data portion of all loaded
blocks (the first 508 bytes), combines them into one
single binary, converts this back into a usable term,
and passes to the user through the user-level interface
fs.
H. Categorisation of files
Creating a directory-capable file system proved
to be a particularly difficult challenge throughout
the course of the development, and was sidelined
as a feature. However, an alternative system to the
orthodox method of handling file organisation was
eventually implemented.
HydroFS does not contain a ”typical” directory
structure. There are no records for directories,
in the same way a typical file system such as
NTFS or FAT32 uses. HydroFS’s file system is
completely flat, and is similar in design to Amazon
S3’s file system, which contains a ”bucket” system
8
for organising and grouping files. This is handled
entirely by string joining and parsing, and does
not require any additional records on the disk to
accomplish.
When HydroFS’s server process spawns upon the
OS booting, it is passed a String containing a ’/’.
The ’/’ character acts as a delimiter for separating
buckets, sub-buckets, and files. Therefore, at the
start of launching the OS, the user is in the root
folder.
Unlike folders in a traditional file system, which
are created independently from files, buckets are
created and destroyed dynamically, whenever files
are created or deleted.
For example, if the user decided to group files
under a bucket called ”files”, the user would then
go into that bucket by calling the following code:
fs:cb("/files")
This function is capable of processing both absolute
and relative paths - if prefixed by a ”/”, it is con-
sidered absolute. Otherwise, it will append the new
bucket to the working directory. In this instance, if
the user was in the root bucket (”/”), they could also
just type ”files” as a parameter, without the preceding
”/”. To store a text file containing ”Hello World!”,
currently in memory as Erlang term X, under the file
name ”mydoc.txt”, the user would call:
fs:write(X, "mydoc.txt")
The file table entry would contain the string
”/files/mydoc.txt”, as the bucket would be appended
to the beginning of the file (with the placement of
delimiters calculated by the server beforehand).
Whilst buckets primarily work as a replacement
for directories, they are also capable of being used
for primitive search functionality. The following is
an example list of files stored on the file system:
• ”/odds/1.txt”
• ”/evens/powsoftwo/primes/2.txt”
• ”/odds/primes/triples/3.txt”
• ”/powsoftwo/evens/4.txt”
• ”/primes/odds/5.txt
• ”/triples/evens/6.txt”
The files are organised based on the filename’s
number (the contents are unimportant to explain this
functionality). It is possible to find all files matching
certain criteria, by calling the fs:tagged function,
which takes a list of strings as a parameter.
Suppose the user wanted to filter all files that
can be categorised as ”odds”. The user would
call fs:tagged([”odds”]), and the file server would
process the instruction. Everything that is saved
with a matching bucket name of ”odds” would
have their full path returned. The order of the
buckets does not matter, so despite ”primes”
coming before ”odds” in the case of 5.txt, its path
(”/primes/odds/5.txt”) would be returned alongside
the paths for 1.txt and 3.txt. The user can also filter
multiple buckets at once. Suppose the user wants to
filter all files marked as ”odds” as well as ”primes”.
The user would call fs:tagged([”odds”,”primes”])
or fs:tagged([”primes”,”odds”]), and the paths of
both 3.txt and 5.txt would be returned.
I. Copying
The user can also copy a file so it can be ac-
cessed from multiple directories. The user calls the
fs:cp(Filename, Bucket) command, and a new file
table entry will be added for the appropriate bucket.
J. Immutability and the Patching System
As of the time of this report, due to time
limitations making this feature outside the scope of
the project, this aspect has not been implemented.
That said, the file system’s design, using the Linked
List loading system, has layed the groundwork for
this.
The patching system allows files to be revised/up-
dated, with the differences between the files saved
as patches, rather than as entirely new files in their
own right. To the user, this is completely transparent,
as the file server logic interprets them as complete
files to begin with, so no additional patching tools
are required.
To give an example of how this is planned to
work, consider the following scenario.
9
HydroFS’ patching method.
In the diagram above, a file of 6 blocks is saved to
sectors 352, 353, 354, 355, 356, and 357. In this
instance, the file is completely contiguous, and the
linked list loading method seems to have no impact
on loading. However, three different revisions of the
file are then made. The first revision is extra data
being added into the file, with nothing removed.
The amount of data being added is between 508
and 1016 bytes, requiring 2 blocks to be stored
(including pointer bytes).
The first block is saved at the next available sector,
which is sector 358, and contains the first 508 bytes
of the extra data. The second block is saved at the
sector after that, 359. The final four bytes of sector
358 point to sector 359, and tthe final four bytes of
sector 359 point back to sector 357. A new file table
entry is added, with the description of what pointer
should be overridden (in this case, 356 does not
point to 357 anymore but 358, so the patch would
be 356,358).
Since sectors 352, 353, 354, 355, 356 and 357 are
not actually modified, storing these files again in
new blocks appears to be a waste of storage space.
Using this method, only 2 new blocks are taken by
the first revision, rather than 6, meaning when this
method is implemented, a 66.6% saving in storage
space in this scenario.
The second revision of the file is the same as the
first but with additional data occurring at the end of
the block. In this case, sector 357 would not be the
end of the file, so the pointer data is overridden in
the file table, pointing to sector 360 instead. Sector
360’s block’s final four bytes are all 0, so the file
would terminate here.
The final revision includes both changes of the first
and second revision, so both overrides are listed in
the file table. This revision uses no extra data blocks
itself, so in this particular instance, excluding the
negligible space used by the file table entry, the
saving is 100%.
The diagram below shows what each file table
entry will end up loading.
not functioning due to compatibility problems, and
on another there was no keyboard input available.
These issues were not encountered when running the
system through bochs, which was what was used for
development testing throughout the process, since
the ability to run the OS at all under Qemu was
only possible near the end of the project.
It should be noted that the ”seconds” are seconds
as measured by the OS under bochs as this was
the only available ”benchmark” tool. Running the
OS under bochs leads to a significant performance
reduction, and so is not indicative of how the file
system would run directly on hardware or through
Qemu. Time was recorded running different numbers
of cores for the OS.

A. 2 cores
Write Performance (Seconds) - 2 cores
Size(in bytes) Measured Speed
508 0.001115957
1016 0.500850896
2032 1.501131014
4064 2.001798172
8128 3.003183701

Read Performance (Seconds) - 2 cores

Size(in bytes) Measured Speed
508 0.000061747
HydroFS’ loading method. 1016 0.000097891
2032 0.000158133
V. R ESULTS 4064 0.000284639
8128 0.000540663
All core features that were aimed to be
implemented in the project were successfully
implemented. In addition to this, a few additional B. 4 cores
features were implemented too, such as a directory Write Performance (Seconds) - 4 cores
structure (really a ”bucket” structure) for organising Size(in bytes) Measured Speed
files, the ability to move paths, and copy a file from 508 0.000311531
one location to another. 1016 0.000401273
2032 0.000578193
Time is recorded in seconds, using the system’s 4064 0.001984555
runtime to measure the time differential. Figures 8128 0.003784495
chosen based on the size of 1 block in HydroFS
(a 508 byte file is 512 bytes when considering the Read Performance (Seconds) - 4 cores
pointer block). Size(in bytes) Measured Speed
508 0.000032051
Results are shown running the system in bochs, 1016 0.000069231
rather than Qemu since running the OS with 2032 0.000121795
the functioning file system on Qemu was not 4064 0.000394859
possible. On one computer, the system’s I/O was 8128 0.000884598

10
C. 8 cores potentially be developed further, in order to reduce
Write Performance (Seconds) - 8 cores used storage space from files with multiple versions
Size(in bytes) Measured Speed using a patching system.
508 0.000154005
1016 0.000202007
ACKNOWLEDGMENT
2032 0.000286009
4064 0.000466015 The author is grateful to the project supervisor,
8128 0.000828105 Simon Thompson, who has on numerous occasions
provided great help focusing the direction of the
Read Performance (Seconds) - 8 cores project in meetings. The author would also like to
Size(in bytes) Measured Speed acknowledge Sam Williams, the developer of Hy-
508 0.000016001 drOS, for his advice for the project as well, and for
1016 0.000036003 creating the OS.
2032 0.000064005
R EFERENCES
4064 0.000112007
8128 0.000224015 [1] D. Giampaolo. Practical File System Design, 3rd ed.
San Francisco: Morgan Kaufmann Publishers, 1999.
Creating bigger files than 8128 bytes were not Pages 1 to 31.
possible at testing, due to the small amount of
memory per core. [2] J. Armstrong, Making reliable distributed systems in
the presence of software errors, PhD thesis, The
Royal Institute of Technology, Department of Micro-
Under operational circumstances the file system
electronics and Information Technology, Stockholm,
could, theoretically, provide around 57MB/s read Sweden, December 2003. Pages 1 to 7.
speed in bochs when running 8 cores. According
to the ISA driver at the moment, the maximum [3] S. Williams, Hydros Project. Hydros-project.org. N.p.,
read/write speed capable is 16MB/s, so this would Web.
limit it, and as such the ISA driver needs to be
improved [4] J. Corbet, Securely Deleting Files From Ext4 Filesys-
tems. .net. N.p., 2011. Web.
It is unclear whether the performance degradation
[5] E. Reilly. Concise Encyclopedia of Computer Science,
of bochs is why running on multiple cores the
1st ed. Chichester: John Wiley, 2004. Pages 580-582.
results are better (as the OS running generally faster
means that the system time value is more accurate), [6] J. Valvano. Embedded Microcomputer Systems. Cen-
or due to the design of HydrOS as a multikernel gage Learning, 2012. Pages 519 to 524.
OS. Further research is needed in this area, once the
OS can be run fully under Qemu/KVM. [7] R. Khurana. Operating System (For Anna). New
Delhi: Vikas Publishing House, 2011. Pages 191 to
215.
VI. C ONCLUSIONS
[8] Basics of OS, UNIX, and Shell Programming. New
In conclusion, the project has been successful. Delhi: Tata McGraw-Hill, 2007. Pages 20 to 31.
The project has been able to provide a functioning
file system with some advanced functionality. [9] I. Dhotre. Operating Systems. Technical Publica-
The project has laid the groundwork for the tions, 2008. Pages 10-1 to 10-12.
implementation of a truly immutable file system,
and can be developed from here into a fully-featured [10] ”Start [Crosstool-NG]”. Crosstool-ng.org. N.p.,
file system. Web.
There are still a number of areas which could be
[11] M. Schultz. Sample files for building crosstool-
improved, most notably the read/write performance NG cross-compilers for the Xinu platform, GitHub
of HydroFS. Currently, the speeds are not up to repository, https://github.com/xinu-os/ct-ng-samples
scratch for every day performance, however this
is mostly due to the limitations of the current [12] Bochs: The Open Source IA-32 Emulation Project
ISA driver. The design of the file system can also (Home Page). Bochs.sourceforge.net. N.p., Web.

11
[13] Simulating A Symmetric Multiprocessor (SMP) Ma-
chine. Bochs.sourceforge.net. N.p., Web.

[14] Compiling Bochs. Bochs.sourceforge.net. N.p., Web.

[15] P. K. Sinha. Distributed Operating Systems, 1st ed.

New Delhi: Prentice-Hall of India, 2001. Pages 642-
659.

[16] W. Gatliff. An Introduction To The GNU Compiler

And Linker, 1st ed. 2002. N.p., Web.

12
 A PPENDIX A.
D IAGRAMS

[H]
Figure 1: HydroFS’ file-loading method.

13
 [H]
Figure 2: HydroFS’ file-writing method.

14
Figure 3: How a ”Patched” revision would load.

15
Figure 4: How ”Patched” versions would look like
when reconstructed.

16
 A PPENDIX B.
S CREENSHOTS

Figure 5: Writing a file to HydrOS with HydroFS.

Figure 6: A file being written to HydrOS through

HydroFS.

17
Figure 7: Reading a file using HydroFS.

18
 A PPENDIX C. Write Performance (Seconds) - 8 cores
T EST R ESULTS Size(in bytes) Measured Speed
508 0.000154005
1016 0.000202007
2032 0.000286009
4064 0.000466015
8128 0.000828105
Read Performance (Seconds) - 8 cores
Size(in bytes) Measured Speed
508 0.000016001
1016 0.000036003
2032 0.000064005
Write Performance (Seconds) - 2 cores 4064 0.000112007
Size(in bytes) Measured Speed 8128 0.000224015
508 0.001115957
1016 0.500850896 Figure 10: Octa-Core performance results
2032 1.501131014
4064 2.001798172
8128 3.003183701
Read Performance (Seconds) - 2 cores
Size(in bytes) Measured Speed
508 0.000061747
1016 0.000097891
2032 0.000158133
4064 0.000284639
8128 0.000540663
Figure 8: Dual-Core performance results

Write Performance (Seconds) - 4 cores

Size(in bytes) Measured Speed
508 0.000311531
1016 0.000401273
2032 0.000578193
4064 0.001984555
8128 0.003784495
Read Performance (Seconds) - 4 cores
Size(in bytes) Measured Speed
508 0.000032051
1016 0.000069231
2032 0.000121795
4064 0.000394859
8128 0.000884598
Figure 9: Quad-Core performance results

19