Writing an OS Kernel from Scratch – Part 10: Virtual File System and ext2 Implementation
“Initramfs is just a toy; a real OS needs persistent storage. Today, we design the VFS abstraction layer and implement the first disk filesystem — ext2!”
In the previous post, we used an in-memory Initramfs for user program loading, but that’s a temporary solution. A real OS must read and write files from disk, supporting persistent, large-capacity storage.
The classic Linux filesystem ext2 (Second Extended Filesystem) is an excellent learning target:
✅ Clear structure, good documentation
✅ No journaling (simple), suitable for bare-metal implementation
✅ Foundation for ext3/ext4
Today, we:
- Design the Virtual File System (VFS) abstraction layer
- Analyze ext2 disk layout
- Implement open/read/readdir system calls
Making your OS truly load programs from hard disk (or QEMU virtual disk)!
Why VFS?
Different filesystems (ext2, FAT32, NTFS) have vastly different structures, but user programs only care about unified interfaces like open, read, write.
VFS Core objects:
| Object | Role |
|---|---|
| Superblock | Describes the entire filesystem (block size, inode count, etc.) |
| Inode | Describes a single file (permissions, size, data block pointers) |
| Dentry | Directory entry (filename → inode mapping) |
| File | Open file instance (including current read/write position) |
ext2 Disk Layout
ext2 divides the disk into Block Groups, each containing:
- Superblock
- Inode allocation bitmap
- Block allocation bitmap
- Inode table
- Data blocks
Inode data block addressing:
- Direct blocks: i_block[0~11] → directly point to data blocks
- Indirect block: i_block[12] → points to a block containing 1024 data block pointers
- Double indirect: i_block[13] → two levels of indirection
- Triple indirect: i_block[14] → three levels (ext2 supports up to 2TB files!)
Comments