File Systems: Under the hood

Introduction

I have always had this fascination of knowing how computers work under the hood; and this led me to stumble upon the language C which is a low level programming lanaguge - perfect for enthusiasts like me to understand and converse with the machine. I wanted to build my first project in C and I was confused as to what should I build. I didn’t want to build a simple calculator or another number guessing game. So I asked my good’ol friend chatgpt, so as “Give me some cool project recommendations in C” and it suggested me to build my very own virtual file system. It sounded so cool, and I obviously dived in it. But even before building something this crazy, I wanted to know the theory behind it and how does this actually work under the hood.

</br>

The Beginning

Our physical storage drives (be it a HDD or a SSD), it is just like a large empty notebook, where you can store any information you want. But think of it this way, if you were to find a particular piece of information in that storage drive, without knowing where to actually look in this vast empty notebook - you will be exhausted. Thus just like our books have something called the “Index page”, similarly our physical storage drives have something called the File System. This is a collection of rules, index table and layout that lets us store stuff in our physical drives wihtout getting lost.

Some popular examples of a file system are: ext4, NTFS, FAT32, etc.

Now this file system has three main components and main popular file systems boil down to these three main core components

1. Superblock - Brain of the entire file system

The Superblock is considered the entire brain of the file system, because it stores all the master information related to the file system. It answers stuff like

• What’s the block size?
• How many blocks exist?
• How many are free?
• Where is the inode table?
• What version is the file system?
• What is the layout?

So when a filesystem is mounted, the operating system does the following

• Read the Superblock
• Validate it
• Finds everything else inside it

So without a superblock, the whole disk is just random bytes. It serves as the identity card of our disk.

2. Inode table

Directory of the files (index) but not the contents (its the metadata container of the whole file system). Each file gets an inode and each inode contains the following parts

• file name
• file size
• where file data is stored
• timestamp
• permissions
• flags (in use or deleted)

3. Data blocks

This is the big chunk of space where actual file content or file data goes. Now here we have different blocks - which have a fixed size unit (say 4KB or 512 bytes etc.), and the files we store they usually take many of these blocks.

So if the blocks ize is 512 bytes and our files is 2000 bytes, our file will require 4 blocks to get written on the disk.

So how does saving a file work?

Lets say I wanna save a file “hello.txt” with the content “hello hardikk”

So a simple filesystem would do the following:

1. Find a free inode: Inode #3 is free (let’s say), so our file sytem will assign it to file to store the metadata of the file here.
2. Decide where to store the file data: FS uses contiguous allocation (for now; although not in real life). So a stretch of blocks that are unused gets picked and gets reserved for our file data.
3. Write the data to the reserved block(s): All our data gets written in the reserved blocks.
4. Fill the inode info of the file: All the metadata of the file gets written into the inode our FS chose earlier.
5. Update the superblock: The FS reduces the count of free blocks depending upon the number of blocks our file used.

</br>

How does reading a file work?

The OS (Operating System) requests “hello.txt” (lets say the file we want to read is named “hello.txt”)

So a simple filesystem would do the following:

1. Scan inodes: Find the inode where the file name is equal to “hello.txt”
2. Look at the inode’s metadata and get the block from where the data is written to the file and how many blocks does the FS occupy.
3. Read the block data: Finally after getting all the data, the FS extracts it and returns ot the required place.

How does deleting a file work?

If we delete the “hello.txt” the follwoing things occur:

1. Find inode of the “hello.txt” file
2. Mark the blocks it occupies as free
3. Set the deleted flag as true
4. Increase the number of free blocks in the superblock.

The actual data might still remain untill finally overwritten by some other data.

Conclusion

So this is how a simple file system works under the hood, and I will soon be building a full fledged FS in C language. Stay tuned!