The VFS Layer

[!NOTE] This module explores the core principles of The VFS Layer, deriving solutions from first principles and hardware constraints to build world-class, production-ready expertise.

1. The Universal Interface

How can the same read() system call work on an Ext4 hard drive, a USB stick (FAT32), and a network share (NFS)?

The answer is the Virtual File System (VFS).

VFS is a kernel software layer that handles all system calls related to file systems. It provides a common interface (contract) that every specific file system must implement.

The Abstraction Layers

1. User Space: Calls read(fd, buf, len).
2. VFS Layer: Looks up the fd, finds the corresponding FS driver.
3. FS Driver: Translates the request to specific disk operations.
   • Ext4: “Read block 500.”
   • NFS: “Send RPC GET packet.”

---

2. Key VFS Objects

In the Linux Kernel (written in C), VFS is implemented using Function Pointers (Polymorphism).

The file_operations Struct

Every open file has a pointer to a struct containing methods:

• read()
• write()
• open()
• fsync()

When you plug in a USB drive, the FAT32 driver registers its own version of these functions. The VFS just calls file->f_op->read().

The dentry (Directory Entry)

Represents a path component (e.g., /, home, user). VFS uses the Dentry Cache (dcache) to speed up path lookups so it doesn’t have to read the disk for every filename check.

---

3. Interactive: The Syscall Router

Visualize how a generic system call is routed to the correct driver.

User Space

Application

↓

KERNEL SPACE

VFS Layer (Dispatcher)

Ext4

/home

FAT32

/mnt/usb

NFS

/net/share

Waiting for syscall...

---

4. Code Examples: The Interface Pattern

The VFS is essentially the Interface pattern applied to operating systems. We can model this in Go and Java.

package main

import "fmt"

// 1. The VFS Contract (Interface)
type FileSystem interface {
	Read(path string) string
	Write(path string, data string)
}

// 2. Implementation: Ext4
type Ext4Driver struct{}

func (e Ext4Driver) Read(path string) string {
	return "Ext4: Reading from inode..."
}
func (e Ext4Driver) Write(path string, data string) {
	fmt.Println("Ext4: Journaling and writing blocks.")
}

// 3. Implementation: NFS
type NFSDriver struct{}

func (n NFSDriver) Read(path string) string {
	return "NFS: Sending RPC GET..."
}
func (n NFSDriver) Write(path string, data string) {
	fmt.Println("NFS: Sending RPC WRITE.")
}

// 4. The VFS Layer (Caller)
func main() {
	// Mount points
	var homeFS FileSystem = Ext4Driver{}
	var netFS FileSystem = NFSDriver{}

	// User Code doesn't care about the driver
	fmt.Println(homeFS.Read("/home/user/file.txt"))
	netFS.Write("/net/share/log.txt", "hello")
}

import java.io.IOException;
import java.nio.file.*;
import java.net.URI;
import java.util.Collections;

public class VfsDemo {
    public static void main(String[] args) throws IOException {
        // Java NIO uses the FileSystemProvider abstraction (SPI)
        // This is exactly how VFS works.

        // 1. Default File System (usually Ext4/NTFS on local disk)
        Path local = Paths.get("local.txt");
        System.out.println("Local Provider: " + local.getFileSystem().provider());

        // 2. Zip File System (Plugged in via SPI)
        // Treats a .zip file as a File System!
        Path zipPath = Paths.get("archive.zip");
        URI uri = URI.create("jar:file:" + zipPath.toUri().getPath());

        try (FileSystem zipFs = FileSystems.newFileSystem(uri, Collections.singletonMap("create", "true"))) {
            Path internal = zipFs.getPath("/internal.txt");

            // The exact same API call is routed to the Zip Driver
            Files.writeString(internal, "Data inside zip");
            System.out.println("Zip Provider: " + zipFs.provider());
        }
    }
}