Red Hat: The Linux File System

In the third part we learned to get around the terminal: pwd for where we are, ls for what’s there, cd for moving about. But knowing how to walk in a city is not the same as knowing its map. Today we draw Linux’s map: which folder holds what, what the “root directory” is, how a file’s real identity is stored, and why in Linux everything really is a file.

In Part 1 we said “in Linux everything is under /”; in Part 2 we saw from afar how Anaconda partitioned the disk. Now we step into that tree and walk it branch by branch. Don’t worry, you won’t get lost: by the end this tree will feel logical, not memorized.

Everything is a file

Let’s start here, because all of Linux’s logic rests on it. This principle, inherited from Unix, says: you can reach almost everything in the system through a single, uniform interface, that is, like a file.

Plain text and programs are files, fine. But here’s the beautiful part:

• Directories are files too; special files that hold the list of names inside them.
• Devices (disk, keyboard, sound card) appear as files under /dev. Writing to the disk is like writing to a file.
• Running processes and the kernel’s state are read like files under /proc and /sys. You “read” how full memory is with cat /proc/meminfo.

The practical benefit is enormous: learn a handful of commands (ls, cat, cp, echo) and you can manage your documents, your settings, your hardware and the system’s live state with those same commands. Where Windows needs a separate tool for each, in Linux they all work with the same “read from a file, write to a file” idea. We’ll see concrete examples by the end.

The top of the tree: the root directory

Everything starts at the root directory; its symbol is a single slash: /. It’s the very top of the tree, and all paths branch from it. Let’s look at the top with ls -l /:

There’s something interesting in the output: the bin, lib, lib64 and sbin lines start with an l and have an -> usr/bin next to them. These are symbolic links (shortcuts); the real folders are now gathered under /usr, and the old names remain as shortcuts for compatibility. You’ll also notice a few folders like afs at the very top of the list; they exist on every RHEL but are usually empty. afs is a mount point reserved for the AFS (Andrew File System) distributed file system; if the OpenAFS client isn’t installed it just sits empty, no need to delete it. You can also picture how the shell resolves a path you type:

flowchart TD
    A["A path: /home/mehmet/report.txt"] --> B["start at / the root"]
    B --> C["go into home"]
    C --> D["go into mehmet"]
    D --> E["find the file report.txt"]

An absolute path (one starting with /) is always resolved from the root, step by step. Remember the absolute/relative distinction from Part 3: a relative path starts from where you are, an absolute path always from the root.

A tour, folder by folder: the FHS

So what does each of these folders under the root do? Good news: this layout isn’t random, it’s standardized by the FHS (Filesystem Hierarchy Standard). That’s why whichever Linux you sit down at, you find the same thing in the same place.

Let’s also see the big picture of the tree (the most important branches):

flowchart TD
    R["/ root"] --> A["/etc · config"]
    R --> B["/home · users"]
    R --> C["/usr · programs"]
    R --> D["/var · logs, changing data"]
    R --> E["/boot · kernel"]
    R --> F["/dev, /proc, /sys · devices and kernel"]

Into /usr and /var

Let’s look more closely at two big branches, because they fill most of the disk (we saw them at the top of du).

• /usr is the “read-only” world of installed software: /usr/bin user commands (1545 on screen!), /usr/sbin admin commands, /usr/lib and /usr/lib64 shared libraries, /usr/share architecture-independent data (man pages, icons, fonts), /usr/local software you install by hand outside the package manager. Remember the /bin -> usr/bin shortcut from Part 3: everything really gathered here.
• /var (“variable”) is data that constantly grows and shrinks: /var/log system logs (the first place to look when something breaks), /var/cache cache, /var/spool printer and mail queues, /var/lib programs’ persistent state (databases live here). When a server warns “disk full”, the first suspect is often /var/log.

/boot: where the kernel lives

Let’s look closely at one branch, because you know it from Part 2. /boot holds everything the computer needs while starting up:

vmlinuz-6.12.0-211.51.1.el10_2.x86_64 is the kernel itself; initramfs-...img is the initial RAM disk used at boot; grub2/ is the bootloader. In Part 2’s “booting from the ISO” section we described these files being loaded into memory. We also took the version number (6.12.0-211...) apart there; here it is on disk.

File operations: create, copy, move, delete

We learned to walk the tree; now let’s prune the branches ourselves. The basic commands for working with files and folders are few and used every day:

• touch file creates an empty file (or updates its timestamp if it exists).
• cp source dest copies. To copy a folder with its contents, cp -r (recursive).
• mv source dest moves. The interesting part: mv old.txt new.txt is also renaming; because, as you’ll see shortly, the name is a label separate from the file itself, and moving is just changing the label.
• mkdir folder makes a folder; for a whole nested chain at once, mkdir -p a/b/c. An empty folder is removed by rmdir.
• rm file deletes. To delete a folder and its contents, rm -r folder.

A file’s identity: type, permissions and inode

Now let’s zoom in on a single file. A file has three basic pieces of identity: its type, its permissions and its inode.

File types

In Part 3 we briefly saw that the first letter of ls -l output tells the file type. Let’s see them all together now:

The first letter of the line gives away the type:

The nine letters after the first (rwxr-xr-x) are the permissions; we’ll cover those at length in Part 6, “users and permissions”. For now, recognizing the type is enough.

inode: a file’s real identity

Now a mind-bending but very important fact: a file’s name is not written in the file itself. A file’s real identity is a record called the inode; it holds its owner, permissions, size, timestamps and where the data sits on disk. The name is just a label kept in a directory that points to an inode number. stat shows a file’s full inode information:

This “name apart, file apart” idea feels odd at first but explains a lot: renaming a file is really just changing the label (the data never moves), and one file can have several names. That’s exactly where links come from.

The four timestamps

The bottom four lines of stat output are the file’s timestamps, and most people confuse them:

• Access (atime): when the file was last read.
• Modify (mtime): when its content last changed. This is the date you see in ls -l.
• Change (ctime): when the inode info (permissions, owner, name) last changed; even if the content doesn’t change, changing permissions updates ctime.
• Birth (btime): when the file was created (a newer addition; not on every file system).

This distinction has practical value: “when was this file last touched” and “when did its content last change” are different questions, and searches like find -mtime look exactly at these stamps.

A bit more on the inode: a directory is a name-book

Once you understand the inode, you can figure out what a directory is: a directory is a book mapping names to inode numbers. It holds lines like “report.txt → 5028314”, that’s all. Deleting a file (rm) is really removing a line from this book and decrementing the count of names pointing to that inode; when the count hits zero, the data is truly freed. Let’s see it concretely:

Two nice details: (1) df -i shows the number of inodes on the disk. Even if the disk has free space, if inodes run out (millions of tiny files) you get a “disk full” error; an experienced sysadmin checks df -i alongside df -h. (2) the link count (Links) in stat speaks: report.txt’s count is 2 because hardlink.txt points to the same inode. The fs-demo directory’s count is 3, because every directory comes with at least two links (its own name and the . inside it) and each subfolder adds one more (here, logs). So from a directory’s link count you can even tell how many subfolders it has.

file: type by content

ls tells you the shell type of a file; but what’s inside it? The file command guesses what a file is by its content, not its name:

In Linux the extension (.txt, .sh) is not required; a file can be text without a .txt name. Content is what decides, so file is very useful: with one command you learn whether a mysteriously named download is really an image, a program or a compressed archive.

Links: one file, several names

We saw that the name and the file are separate things. So we can give one file two names. There are two kinds of link, and the difference matters:

flowchart TD
    N1["report.txt (name)"] --> I["inode 5028314<br/>the real file + data"]
    N2["hardlink.txt (name)"] --> I
    S["symlink.txt (name)"] -->|"points to a path"| N1

• Hard link: a second name given to the same inode. Made with ln report.txt hardlink.txt. In ls -li both have the same inode number and a Links count of 2. Both are equally “real” files; deleting one leaves the data intact as long as the other name exists. Its limit: it works within the same disk partition and not on directories.
• Symbolic link (symlink): a small shortcut file that points to a path, not to a file. Made with ln -s report.txt symlink.txt. It shows in ls -l with a leading l and -> report.txt. If the target is deleted it’s left “broken” (nothing to show). In return it works across disks and can point to directories; the bin -> usr/bin in the root directory was exactly this.

You’ll see symlinks a lot in daily life: pointing a stable name at the “current version” of a program, or linking a config file to another place. Hard links are rarer but are the backbone of backup systems.

A first look at permissions: sticky and setuid

We’ll cover permissions (rwxr-xr-x) fully in Part 6, but two special bits will show up in the file system right away; just know their names:

• Sticky bit (t): /tmp permissions end with drwxrwxrwt. /tmp is a shared folder everyone can write to; thanks to the sticky bit, everyone can delete their own files but not someone else’s. Like a “mind your own trash” rule in a shared bin.
• Setuid bit (s): /usr/bin/passwd has rws in its permissions. Normally a program you run runs with your privileges; a setuid program runs with its owner’s (root’s) privileges. passwd is like this: to write your password into /etc/shadow it briefly becomes root. Powerful but to be used carefully; it’s one of the first things security audits look at.

”Everything is a file”, really: /proc and /dev

Remember the principle from the start. Now let’s look at its two most striking examples: here the things we call “files” don’t exist on disk at all, the kernel produces them on the fly.

/proc: the kernel’s window

/proc is a virtual file system that takes up no real space on disk; the “files” inside show the current state of the system. You read them with cat, as if they were ordinary text files:

• cat /proc/cpuinfo gives the processor, cat /proc/meminfo memory, cat /proc/loadavg the system load.
• Each running process has a folder named by its number: /proc/1234 holds that process’s info.
• Tools like top, free and ps actually read /proc behind the scenes; you can read it directly too.
• The ones under /proc/sys are readable and writable kernel settings. By writing a number to a file you can change the kernel’s behavior; the pinnacle of “everything is a file”.

/dev: devices as files, and /dev/null

Under /dev every piece of hardware appears as a file. The disk is /dev/sda, its first partition /dev/sda1. But the few you’ll use most aren’t even real hardware; they’re virtual devices provided by the kernel:

What is /dev/null? Here’s the most famous one. /dev/null is a “black hole” that swallows and discards everything written to it; if you try to read it, it ends immediately, it’s empty. What’s it for? To silence a program’s unwanted output:

command > /dev/null       # throw away the normal output
command 2>/dev/null       # throw away only error messages
command &>/dev/null       # throw away both output and errors

In Part 3 we used 2>/dev/null to silence the “Permission denied” lines from find; now you know why it worked: the error messages were going to that black hole. Its two siblings come in handy often too: /dev/zero produces endless zeros (to create an empty file or wipe an area), /dev/urandom produces random bytes (to generate passwords and keys). So /dev isn’t only hardware; it also holds taps that “produce and swallow” data.

What is a file system? From block device to mount point

So far we’ve seen the tree’s logic. But how does this tree actually sit on a physical disk? Here three concepts stack on top of each other, and telling them apart is the foundation of system administration.

At the bottom is the block device. A block device is a storage device that keeps data in fixed-size blocks and allows direct (random) access to any point; in short, anything that behaves “like a disk”. Examples: the internal hard disk or SSD (/dev/sda, /dev/nvme0n1 for NVMe SSDs), a USB flash drive you plug in (/dev/sdb), an external portable disk, a memory card (/dev/mmcblk0), even a CD/DVD (/dev/sr0). They appear with a leading b in ls -l; their opposite is the character device (c, like the keyboard or /dev/null) that streams data byte by byte. A NAS is usually not a block device: it is mounted as a folder over the network via NFS or SMB; only methods like iSCSI present remote storage as a local block device. Our disk is /dev/sda; partitions are cut on top (sda1, sda2…). Inside a partition a file system is created; the file system is the format that organizes that raw space into “files, directories, inodes”. At the top, that file system is attached to a mount point and becomes part of the tree. lsblk -f shows the whole stack on one screen:

flowchart TD
    A["Block device<br/>/dev/sda (raw disk)"] --> B["Partition<br/>/dev/sda3"]
    B --> C["LVM and file system<br/>rhel-root, format: XFS"]
    C --> D["Mount point<br/>/ (attached to the tree)"]

Mounting and /etc/fstab

Attaching a file system to the tree is called mounting, detaching it umount. But who knows which disk goes where each time the machine boots? The answer is the /etc/fstab file:

Each line in /etc/fstab is the permanent record of the layout Anaconda built in Part 2: the disk by UUID (so it doesn’t get confused even if the name changes), the mount point, the file system type and options. Every time the machine boots the system reads this file and mounts the disks in place. When you plug in a USB stick you can mount it by hand with sudo mount /dev/sdb1 /mnt, or leave it to the desktop’s automatic mounting; the findmnt and mount commands show what’s mounted where at the moment. We’ll grow disks and play with LVM in detail in Part 11.

Disk and mounting: df and du

We’ve seen the tree and the files; but how does this tree sit on physical disks? Two commands give that picture.

df: file systems and mount points

df (disk free) looks at the system’s file systems as a whole: which partition is mounted where, how full:

Note the “Mounted on” column: this is exactly the mount point concept. In Part 2, when Anaconda partitioned the disk, the root partition was mounted on /, the separate /boot partition on /boot, the /home partition on /home. So when you go into /home/mehmet you’re actually inside a separate disk partition, but nothing in the tree gives it away; everything looks like a single whole. When you plug in a USB stick it’s usually mounted automatically under /run/media/mehmet/....

du: how much space does this folder take?

df looks at the whole; how much space a particular folder takes is told by du (disk usage):

du -sh <folder> gives a folder’s summary size; sort -h sorts the “human-readable” sizes from small to large. When you say “my disk is full, who’s the culprit?”, du is your first command. In short, keep the two apart: df = how full is my disk, du = how much space does this folder take.

Finding files: find and tree

Searching a huge tree by hand is impossible. find is the most powerful way.

The basic pattern is simple: find <where> <criterion>.

find /etc -name "*.conf"      # by name (config files)
find ~ -type f                # files only (not directories)
find /var -size +100M         # larger than 100 MB
find /home -mtime -1          # changed in the last day
find ~/fs-demo -type f -delete   # delete what's found (careful!)

The “Permission denied” lines you see are normal: find can’t enter folders you have no read permission for. For a system-wide search you may need sudo in front. If you want a quick lookup by name, locate (plocate on RHEL) is faster but searches a pre-built index; we’ll see installing it in Part 7.

And if you want to see the tree visually, tree:

Wildcards: many files at once

Instead of typing file names one by one, you can write a pattern and catch many files at once. It’s the shell that does this (not the command): you write the pattern, the shell expands it to the matching file names; this is called globbing.

• * any number of characters: *.txt all .txt files, report* those starting with “report”.
• ? a single character: file?.txt → file1.txt, file2.txt (but not file10.txt).
• [...] brackets, a set: file[12].txt → only file1.txt and file2.txt; [a-z] a letter range.
• {...} braces, options: file.{txt,log} → file.txt and file.log.

This works with every command like ls, cp, rm because the shell does the work, not the command. That’s exactly why you should be careful with rm: before deleting, list the same pattern with ls to see what you’ll delete. Even echo * prints everything in the current directory; that’s the harmless way to test a pattern.

Try it yourself

Answer each question in your head first, then try it on your machine.

Question 1 — Where does the path lead? (easy)

Read the path /home/mehmet/fs-demo/report.txt from left to right. How many directories do you pass through to reach the file, and is this an absolute or a relative path?

Question 2 — Read the type (easy)

In ls -l output one line starts with brw-rw---- and another with lrwxrwxrwx. What kinds of files are these?

Question 3 — The same file? (medium)

Two files show the same inode number in ls -li. What does that mean? And if one were a symlink, what would the inode numbers look like?

Question 4 — Silence the noise (medium)

A command prints both a result and a lot of error messages; you don’t want to see the errors. What do you do? And if you wanted to throw away both the result and the errors entirely?

Question 5 — df or du? (easy)

(a) “What percent is my root disk full?” (b) “How much space does my Downloads folder take?” Which command for which question?

Question 6 — Copy and move (easy)

In ~/fs-demo there is report.txt. Create a backup called report.bak, then make a folder called backup and move this backup into it. Which commands, in order?

Question 7 — Pick the right pattern (medium)

A folder has report1.txt, report2.txt, report10.txt and notes.txt. What does ls report?.txt show? And ls report*.txt?

Summing up

We’ve drawn Linux’s map. You now know what’s in which folder, can read a file’s real identity, and see what the “everything is a file” principle means. Put the following in your pocket.

Sources

• Filesystem Hierarchy Standard (FHS 3.0): the official standard for the directory tree.
• RHEL 10 documentation: file systems and storage management.
• man hier: the manual page describing the directory tree on your own machine (type man hier, try it).
• The Linux Command Line (William Shotts): the file system and navigation chapters, free.
• The “everything is a file” principle: the Unix philosophy.