Exploring Linux Filesystems: VFS, ext2 Superblock, and Inode Access

Linux file systems can be intimidating for newcomers, especially when transitioning from Windows where FAT32 and NTFS dominate. This article shares the author’s learning path, starting with the basic concept that a file system is a set of rules for naming, organizing, and accessing files stored on media such as hard disks, optical discs, or USB drives.

1. File System Basics

Key user questions include where files are stored, how data is written, how it is read back, and how unwanted files are deleted. The file system defines naming conventions, data organization into blocks, and efficient query and access mechanisms.

2. Virtual File System (VFS)

Early Linux kernels tightly coupled each file system implementation with the OS, making it impossible to mount a file system that the kernel did not explicitly support. To solve this, Linux introduced the Virtual File System (VFS), a thin abstraction layer that hides the specifics of ext3, FAT32, NTFS, and others behind a uniform API. Applications therefore use the same open, read, write, and close calls regardless of the underlying file system.

3. ext2 Superblock Analysis

The ext2 (and ext3) superblock occupies bytes 1024‑2047 of a partition and stores critical metadata such as file system type, block size, total block count, inode size, inode count, and group count. The article demonstrates extracting this information with tune2fs -l /dev/sda1 and parsing the output.

[root@localhost ~]# tune2fs -l /dev/sda1
Filesystem volume name: /boot
Filesystem UUID: 6ade5e49-ddab-4bf1-9a45-a0a742995775
Filesystem magic number: 0xEF53
Block size: 1024
...

Using dd to copy the superblock to a file:

$ dd if=/dev/hdd1 of=./hdd1sb bs=1024 skip=1 count=1

The extracted superblock confirms the partition uses ext2 (magic signature 0xef53) and reveals values such as 1 048 576 inodes, 2 097 065 blocks, and a 4 KB block size.

4. Groups, Descriptors, and Bitmaps

Each ext2 file system is divided into block groups. A group contains a copy of the superblock (for redundancy), a group descriptor, block bitmap, inode bitmap, and inode table. The article lists the groups that store backup superblocks (e.g., groups 1, 3, 5, 7, 9, 25, 27, 49) and shows how to compute them using powers of 3, 5, 7.

The group descriptor structure (from include/linux/ext2_fs.h) is reproduced:

struct ext2_group_desc {
    __le32 bg_block_bitmap;   /* block bitmap */
    __le32 bg_inode_bitmap;   /* inode bitmap */
    __le32 bg_inode_table;    /* inode table */
    __le16 bg_free_blocks_count;
    __le16 bg_free_inodes_count;
    __le16 bg_used_dirs_count;
    __le16 bg_pad;
    __le32 bg_reserved[3];
};

A small program iterates over all 64 groups, printing each descriptor’s block numbers, free block/inode counts, and directory count.

#define B_LEN 32
int main(int argc, char **argv) {
    char buf[B_LEN] = {0};
    int i = 0, fd = -1;
    struct ext2_group_desc gd;
    fd = open(argv[1], O_RDONLY, 0777);
    while (i < 64) {
        read(fd, buf, B_LEN);
        memcpy(&gd, buf, B_LEN);
        printf("========== Group %d ==========
", i);
        printf("Blocks bitmap block %ld
", gd.bg_block_bitmap);
        printf("Inodes bitmap block %ld
", gd.bg_inode_bitmap);
        printf("Inodes table block %ld
", gd.bg_inode_table);
        i++;
    }
    close(fd);
    return 0;
}

5. Inode Table and Block Pointers

Each inode is 128 bytes and stores file metadata (size, timestamps, permissions) plus 15 block pointers: 12 direct, one single‑indirect, one double‑indirect, and one triple‑indirect. The article visualises the pointer hierarchy and calculates the maximum file size for a given block size (e.g., 4 KB blocks → ~16 TB maximum).

6. End‑to‑End C Programs for Reading Files by Inode

The article provides a series of C source files: superblock_size.c – prints sizeof(struct ext2_super_block) (1024 bytes). group_desc.c – reads a group descriptor given a partition device. rd_file_by_inode.c – combines the previous steps to locate an inode, read its block pointers, and reconstruct the file contents on disk.

Key functions include:

int get_blk_size(int fd, int offset, struct fdata *ret) { /* reads superblock */ }
int get_grp_descriptor(int fd, int offset, struct fdata *ret) { /* reads group descriptor */ }
int get_inode(int fd, int offset, struct fdata *ret) { /* reads inode */ }
int read_data(int fd, int block_s, int dblock_num, int fsize, int level, char *dbuf) { /* recursive block pointer traversal */ }

Compilation is performed with gcc -o rd_file_by_inode rd_file_by_inode.c. The program is then invoked as: ./rd_file_by_inode /dev/hdd1 12 output.bin It prints the inode number, block size, and file size, and writes the recovered file to output.bin.

7. Validation

Using the recovered files (e.g., bzImage, klinux-2.6.18.tar.gz, VMwareTools-7.8.6-185404.i386.rpm), the author compares MD5 checksums with the originals and confirms they match. Hex dumps of the original and recovered files are also shown to demonstrate byte‑for‑byte equality.

Although real kernel file‑system drivers use more optimized paths, this hands‑on exploration deepens understanding of how Linux stores and retrieves data at the block level.

Author: 上善若水 (originally published on the "码农有道" public account).