COMS W4118 Operating Systems I

Linux File System Architecture

Virtual File System (VFS) Overview

Many file system types and device types can coexist on the same system. How can we unify them all under one uniform interface? Let’s consider three levels of the storage schematic presented above:

• File System Interface
• VFS Interface
• Storage Level

File System Interface

This is the API that userspace programs use to interact with files. Recall file I/O syscalls from L03-file-io: open(), close(), read(), etc. Userspace programs receive file descriptor from the kernel and uses syscalls to interact with the file.

Prefer to give userspace programs a simple and unified interface instead of exposing implementation details! As such, delegate fs-specific details to the kernel.

Storage Level

We’ve learned about several file systems at this point: FFS, ext2, ext3, lfs, reiserfs, etc. We can format (or partition) a storage device (HDD/SSD/etc.) with a file system.

There are even distributed file systems where data is not stored locally, but on some remote server!

However, we don’t want to burden userspace programs with fs-specific details. We need to hook into the kernel so that userspace programs can simply use the unified syscall API!

VFS Interface

An FS abstraction layer that transparently and uniformly supports multiple file systems. VFS specifies an interface that a given FS implements to hook into the kernel

• interface: a struct of function pointers, like struct sched_class from HW6

VFS carries out file I/O operations from userspace by dispatching operations to the FS implementation of the VFS interface

• dispatch example, just call the function pointer: dir->inode_op->mkdir()

VFS Data Structures

Four high-level VFS data structures: struct file, struct dentry, struct inode, struct super_block.

struct file

Recall from L03-file-io/HW4: struct file represents an instance of an open file.

• Pointed to by per-process fdtable entry, allows for file sharing by copying pointer (e.g., dup())
• Stores flags, current file position, etc.
• Refers to dentry via struct path f_path (which refers to inode)

VFS interface: struct file_operations *f_op

• read, write, seek, etc.

struct dentry

Basically a “hard link”: contains name of link and inode number.

Break up an absolute path into dentries, one per component. For example: /home/hans/foo:

• /
• home
• hans
• foo

Path resolution is expensive! To open /home/hans/foo you need to:

• consult the dentry for / to find the root inode
• find the root data block, iterate through it to find dentry for home
• consult the dentry for home to find the inode
• find the corresponding data block, iterate through it to find dentry for hans
• consult the dentry hans to find the inode
• find the corresponding data block, iterate through to find the dentry for foo
• consult the dentry foo to find the inode
• find the corresponding data block, and finally read the file contents!

Linux employs some cool caching to help improve performance… more on this later.

VFS interface: const struct dentry_operations *d_op

• manage dentries through dentry cache (create/remove/hash/etc), more on this later.

struct inode

Unique descriptor of a file or directory

• Recall discussion of hard links in L24-unix-fs

i_ino: inode # unique per mounted filesystem
Can refer to fs-specific data via i_private (will be used for HW8)

VFS interface: const struct inode_operations *i_op

• create, link, unlink, mkdir, rmdir, etc.

struct super_block

Descriptor of a mounted filesystem.

VFS interface: const struct super_operations *s_op

• inode management, journaling, syncing metadata

Dentry Cache

Linux kernel makes path resolution efficient by employing a dentry cache (dcache).

(simplified version from this online book)

1. Mount an instance of ext2 at /home
   • s_root field of super_block refers to root dentry of the mount
2. P1 opens "/home/hans/foo" for reading
   • Recall path resultion above: need to read several inodes/dentries from disk
   • Along the way, cache them in the dcache
3. P2 opens "/home/hans/foo" for writing
   • Different struct file because P2 is an independent process
   • Same dentry and same inode
   • Before consulting directory data blocks for dentries, check if present in dcache! Speeds up path resolution!
4. P3 opens "/home/hans/bar"
   • Different file than P1 and P2
   • /home/hans/ path resolution cached in dcache
   • Need to read in hans/ directory data block to find dentry for bar
   • …only to find it refers to the same inode as foo
   • bar and foo are hard links to the same inode!

---

Last updated: 2023-04-18