Aim : 

The primary aim of MicroFS is to provide students with a concrete, hands-on understanding of how operating systems manage persistent storage. Specifically, the project aims to:

• Build deep proficiency in C programming — pointers, structs, bitwise operations, and direct binary file I/O using lseek, read, and write.
• Implement and understand inode-based filesystem architecture: how inodes separate file names from file data, how bitmaps track free space, and how directory entries create the name-to-inode mapping.
• Implement crash recovery via a Write-Ahead Journal (WAL) — understanding why atomic multi-block operations require logging before writing.
• Build a filesystem consistency checker (fsck) capable of detecting and repairing structural inconsistencies in the disk image.
• Support Unix-style file concepts: hard links with reference counting, symbolic links with loop detection, file permissions (rwxrwxrwx), and timestamps (created, modified, accessed).
• Foster collaborative engineering through a shared API contract (include/microfs.h), Git branching, pull requests, and dependency-ordered module integration.
• Deliver a portfolio-ready system with a colorised interactive shell, 56-test suite, and full documentation.

Methodology: 

1. Virtual Disk and Storage

MicroFS stores the entire filesystem inside a single 4 MB binary file (microfs.disk) divided into 8192 fixed-size blocks of 512 bytes each. Every read and write in the system ultimately reduces to an lseek followed by a read or write on this file, exactly replicating what a real block device driver does. The disk is partitioned at format time into six fixed regions: the superblock at block 0, a 32-block Write-Ahead Journal at blocks 1–32, an inode bitmap at block 33, a block bitmap spanning blocks 34–37, the inode table at blocks 38–165, and the data block area from block 166 to 8191.

2.  Inodes and Free Space

Every file, directory, and symbolic link is described by a 192-byte inode record stored in the inode table. Each inode holds the object type, Unix permission bits, hard-link reference count, file size, three timestamps, and twelve direct block pointers that map file content into the data block area. Free space is tracked with two bitmaps — one for inodes and one for data blocks — so any allocation or deallocation is a single bit flip followed by a superblock counter update. Block index 0 is permanently reserved, making it a safe sentinel value meaning "not allocated" in the direct-block arrays.

3.  Directories and Path Resolution

A directory is implemented as an ordinary file whose data blocks contain a flat array of 60-byte directory entries, each pairing a 4-byte inode number with a 56-byte filename. An inode number of zero marks a free slot. Every new directory is initialised with . and .. entries pointing to itself and its parent respectively. Path resolution walks this structure token by token: absolute paths start from the root inode, relative paths start from the current working directory, and .. is resolved by following the parent entry. Symbolic links are followed transparently during traversal, with a loop-detection counter capping depth at eight redirections.

4. Crash Recovery via Write-Ahead Journal

To guarantee consistency across unexpected shutdowns, every potentially destructive write follows a three-step protocol. First, the original block data is copied to the journal along with a WRITE record. Second, a COMMIT record is appended to the journal. Third, the actual write is applied to its target on disk and the journal is checkpointed. On remount after a crash, MicroFS replays the journal: a COMMIT record means the write completed and nothing needs to be done; a WRITE record without a COMMIT means the write was incomplete and the original data is restored from the journal, returning the disk to its last consistent state.

 5. Consistency Checking and the Shell

The built-in fsck command verifies the superblock checksum, the inode and block bitmaps against the actual inode table, hard-link reference counts, directory entry integrity, and symlink targets. With the -r flag it repairs fixable inconsistencies in place. The user interacts with all of this through a colorised Unix-style shell that accepts absolute and relative paths, displays a prompt reflecting the current working directory, and exposes the full set of file, directory, and link commands.

Result : 

MicroFS has been fully implemented and produces the following concrete, verifiable outcomes.

Shell Commands : 

Conclusion:

MicroFS is a fully working inode-based filesystem in C that implements the same core abstractions as ext4 — inodes, bitmaps, hard links, symbolic links, Write-Ahead Journal crash recovery, and fsck — inside a single 4 MB binary file. All 56 tests pass and the interactive shell provides immediate, tangible proof that the underlying binary structures are correct. The Write-Ahead Journal was the most technically demanding part: getting the LOG → COMMIT → APPLY ordering right, and verifying it through simulated crashes, gives a concrete appreciation for why production filesystems require careful write ordering. The result is a system that is not just academically interesting but architecturally honest — every design decision maps directly to something real filesystems do.

Future Scope : 

• chmod / chown — permission bits and UID/GID are already stored per inode; only a shell handler is needed.
• Indirect blocks — a 13th inode pointer raises the per-file size limit from ~6 KB to ~65 KB.
• FUSE mount — wrapping MicroFS with a FUSE adapter would let microfs.disk mount as a real Linux directory, allowing standard tools like cp and vim to operate on it directly.
• B-tree directories — replace the linear DirEntry scan with O(log n) lookup for large directories, as ext4 does with htree.
• Block encryption / compression — encrypt or compress data blocks transparently before writing to disk.

References :

• Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts (10th ed.). Wiley.
• Love, R. Linux Kernel Development (3rd ed.). Addison-Wesley.
• The ext4 Filesystem — Linux Kernel Documentation. https://www.kernel.org/doc/html/latest/filesystems/ext4/
• SQLite WAL (Write-Ahead Logging). https://www.sqlite.org/wal.html
• FUSE — Filesystem in Userspace. https://github.com/libfuse/libfuse

Mentors and Mentees:

Mentors:

• Chinmayee Adiga 
• Devansh Sharma

Mentees :

• Sanjeev 
• Mohamed Razeen
• Jeevan Raj G
• Jissa Mary

GMeet Link : https://meet.google.com/qbi-ekfz-erc

Repo Link : https://github.com/chinmayeeadiga/MicroFS