Linux storage is organised in stacked layers, from the hardware to the application: a block device, a partition table, optional layers (RAID, LVM, encryption), a file system, and finally a mount point in the tree. This orientation page sets up that mental model for beginner to intermediate administrators, on Debian 13, Ubuntu 24.04 and RHEL / AlmaLinux 10, with RHCSA / LFCS in mind. It places each building block and points to the dedicated guide; it replaces no hands-on guide.
What you will learn
- Read the layered model of Linux storage and its stacking order.
- Recognise block devices (
sd*,nvme*,vd*,dm-*) and their naming. - Tell MBR and GPT apart, and know which one is used in 2026.
- Place the file systems (ext4, XFS, Btrfs, ZFS) and the abstraction layers (LVM, RAID, LUKS).
- Pick the right inspection tool for what you are looking for.
The layered model, from the hardware to the application
All Linux storage reads as a stack of layers, where each layer presents a new device to the one above. Understanding this stacking avoids most mistakes: you always know what you are acting on.
The canonical order, from the bottom (hardware) to the top (application), is the following:
- Block device: the physical or virtual disk (
/dev/sda,/dev/nvme0n1,/dev/vda). - Partition table: the division of the disk into partitions (
/dev/sda1,/dev/nvme0n1p1). - Optional abstraction layers: software RAID, LVM, LUKS encryption, RAID always first.
- File system: ext4, XFS, Btrfs, which structures the files (
mkfs). - Mount point: the attachment to the tree (
/,/home,/var), throughmountand/etc/fstab.
The order of the optional layers follows a logic of redundancy then encryption. RAID always goes first, on the disks, and the file system always last: you protect with redundancy first, encrypt next, format last. Between the two, LVM and LUKS combine in two ways, both common:
- LVM on LUKS (disks → RAID → LUKS → LVM → file system): a single encrypted volume, then split into logical volumes. It is the layout the Debian and Ubuntu installers set up with the "encrypted LVM" option: a single passphrase unlocks everything;
- LUKS on LVM (disks → RAID → LVM → LUKS → file system): each logical volume is encrypted separately, which lets you encrypt only some volumes (Ubuntu Community Wiki).
In both cases, encryption stays below the file system: LUKS encrypts blocks, not files.
Block devices and naming
A block device is a storage device that Linux exposes as a special file in the /dev directory. The kernel gives it a name according to the type of bus used. Recognising these prefixes immediately tells you what kind of disk you are dealing with.
| Prefix | Bus type | Example | Partition |
|---|---|---|---|
sd* | SATA, SCSI, SAS, USB | /dev/sda | /dev/sda1 |
nvme*n* | NVMe (PCIe) | /dev/nvme0n1 | /dev/nvme0n1p1 |
vd* | virtio (virtual machines) | /dev/vda | /dev/vda1 |
dm-* | device-mapper (LVM, LUKS, RAID) | /dev/dm-0 | (not partitioned) |
The sd* naming comes from the kernel's official device number registry: /dev/sda is the first SCSI/SATA disk, /dev/sdb the second. The static numbering only reserves 15 partitions per disk, but the same registry provides a major 259 (Block Extended Major) allocated dynamically to additional partitions: a GPT disk can therefore carry many more (docs.kernel.org, Linux Device List).
NVMe naming is richer because it exposes the notion of namespace. In /dev/nvme0n1p1, nvme0 is the hardware controller, n1 the namespace (a logical volume carved out of the controller), and p1 the partition. Most consumer SSDs only have one namespace, hence the near-systematic nvme0n1 (Oracle Linux blog, overview of NVMe architecture).
Three landmarks to find your way:
/dev: the special files of all block devices./sys/block: the kernel's view of each disk, read by the inspection tools.dm-*: the virtual devices created by device-mapper (LVM volumes, LUKS encrypted volumes, RAID), which do not match a physical disk but an abstraction layer.
The key distinction: a disk (sda) contains partitions (sda1), whereas a device-mapper device (dm-0) is a software construction stacked on top.
Partition tables: MBR or GPT in 2026
A partition table describes how a disk is divided. Two formats coexist, but in 2026 the default choice is largely settled.
The historical MBR (Master Boot Record) format is limited to disks of 2 TiB (2³² sectors of 512 bytes) and to 4 primary partitions (Wikipedia, GUID Partition Table). These limits make it unsuitable for modern disks.
The GPT (GUID Partition Table) format lifts these constraints: it uses 64-bit block addresses, supports disks well beyond 2 TiB, and allows up to 128 partitions in its usual implementation. GPT is part of the UEFI standard and has become the default format on recent hardware (Wikipedia, GUID Partition Table).
The simple rule: on a UEFI machine (the norm since the mid-2010s), use GPT. MBR only survives for compatibility with older systems in legacy BIOS mode or small disks.
File systems at a glance
A file system organises data into files and directories on a partition or a volume. The choice mostly depends on your distribution and your usage. This page only places each option; the details live in the dedicated guides.
| File system | Default on | Strengths |
|---|---|---|
| ext4 | Debian 13, Ubuntu 24.04 | Mature, robust, general use |
| XFS | RHEL / AlmaLinux 10 | Very scalable, large files and volumes |
| Btrfs | Fedora, openSUSE | Snapshots, subvolumes, compression |
| ZFS | (outside the kernel tree) | Integrity, snapshots, advanced pooling |
ext4 has been Debian's default file system since Debian 8 (Debian Wiki, Ext4), and remains the default of Debian 13 as well as Ubuntu 24.04. On the Red Hat side, XFS is the default file system, described as "highly scalable, high-performance, robust, and mature" for large files and volumes (Red Hat, Overview of available file systems). This Debian/Ubuntu (ext4) versus RHEL (XFS) divergence is worth knowing for the certifications.
Btrfs brings snapshots and subvolumes natively. An important point of attention: its RAID 5/6 (parity) profiles are still considered unstable because of the write hole, a risk of corruption if a failure occurs while a stripe is being written; the RAID 0/1/10 profiles are reliable (official Btrfs documentation, btrfs-man5, RAID56 section). Do not use Btrfs RAID 5/6 in production without knowing this limit.
ZFS lives outside the Linux kernel tree: its CDDL licence is considered incompatible with the kernel's GPLv2, which prevents its upstream integration. It is distributed as an out-of-tree kernel module, installed separately by some distributions (Software Freedom Conservancy, ZFS and Linux).
Finally, distinguish local file systems (ext4, XFS, Btrfs, placed on a disk) from network file systems such as NFS, which mount a remote tree as if it were local (see the NFS guide).
The abstraction layers: LVM, RAID, LUKS
Between the partition and the file system, Linux inserts optional abstraction layers. Each one meets a precise need and stacks at a precise place in the stack. All rely on device-mapper and show up as dm-*.
LVM (Logical Volume Manager) brings flexibility. It aggregates physical volumes (PV) into a volume group (VG), which is then split into logical volumes (LV) resizable online, without being constrained by disk boundaries. It sits above RAID when both are combined, and above or below LUKS depending on the chosen layout. See the LVM guide.
Software RAID, managed by mdadm, brings redundancy: it aggregates several disks into a volume that survives the failure of one disk. It is the lowest of the three layers, placed directly on top of the disks (mdadm documentation and practice, Ubuntu Community Wiki). See the mdadm RAID guide.
LUKS (Linux Unified Key Setup) brings encryption at rest: it protects the data against the physical theft of a disk. It sits above RAID, below or on top of LVM, but always below the file system: LUKS encrypts blocks, and the FS works on the decrypted volume. See the LUKS encryption guide.
Local, network or object storage
Beyond the local stack, you need to place where the data physically lives. Four big families exist; this page tells them apart in one line each, the details belonging to other sections.
- DAS / local storage: disks directly attached to the machine (SATA, SAS, NVMe, USB), exposed in
/dev. - NAS: file sharing over the network through NFS (Unix/Linux world) or SMB/CIFS (Windows interoperability).
- SAN: blocks exposed over the network, typically through iSCSI, seen by the host as local disks.
- Object storage: data accessed through an S3 API (for example MinIO), without a file system or classic mount.
The useful distinction: a NAS serves files, a SAN serves blocks (on which you put your own file system), and object storage serves objects over HTTP.
The basic inspection tools
Before any manipulation, you must observe the state of the storage. Each tool shows a different facet; confusing them wastes time. Here is which one to open depending on what you are looking for.
| Tool | What it shows |
|---|---|
lsblk | The tree of block devices (disks, partitions, volumes) |
lsblk -f | The same view, enriched with the FS type, the label and the UUID |
blkid | The file system type and the UUID of a device |
findmnt | The mounted file systems and their mount points |
df | The available space per mounted file system |
parted -l | The partition tables (MBR/GPT) of all disks |
The pivot tool is lsblk: it "lists information about all available or the specified block devices" by reading sysfs (/sys/block) and the udev database, and shows them as a tree (man7.org, lsblk(8)). Its -f option adds the file system type, the label and the UUID, which makes it the first diagnostic reflex.
For mounted volumes, findmnt "will list all mounted filesystems or search for a filesystem" by reading /proc/self/mountinfo and shows the hierarchy of mount points (man7.org, findmnt(8)). It is the tool to prefer over plain mount, more readable and filterable.
Key points
- Linux storage is a stack of layers: block device → partition table → (RAID / LVM / LUKS) → file system → mount point.
- RAID goes first, the file system last; in between, LVM on LUKS (default of the Debian and Ubuntu installers) or LUKS on LVM. Encryption always stays below the FS.
- Naming reveals the bus:
sd*(SATA/SAS/USB),nvme*n*(NVMe, with namespace),vd*(virtio),dm-*(device-mapper). - GPT is the default partition format in 2026 (UEFI); MBR is limited to 2 TiB and 4 primary partitions.
- ext4 is the Debian/Ubuntu default, XFS the RHEL default; Btrfs RAID 5/6 remains unstable, ZFS lives outside the kernel tree (CDDL licence).
lsblk -fandfindmntare the first inspection reflexes; always identify the right disk before acting.
Knowledge check
Check that the essentials of this guide are acquired. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Identify disks on Linux
A new full quiz with random questions
Work again only on the questions you missed