Filesystem

Linux hub

A filesystem is the method an operating system uses to organise, store, and retrieve files on a storage device. Linux uses ext4 and XFS most commonly in production, plus virtual filesystems like /proc and /sys that exist only in memory.

What Is a Filesystem in Simple Terms

Imagine a massive library. The books are your data. The filesystem is the cataloguing system — the rules for how books are labelled, where they go on shelves, and how you find them again. Without it, every piece of data would be indistinguishable from every other.

A filesystem answers three fundamental questions: where is the data stored on disk, what is it called, and who is allowed to access it.

How It Works

Linux sits a Virtual File System (VFS) layer between the kernel and actual storage. VFS provides a single consistent interface for all filesystem types. Applications call open(), read(), write() — they never need to know whether the data is on ext4, XFS, NFS, or a kernel virtual filesystem.

◈ DIAGRAM

Application (nginx, postgres, node)
|
v
VFS (Virtual File System) -- unified interface
|
+----+----+----+----+
|    |    |    |    |
v    v    v    v    v
ext4 xfs  nfs  proc sys
(disk filesystem)  (virtual)

Common Linux filesystems:

TEXT

ext4    Most common for system partitions
        Journaling, good performance, backward compatible
 
XFS     High-performance, large file handling
        Default on RHEL/CentOS, Amazon Linux
        Better for large files and parallel I/O
 
tmpfs   RAM-backed filesystem
        /tmp and /run are usually tmpfs
        Fast but cleared on reboot
 
/proc   Virtual — kernel process and system info
/sys    Virtual — kernel hardware interface
/dev    Virtual — device file representation
 
NFS     Network filesystem — remote storage over network
extended (ZFS, Btrfs)  Advanced features but less common

Mounting — attaching a filesystem:

Linux has one directory tree starting at /. Every filesystem must be mounted at a mount point — a directory in that tree — before its files are accessible.

Bash

## Show all mounted filesystems
df -h
## Filesystem      Size  Used Avail Use% Mounted on
## /dev/xvda1       20G   12G  7.5G  62% /
## tmpfs           1.9G  1.2M  1.9G   1% /tmp
## /dev/xvdb1      100G   45G   55G  45% /data
 
## Show filesystem type
df -Th
## Filesystem     Type   Size  Used Avail Use% Mounted on
## /dev/xvda1     ext4    20G   12G  7.5G  62% /
## tmpfs          tmpfs  1.9G  1.2M  1.9G   1% /tmp
 
## Mount a device manually
sudo mount /dev/sdb1 /mnt/data
 
## Unmount
sudo umount /mnt/data

Persistent mounts in /etc/fstab:

TEXT

## /etc/fstab format:
## device    mountpoint  fstype  options         dump  pass
/dev/xvda1   /           ext4    defaults         0     1
/dev/xvdb1   /data       xfs     defaults,noatime 0     2
tmpfs        /tmp        tmpfs   defaults,size=2G 0     0

Checking and repairing filesystems:

Bash

## Check filesystem health (must be unmounted or read-only)
sudo fsck -n /dev/sdb1   ## -n = dry run, check only
 
## Force check on next reboot
sudo touch /forcefsck
 
## Show inode usage (can fill up before disk space runs out)
df -i
## Filesystem      Inodes  IUsed   IFree IUse% Mounted on
## /dev/xvda1     1310720  45231 1265489    4% /

Practical Commands

Bash

## Check disk space across all filesystems
df -h
 
## Check inode usage (separate from disk space)
df -i
 
## Show filesystem type
df -Th
 
## Find filesystem type of a specific path
stat -f /var/log/
 
## Check what filesystem type a device uses
file -sL /dev/xvda1
 
## List block devices and their filesystems
lsblk -f

Troubleshooting

Symptom	Command	What to Look For
Disk full errors	`df -h`	Filesystem at 100% Use%
Cannot create files despite disk space	`df -i`	Inode count at 100% IUse%
Filesystem read-only unexpectedly	`dmesg	grep error`
Mount point missing after reboot	`cat /etc/fstab`	Mount entry missing or wrong device name

Tip
A filesystem can be completely full of inodes even when disk space is available. This happens with directories containing millions of small files (like email spools or build caches). Always check df -i alongside df -h.

Remember
/proc, /sys, and /dev are not real filesystems. They have no files on disk. The kernel generates their contents in memory. You cannot run out of disk space from files in these directories.

Frequently Asked Questions

Why do production Linux servers typically choose ext4 or XFS over other filesystems?

ext4 is the long-standing default on most distributions, mature and well-tested with journaling to protect against corruption on unclean shutdown; XFS handles very large files and high-throughput parallel I/O better, which is why it's common on database and storage-heavy servers. Both differ from virtual filesystems like /proc and /sys, which don't store data on disk at all — they're kernel-generated views into process and system state, recreated fresh on every boot.

What's a common mistake when working with /proc or /sys as if they were regular filesystems?

Treating them as persistent storage — writing a tuning value to a file under /proc/sys/ (e.g. for sysctl parameters) only takes effect until the next reboot, since nothing there is backed by disk; the change must also be added to /etc/sysctl.conf (or a drop-in file) to survive a restart. Another gotcha is that some /proc entries (like process directories) can disappear mid-read if the process exits, so tooling reading them needs to handle that race gracefully.