Learn Linux - System Architecture & Filesystem Hierarchy Standard (FHS)

#Introduction

After episode 1 where we discussed the history and philosophy of Linux — from the Unix era at Bell Labs, the GNU project, the Linux kernel by Linus Torvalds, to the "everything is a file" principle — in this episode we'll dissect the internal workings of the Linux system: how its layers are structured, and how system files are organized in a standard directory structure.

Why is this important? Because almost every Linux administration task boils down to "putting or reading files in the right place". Configuration lives in /etc, application data in /var, programs in /usr, and logs can fill up /var/log. A DevOps Engineer who doesn't understand this structure will be confused looking for the nginx config file, reading logs, or finding out why the server disk is full. Understand the architecture and the FHS, and half of your journey in this series will feel lighter.

This episode 2 will cover two big things: first, the four layers of Linux architecture (Hardware → Kernel → Shell → Applications); second, the Filesystem Hierarchy Standard (FHS) along with the function of each major directory. We'll also explore your system directly to see this structure in practice.

#Linux System Architecture Layers

Linux is built like a multi-story building. Each layer has a specific role, and programs in the upper layers never talk directly to the hardware in the bottom layer — they communicate through the layers below.

#Hardware

The bottom layer: CPU, RAM, disk, network card, and all physical hardware. Hardware doesn't understand the concept of "files" or "processes" — it only understands machine instructions and electronic signals.

#Kernel

The kernel layer is the bridge between hardware and software. The kernel is the only program allowed to communicate directly with hardware — managing CPU time, allocating memory, handling disk and network I/O, and acting as the "traffic police" ensuring each process gets its fair share. When a program needs to write to disk, it doesn't write directly to hardware; it asks the kernel via a system call.

This is why when you ran uname -a in episode 0, the output was the kernel version — because the kernel is the true identity of a Linux system. The kernel isn't just one thing; it can also be loaded as modules (like drivers) as needed.

#Shell (Bash)

The shell is the command interpreter that stands between the user and the kernel. You type ls /home in the terminal, the shell interprets it, then asks the kernel to execute it. The most popular shell is Bash (Bourne Again Shell), but there are also zsh, fish, and sh.

The best analogy: the shell is the restaurant waiter between the guest (user) and the kitchen (kernel). The guest doesn't need to know how to cook — just place the order, and the waiter relays it to the kitchen and brings back the result. The shell protects you from the complexity of system calls, while giving you a language (shell syntax) to control the system.

#User Space / Applications

The top layer: all the programs you run — nginx, databases, bash scripts, even office applications. These programs live in user space, strictly separated from kernel space. This separation is the foundation of Linux security: if an application crashes or is hacked, the impact is isolated and doesn't damage the kernel.

Four layers of Linux architecture

┌─────────────────────────────────────────┐
│  User Space / Applications              │  nginx, sshd, database, scripts
├─────────────────────────────────────────┤
│  Shell (Bash, zsh, fish)                │  command interpreter
├─────────────────────────────────────────┤
│  Linux Kernel                           │  hardware & resource manager
├─────────────────────────────────────────┤
│  Hardware                               │  CPU, RAM, disk, NIC
└─────────────────────────────────────────┘

#Filesystem Hierarchy Standard (FHS)

Now we get to the most practical part: where are system files placed? The answer is governed by the FHS (Filesystem Hierarchy Standard) — the standard that defines the directory structure of Linux systems. All distros that follow the FHS have the same structure, so your knowledge on Ubuntu still applies to Rocky Linux, Debian, or Arch.

Think of the Linux filesystem like a national archive building: all documents (files) are stored in an agreed-upon folder system. A new archivist can immediately find any document — which floor, which cabinet — just by reading its path name. Same with Linux: once you know the functions of /etc, /var, and /usr, you can guess a directory's contents even before opening it.

Everything is rooted in the root directory / (slash). All other directories are branches of this tree — there's no C: or D: drive like in Windows; it's all one tree starting from /.

Let's dissect the key directories:

#/bin and /sbin — System Programs

• /bin contains core commands the system needs to boot and operate at a basic level: ls, cp, mv, cat, bash. In the past it only held essential programs; on modern distros, /bin is often a symlink to /usr/bin.
• /sbin contains system administration programs usually only run by root: iptables, fdisk, shutdown, mount.

#/etc — System Configuration

This may be the most important directory for you as a DevOps Engineer. /etc contains all configuration files for the system and applications: /etc/nginx/nginx.conf, /etc/ssh/sshd_config, /etc/hosts, /etc/passwd, /etc/resolv.conf. All settings are in text format, following the "everything is a file" principle we discussed in episode 1.

#/home and /root

• /home contains the personal directory of every regular user: /home/arman, /home/budi. Each user has their own directory for documents, personal configuration (~/.bashrc), and work files.
• /root is the personal directory of the root user (superuser). It's deliberately separated from /home so that when the system has problems and other users can't log in, root can still get in.

#/var — Variable Data

The directory for data that changes (varies) while the system runs: /var/log (system logs), /var/www (nginx web root), /var/lib (database data), /var/tmp. If the disk is full, the most common cause is a swollen /var/log.

#/tmp — Temporary Files

The place for temporary files that are cleared on reboot. /tmp is a public space — all users can write to it, so never store important data here.

#/usr — User System Resources

The largest directory for programs and data that don't change: installed programs (/usr/bin, /usr/sbin), libraries (/usr/lib), documentation (/usr/share), and source code (/usr/src). Despite the name "user", /usr doesn't belong to a user — it's the place for the system's "many utilities and resources".

#/dev — Device Files

Thanks to the "everything is a file" philosophy, hardware is represented as files in /dev: /dev/sda (disk), /dev/nvme0n1 (NVMe SSD), /dev/tty (terminal). Programs can read/write devices as if they were ordinary files.

#/proc and /sys — Virtual Filesystems

This is the most interesting part and the most often misunderstood. /proc and /sys aren't real directories on disk — they are virtual filesystems created by the kernel while running. Reading a file in /proc means reading data directly from the kernel:

cat /proc/cpuinfo
cat /proc/meminfo
cat /proc/uptime

/proc/cpuinfo shows processor details, /proc/meminfo shows memory, and /proc/uptime shows how long the system has been running. The kernel updates these files dynamically every time they're read — never static. /sys is a similar virtual filesystem focused on device information and kernel parameters.

#/opt and /mnt

• /opt is the directory for additional/optional software installed outside the standard package manager (for example, commercial applications distributed in their own folder).
• /mnt is a temporary mount point — the place where you mount external filesystems like USB drives or additional disks before they're moved to a permanent location.

#FHS Directory Summary Table

#Exploring a Real System

Theory is done — now let's prove it by exploring your own system. Open a terminal and run the following commands:

ls /

bin  boot  dev  etc  home  lib  lib64  media  mnt  opt
proc  root  run  sbin  srv  sys  tmp  usr  var

Notice — all the directories we just discussed are here: etc, home, var, proc, sys, dev, usr, tmp. This is the national archive tree we talked about.

Next, check your filesystem and storage conditions:

df -h
lsblk

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       20G   4.2G   15G  23% /

A brief explanation:

Notice the Mounted on column in the df -h output: it shows where each filesystem is mounted in the / tree. The root filesystem /dev/sda2 is mounted at / — and all other directories, from /etc to /home, are branches from there.

#Common Pitfalls

1. Editing files in /proc//sys. As explained above, these are virtual filesystems. Modifying them directly can make the kernel unstable. Use /etc or the appropriate commands.

2. Putting files in the wrong place between /home and /var. Your personal data and scripts should be in /home; service data (logs, web root, databases) belongs in /var. Putting a web root in /home/arman/www will cause problems when other users need to access it or when web service permissions are restricted.

3. Deleting system directories to "save disk space". Deleting the contents of /usr or /bin can make the system unable to boot. If the disk is full, check first with du -sh /var/log/* before deleting anything.

4. Assuming /tmp is safe for important data. /tmp is cleared on reboot and can be accessed by other users. Store important data in /home or /var.

5. Editing configuration files without a backup. Before modifying files in /etc (for example /etc/ssh/sshd_config), make a habit of copying it first: cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak. If the configuration breaks, you can easily restore it.

#Conclusion

In this episode 2, we've dissected Linux's internal architecture: the four layers (Hardware → Kernel → Shell → Applications) that explain how the system works as a multi-story building, and the Filesystem Hierarchy Standard that explains where each file is placed. You've also explored a real system with ls /, df -h, and lsblk.

Key takeaways:

• Linux works in four layers; the kernel is the bridge between hardware and software.
• The shell is the command interpreter between you and the kernel.
• FHS is the standard for file locations — /etc for configuration, /var for variable data, /home for personal files, /proc//sys for virtual kernel data.
• df -h and lsblk are your entry points for understanding your storage conditions.
• Don't edit files in /proc//sys, and always back up configuration before changing it.

With this map in your head, you're now ready to move on to the most hands-on episode 3: Filesystem Navigation & File/Folder Management — mastering pwd, ls, cd, mkdir, cp, mv, rm, up to wildcards, complete with exercises to build a real project structure. Stay motivated, because starting from this episode you'll truly "hold" Linux!