Linux Storage Explained: Disks, Partitions, Filesystems, and Mount Points

Linux presents files through one directory tree beginning at /, but the data underneath that tree can live on different disks, partitions, virtual devices, or network storage. Understanding how those layers connect is essential before you start resizing disks, editing /etc/fstab, or troubleshooting storage problems.

The key is to separate four concepts that beginners often treat as the same thing: a disk provides storage, a partition can divide that storage, a filesystem organizes data, and a mount point places that filesystem into the Linux directory tree.

💾 Start with the Storage Layers

A common beginner mistake is to use the words disk, partition, and filesystem interchangeably. They describe different layers.

The simplified relationship is:

Real systems can be more complex. Storage may involve LVM, RAID, encryption, device mapper layers, network filesystems, containers, or filesystems that span multiple devices. The simple model is still the right place to begin because it makes those advanced layers easier to add later.

💽 What Is a Block Device?

Linux represents many storage devices through block device interfaces. Instead of applications having to understand every physical disk controller directly, the kernel exposes devices that software can access as blocks of data.

You commonly see device paths under /dev. Depending on the environment, examples might resemble:

/dev/sda
/dev/sda1
/dev/vda
/dev/vda1
/dev/nvme0n1
/dev/nvme0n1p1

These names are examples of common naming patterns, not universal guarantees. A virtual machine, cloud server, physical host, and NVMe system can expose storage differently.

🧩 What Is a Partition?

A partition describes a region of a storage device. Partition tables let one disk be divided into separately addressable areas.

Conceptually, a disk might look like this:

Each partition can then potentially be used for a different purpose. One could contain a filesystem mounted as the root filesystem, another could be used for boot-related data, swap, or another storage role.

Partitions are not mandatory in every possible Linux storage design. A filesystem can also be created on certain whole block devices, and more advanced storage stacks can introduce additional layers between the physical device and filesystem.

The important idea is that a partition is a boundary in storage; it is not itself the filesystem that stores ordinary directories and files.

🗂️ What Is a Filesystem?

A raw storage region does not automatically provide familiar objects such as filenames and directories. A filesystem defines how data and metadata are organized so that the operating system can work with files.

Within a filesystem, names and file objects are related but not identical. Hard links and symbolic links in Linux illustrate the difference: two hard-linked names share an inode, while a symlink stores a pathname that Linux resolves.

Linux supports multiple filesystem types. Examples commonly encountered on Linux systems include ext4 and XFS, while other filesystem types are used in particular environments and workloads.

At the conceptual level, a filesystem is responsible for things such as:

• organizing files and directories;
• tracking metadata;
• tracking which storage space is allocated or available;
• supporting filesystem-specific features and limits.

This is why the phrases “the disk is full” and “the filesystem is full” are not perfectly interchangeable. The operating system usually reports file usage within a mounted filesystem, while the underlying device may participate in a larger storage arrangement.

📍 What Does Mounting Mean?

Linux does not normally assign independent drive letters such as C: or D:. Instead, accessible files are presented through one hierarchy rooted at /.

Mounting attaches a filesystem to a location in that hierarchy.

That location is the mount point.

For example, imagine a separate filesystem mounted at:

/data

After the mount is active, accessing files below /data accesses the mounted filesystem.

This design allows multiple filesystems to appear as parts of the same directory tree.

🌳 One Directory Tree Can Use Several Filesystems

The Linux directory tree is a namespace: it describes where files appear. It does not mean every directory necessarily belongs to the same storage device.

A simplified server might look conceptually like this:

/
├── etc
├── home
├── var
└── data

But underneath, the storage could be arranged as:

The exact layout is system-specific. The lesson is that directory location and physical storage location are related through mounts rather than being the same concept.

🔍 Inspect Block Devices with lsblk

The lsblk command lists block devices and is one of the fastest ways to understand a server’s visible storage structure.

Run:

lsblk

A simplified example might look like:

NAME   SIZE TYPE MOUNTPOINTS
vda     40G disk
├─vda1   1G part /boot
└─vda2  39G part /

The exact columns and output depend on the system and tool version, so treat this only as an illustrative shape.

Read the hierarchy from the top downward:

To include filesystem-related information, a useful observational command is:

lsblk -f

This can display filesystem type, labels, UUID information, and mount points when available.

🔎 Inspect Mounted Filesystems with findmnt

lsblk starts from block devices. findmnt approaches the problem from the mounted-filesystem side.

Run:

findmnt

The command can list mounted filesystems in a tree-like form, making it easier to see how filesystems are attached beneath the Linux directory hierarchy.

You can also ask which filesystem contains a particular path:

findmnt --target /var/log

This is useful because a path such as /var/log does not tell you by itself which mounted filesystem ultimately contains it.

📊 Where df Fits In

The df command answers a different question: how much space is available and used on mounted filesystems.

For a human-readable view:

df -h

You might see a filesystem associated with a mount point such as /, /boot, or another directory.

This creates a useful distinction:

If df reports a filesystem at 95% usage, that tells you about space consumption. It does not by itself fully explain the underlying block-device topology.

🔄 Put the Entire Path Together

Imagine a server with an additional storage device. A simplified storage path could be:

Each stage answers a different question:

⚙️ What Is /etc/fstab?

Mounting a filesystem once and configuring it to be mounted during normal system startup are separate concepts.

Linux systems commonly use /etc/fstab to describe filesystems and mount configuration that system tools should know about.

You can safely inspect the file without modifying it:

cat /etc/fstab

An entry can describe information such as:

• the filesystem source;
• the target mount point;
• filesystem type;
• mount options;
• additional filesystem-check or dump-related fields.

Sources are often identified using stable identifiers such as filesystem UUIDs rather than relying only on device names.

🧠 Why UUIDs Appear in Storage Configuration

Device paths such as /dev/sdb1 are convenient for humans, but administrators often want a more persistent way to identify a particular filesystem.

A filesystem UUID provides an identifier that tools can use to refer to that filesystem.

You may see UUID information with:

lsblk -f

And findmnt can work with filesystem identifiers as well as device paths and mount points.

The important concept is not memorizing UUID syntax. It is understanding that the filesystem identity and its current device pathname are separate pieces of information.

🧪 Mini Lab: Map Your Server’s Storage

lsblk

lsblk -f

findmnt

findmnt --target /var/log

df -h

⚠️ Common Storage Mistakes

💡 A Better Storage Troubleshooting Model

When storage behaves unexpectedly, work through the layers instead of jumping directly to random commands.

1. Does Linux see the block device? Inspect the device layer with lsblk.
2. What structure exists on it? Look for partitions and filesystem information.
3. Is the filesystem mounted? Inspect the mount tree with findmnt.
4. Where is it mounted? Identify the mount point that exposes it in the directory hierarchy.
5. How much capacity is available? Use df -h for mounted filesystem usage.
6. Should the mount persist? Inspect configuration such as /etc/fstab when persistent mounting is relevant.

What You Should Remember

Linux storage is easier to understand when you separate the physical or virtual storage resource from the filesystem namespace that applications see.

The common mental model is:

Then choose your inspection tool based on the question. Use lsblk for block-device structure, findmnt for mount relationships, and df for mounted filesystem capacity.