Linux System Administration Foundations I Lecture 3: Filesystems, Directories, and Why Linux Treats Everything as a File

A newly installed Linux system may appear to contain an overwhelming collection of directories whose purposes are not immediately obvious. Unlike operating systems that separate resources behind numerous graphical abstractions, Linux presents a unified hierarchy beginning at a single point known simply as the **root** directory, represented by a forward slash (**/**). Every file, every mounted disk, every configuration file, every user's home directory, and many representations of hardware itself ultimately become part of this single tree. Understanding this hierarchy is one of the first signs that an administrator has begun to think like the operating system itself. The statement that "everything is a file" is one of Unix's most celebrated principles. It is not literally true—network sockets and processes are not ordinary files—but it accurately reflects the design philosophy. Devices, configuration information, process statistics, and communication interfaces are intentionally presented through file-like abstractions so that the same tools may inspect and manipulate many different parts of the system. A command that reads a text file today may tomorrow read information from the kernel or communicate with a hardware device using nearly identical techniques. The root of the filesystem contains directories whose purposes have evolved over decades while remaining remarkably stable. The **/etc** directory stores system configuration, allowing administrators to understand how services are configured without relying upon proprietary databases. The **/var** hierarchy contains information expected to change over time, including logs, mail queues, caches, databases, and application state. User files typically reside beneath **/home**, while executable programs are distributed among directories such as **/bin**, **/usr/bin**, and **/usr/local/bin**, reflecting both historical practice and modern packaging conventions. Not every directory occupies the same physical storage device. Linux permits multiple filesystems to be mounted into the same directory tree, producing the illusion of a single continuous filesystem even when information resides on separate disks, network storage, removable media, or virtual devices. This flexibility allows administrators to expand storage, isolate workloads, improve reliability, or protect sensitive information without altering the logical organization visible to applications. Every object stored within the filesystem possesses metadata describing its ownership, permissions, timestamps, size, and other attributes. The data contained within a file is only part of its identity. Administrative decisions frequently depend upon these associated attributes rather than upon the file's contents themselves. A configuration file with incorrect ownership may prevent a service from starting despite containing perfectly valid configuration. A script lacking execute permission remains inert regardless of its correctness. Linux further distinguishes between ordinary files, directories, symbolic links, device nodes, sockets, and named pipes. Although they appear together within the same directory listings, they perform entirely different roles within the operating system. Symbolic links permit one location to reference another without duplicating data. Device nodes provide controlled access to hardware. Sockets facilitate communication between processes. This diversity illustrates how the filesystem serves as both a storage mechanism and a universal interface for system resources. Reliability depends upon filesystems preserving consistency even when unexpected failures occur. Modern filesystems therefore employ techniques such as journaling, copy-on-write semantics, checksums, or snapshots to reduce the likelihood of corruption following power failures or hardware faults. Administrators need not understand every implementation detail immediately, but they should appreciate that not all filesystems offer identical guarantees regarding performance, resilience, scalability, or recovery. Disk space itself represents only one aspect of filesystem health. Administrators must also consider inode availability, fragmentation where applicable, mount options, filesystem permissions, backup strategies, and the consequences of unplanned storage failures. Systems rarely fail because disks simply become full; they more often fail because administrators misunderstood how storage was organized or neglected to monitor its changing state. The filesystem also serves as the historical memory of a Linux system. Configuration survives reboots because it is stored persistently. Log files preserve evidence of previous events. Applications maintain databases recording transactions, while scheduled backups preserve information against accidental loss. Understanding where information resides is therefore inseparable from understanding how systems recover from failure. For experienced administrators, navigating the filesystem becomes less an exercise in memorization than one of reasoning. When confronted with an unfamiliar application, they naturally ask where its configuration resides, where it stores logs, where its data lives, which user owns its files, and how those resources fit within the broader hierarchy. Linux was deliberately organized so that these questions usually have consistent answers. The Unix filesystem is therefore much more than a method of storing documents. It is the organizing framework through which Linux exposes the state of the operating system itself. Mastery begins when directories cease to appear as arbitrary folders and instead reveal themselves as carefully designed components of a coherent architectural philosophy, one that has remained relevant through generations of hardware, software, and technological change.