File System Layers

When you execute a simple command like open('/home/user/document.txt', 'r'), you invoke one of the most sophisticated abstraction layers in computer science. Behind this seemingly trivial operation lies an intricate machinery that translates your high-level request through multiple layers of software, each adding critical functionality while hiding complexity from the layer above.

The logical file system sits at the apex of this layered architecture. It's the layer that developers and users interact with directly—the layer that transforms the chaos of spinning platters, flash cells, and electrical signals into the elegant abstraction we call a file.

Understanding this layer isn't merely academic. It's the key to writing efficient file-handling code, debugging mysterious I/O failures, and architecting systems that perform well under load. Principal engineers at companies like Google, Netflix, and Amazon regularly make design decisions that require deep understanding of how logical file systems process requests.

Before diving deep into the logical file system, we must understand where it sits within the broader file system architecture. Modern operating systems implement file systems as a layered stack, where each layer provides abstraction and services to the layer above while consuming services from the layer below.

This layered design follows fundamental software engineering principles: separation of concerns, abstraction hiding, and modularity. Each layer has a well-defined interface and responsibility, making the system easier to understand, maintain, and extend.

The critical insight: Each layer only knows about the abstractions provided by the layer below. The logical file system doesn't know whether data is stored on an SSD, a spinning disk, or a network-attached storage device. It operates purely in terms of logical blocks and file metadata. This separation is what allows the same file system implementation to work transparently across vastly different storage technologies.

The logical file system is the topmost layer of the file system stack. It's the layer that user programs interact with through system calls like open(), read(), write(), close(), stat(), and chmod(). Its primary job is to manage all aspects of files that don't involve physical storage—essentially, everything about a file except the actual bytes on disk.

Think of the logical file system as the interface and policy layer. It defines what operations are possible, validates that requested operations are legal, manages the metadata that describes files, and orchestrates requests to lower layers. It's the layer that makes files behave like files—with names, permissions, sizes, timestamps, and organizational structure.

An important distinction: The logical file system deals with structure and policy, not mechanism. It decides what should happen and whether it's allowed to happen, then delegates the how to lower layers. When you call write(fd, buffer, 1000), the logical file system verifies you have write permission, looks up the file's FCB, and determines which logical blocks need modification. But it doesn't actually issue I/O commands—that's left to lower layers.

Every file in a file system is represented by a File Control Block (FCB). In Unix-like systems, this structure is called an inode (index node). In Windows NTFS, it's a Master File Table (MFT) entry. Regardless of the specific implementation, the concept is universal: there must be a data structure that stores all metadata about a file.

The FCB is the logical file system's fundamental unit of management. When you refer to a file by name, the logical file system ultimately resolves that name to an FCB. All subsequent operations on that file consult and update this structure.

Critical observation: The FCB does NOT contain the file's name. This is a profound design decision. Names are stored in directories, which are just special files containing (name, inode number) pairs. This separation enables:

1. Hard links — Multiple names can point to the same inode
2. Efficient renaming — Renaming only changes the directory entry, not the file itself
3. Atomic operations — The inode is the authoritative source of truth, reducing race conditions

When the link count drops to zero (no names reference the inode) AND no process has the file open, only then is the file truly deleted.

The logical file system provides directory services—the ability to organize files into a hierarchical namespace and resolve human-readable paths to internal identifiers. This seemingly simple functionality involves surprisingly complex machinery.

What is a directory? In most Unix-like file systems, a directory is simply a special file whose contents are a list of (name, inode number) pairs. The logical file system interprets this data specially, providing operations like opendir(), readdir(), and closedir().

Path Resolution Algorithm

When you access /home/user/docs/report.txt, the logical file system executes a path resolution algorithm:

1. Start at root directory (inode 2 on most Unix systems)
2. Read root directory contents
3. Search for entry named 'home' → get inode number
4. Read inode for 'home', verify it's a directory
5. Read 'home' directory contents
6. Search for entry named 'user' → get inode number
7. Read inode for 'user', verify it's a directory
8. Read 'user' directory contents
9. Search for entry named 'docs' → get inode number
10. Read inode for 'docs', verify it's a directory
11. Read 'docs' directory contents
12. Search for entry named 'report.txt' → get inode number
13. Read inode for 'report.txt', verify permissions
14. Return file handle

For a 4-component path, this involves reading at least 8 blocks (4 directory inodes + 4 directory contents). For deeply nested paths, the cost is even higher.

Directory Implementation Strategies

The logical file system must efficiently implement directories despite varying workloads—from directories with 3 files to directories with 3 million files. Several strategies exist:

*Linear list insertion is O(1) only if we allow duplicates; with duplicate checking it becomes O(n).

Modern file systems like ext4 use a hybrid approach: small directories use a linear list (fast for typical use), but large directories automatically convert to an HTree (hashed B-tree) structure. This adaptive strategy optimizes for common cases while scaling to extreme workloads.

The logical file system is the enforcement point for all file access control. Before any operation proceeds, this layer validates that the requesting process has appropriate permissions. This is not optional—it's the fundamental security barrier protecting user data.

Access control happens at multiple levels:

1. Every operation — Read, write, execute, delete, rename, attribute change
2. Every path component — You need execute permission on every directory in a path
3. Every transition — Following symbolic links, crossing mount points

A single failed permission check aborts the entire operation with EACCES (permission denied) or EPERM (operation not permitted).

Unix Permission Model (DAC)

The traditional Unix model is Discretionary Access Control (DAC). The file owner decides who can access the file. Permissions are encoded in a 12-bit field:

   Special    Owner      Group      Others
   ─────────  ─────────  ─────────  ─────────
   suid sgid  r  w  x    r  w  x    r  w  x
   sticky                                     
   ─────────  ─────────  ─────────  ─────────
     3 bits    3 bits     3 bits     3 bits

Permission bits meaning:

• r (4): Read file contents / list directory
• w (2): Modify file contents / add/remove directory entries
• x (1): Execute file / traverse directory

Special bits:

• setuid (4000): Execute as file owner (not caller)
• setgid (2000): Execute as file group / inherit group in directory
• sticky (1000): Only owner can delete files in directory (used for /tmp)

Access Control Lists (ACLs)

Basic Unix permissions only allow specifying access for owner, one group, and everyone else. This is insufficient for complex environments. ACLs (Access Control Lists) extend the model, allowing fine-grained control:

# Example: Grant specific user access without changing group
setfacl -m u:alice:rw /data/project/report.doc

# Example: Deny specific group access
setfacl -m g:contractors:--- /data/confidential/

# Example: Set default ACL for new files
setfacl -d -m g:developers:rwx /data/project/

ACLs are stored as extended attributes attached to the inode. The logical file system evaluates ACLs after checking basic permissions, allowing or denying access based on the most specific matching entry.

When a process opens a file, the operating system doesn't just return an inode—it creates a sophisticated tracking structure. The logical file system maintains multiple levels of file tables to efficiently manage open files while supporting features like file sharing and independent file positions.

The Three-Level Table Architecture

    Process A            Process B           System-wide
   ────────────        ────────────        ─────────────────
   ┌──────────┐        ┌──────────┐        ┌───────────────┐
   │ FD Table │        │ FD Table │        │ Open File     │
   ├──────────┤        ├──────────┤        │ Table         │
   │ 0  stdin │        │ 0  stdin │        ├───────────────┤
   │ 1  stdout│        │ 1  stdout│        │ Entry 1       │
   │ 2  stderr│        │ 2  stderr│        │  - offset: 0  │
   │ 3 ─────────┐      │ 3 ───────────┐    │  - mode: r    │
   │ 4 ─────────┼──────│ 4 ───────────┼────│  - inode ptr  │
   └──────────┘ │      └──────────┘   │    ├───────────────┤
                │                     │    │ Entry 2       │
                │                     └────│  - offset: 500│
                │                          │  - mode: rw   │
                └──────────────────────────│  - inode ptr  │
                                           └───────────────┘

Level 1: Per-Process File Descriptor Table

• Each process has its own array of file descriptors (small integers: 0, 1, 2, ...)
• Each entry points to an entry in the system-wide open file table
• Inherited across fork(), allowing parent-child file sharing
• close() removes entry from this table only

Level 2: System-Wide Open File Table

• One entry per unique file opening (not per descriptor)
• Contains: current file offset, access mode (r/w), flags, pointer to inode
• Multiple FDs (same or different processes) can point to same entry → shared offset
• Reference counted; entry freed when all FDs closed

Level 3: In-Memory Inode Table (vnode/inode cache)

• One entry per open file, regardless of how many times it's open
• Cached copy of on-disk inode, plus runtime state (locks, pages in memory)
• Reference counted; evicted from cache when no longer needed

Practical Implications

Scenario 1: Two independent opens of the same file

// Process A
int fd = open("/data/log.txt", O_RDONLY);

// Process B (separate process)
int fd = open("/data/log.txt", O_RDONLY);

• Each process gets its own FD
• Each creates a separate open file table entry
• Both entries point to the same inode
• File offsets are independent — each reader tracks position separately

Scenario 2: Inherited file descriptor after fork()

int fd = open("/data/log.txt", O_RDWR);
if (fork() == 0) {
    write(fd, "child", 5);  // Child writes
} else {
    write(fd, "parent", 6); // Parent writes
}

• Parent and child share the SAME open file table entry
• File offset is shared — writes interleave at kernel-tracked position
• Critical for: shell pipelines, log files, coordinated I/O

The logical file system is the first line of defense against invalid operations. Before passing any request to lower layers, it performs comprehensive validation. This validation is critical for system stability—allowing an invalid request to reach the disk driver could cause data corruption or system crashes.

Error Codes and Their Meanings

When validation fails, the logical file system returns specific error codes via errno. Understanding these codes is essential for proper error handling:

After validation succeeds, the logical file system must interface with the file organization module (the next layer down). This interface is designed around logical blocks—fixed-size units of storage independent of the underlying hardware.

The logical file system communicates requests in an abstract form:

• "Read block 1000 of file inode 12345"
• "Write this data to block 2000 of file inode 12345"
• "Allocate 5 new blocks for file inode 12345"

It does NOT specify:

• Which physical sectors on disk contain these blocks
• Whether the blocks are contiguous or fragmented
• What the actual disk geometry is

This abstraction is crucial. The same logical file system code can work with contiguous allocation, linked allocation, indexed allocation, or extent-based allocation—as long as the file organization module presents the same interface.

The Conversion Process

   Application Request              Logical FS Action           To Lower Layer
   ──────────────────────           ─────────────────           ──────────────
   read(fd, buf, 4096)              1. Validate fd, buf, count
                                    2. Get inode from FD
                                    3. Check read permission
                                    4. Calculate: offset 0 → logical block 0
                                                  ────────────────────────────►
                                                  Request: read inode X, block 0

   write(fd, buf, 8192)             1. Validate fd, buf, count
   (offset at 4096)                 2. Get inode from FD
                                    3. Check write permission
                                    4. Calculate: offset 4096 → block 1
                                                  offset 8192 → block 2 (partial)
                                                  ────────────────────────────►
                                                  Request: allocate block if needed
                                                  Request: write inode X, blocks 1-2
                                    5. Update inode: size, mtime

Key transformations:

• Byte offset → Logical block number: block = offset / block_size
• Byte count → Block count: Handles partial blocks at start and end
• Permissions → Allowed operations: Read/write/execute checks
• File descriptor → Inode: Via the open file table chain

We've explored the logical file system—the top layer of the file system stack and the primary interface for applications and users. Let's consolidate the key concepts:

What's Next:

The logical file system converts file operations into logical block requests. But how does the system know which physical blocks on disk hold these logical blocks? That's the job of the file organization module—our next topic. We'll explore how different allocation strategies (contiguous, linked, indexed) map logical blocks to physical storage.