Linux File System Hierarchy
Linux filesystem hierarchy through root, standard directories, and mount points.
The Linux filesystem looks unusual at first because everything begins at a single root directory, /, rather than with drive letters. That design is deliberate. Devices, removable media, temporary files, system configuration, and user data all live inside one directory tree. Different storage devices may be mounted at different points in that tree, but the interface stays consistent. For operators and developers, the real skill is learning what kinds of data belong where.
The broad layout is guided by the Filesystem Hierarchy Standard. Not every distribution follows it perfectly, but the major conventions are stable enough that moving between Debian, Ubuntu, Red Hat, or Alpine is much easier once you know the landmarks.
/etc holds system configuration. If you want to inspect service settings, network configuration, passwd files, or package repository definitions, this is the first place to look. etc should contain configuration, not application state. When a package writes changing runtime data there, backups and automation become messy.
/usr contains most userland programs and read-only shareable data installed by the distribution. Binaries often live in /usr/bin, libraries in /usr/lib, and architecture-independent data in /usr/share. A useful mental model is that /usr is what the vendor provides, while /etc is how this machine customises it.
/var stores variable data such as logs, caches, spool files, and databases. Anything expected to grow or change during normal operation usually belongs here. That is why full disks often turn out to be a /var problem, not a root filesystem problem in the abstract. Log rotation, cache limits, and database storage policy all matter because /var is where operational churn accumulates.
User data usually lives in /home, while the superuser's home is commonly /root. Temporary data appears in /tmp and sometimes /var/tmp, with the former often cleaned more aggressively. Application add-ons may live in /opt, while site-specific service data may appear in /srv depending on local conventions.
Several directories represent kernel and device interfaces rather than ordinary stored files. /dev exposes devices as files. /proc presents process and kernel state. /sys exposes hardware and kernel subsystem details. /run stores volatile runtime state such as PID files and sockets that must exist early in boot. These paths are useful precisely because scripts and tools can interact with system state using ordinary file operations, even when the backing implementation is virtual.
The hierarchy matters because it reduces guesswork. Backing up /etc and /home serves a different purpose from backing up /var/lib. Mounting /tmp with strict options addresses a different risk from making /var/log larger. Once you stop seeing the filesystem as a pile of folders and start seeing it as a contract between the kernel, the distribution, applications, and operators, Linux becomes much easier to navigate and maintain.