Designing a Simple File System with Blocks, Bitmaps, Inodes, and Directories

The tutorial starts by assuming a 1 TB hard disk and divides it into logical 1 KB blocks (each block = two physical sectors), creating 1024 blocks for a simplified 1 MB example. A block bitmap is introduced to track block usage, with block 0 reserved for the bitmap itself.

Files are stored by selecting a free block (e.g., block 3) and writing the file data there. To avoid overwriting, a bitmap records which blocks are used, and a separate inode bitmap tracks inode allocation.

Each file gets an inode (128 bytes) that stores metadata such as name, size, timestamps, and a pointer to the data block. The inode table occupies a fixed block (block 2) and the inode bitmap resides in block 1.

For larger files requiring multiple blocks, the design first uses contiguous allocation, then introduces indirect indexing: one block can store pointers to many data blocks, enabling a first‑level indirect index that expands the addressable space to 263 blocks, with the possibility of second‑level indexing for even larger files.

Directory support is added by defining a special file type for directories, storing directory entries (inode numbers, file types, and names) within data blocks. The root directory is fixed at inode 0, and hierarchical paths (e.g., folder/file.txt) are resolved by traversing directory inodes.

Additional structures such as a superblock (holding global counts of blocks, free blocks, inodes, etc.) and block descriptors are placed in the early blocks to simplify management when structures grow beyond a single block.

The final layout mirrors the classic Linux ext2 filesystem, with block bitmap, inode bitmap, inode table, data blocks, and directory structures, demonstrating a complete, extensible file system design.