SadServers
  • Scenarios
  • Labs
    All Labs Linux & Bash Web Servers Databases Data Processing Docker Kubernetes CI/CD Infrastructure as Code Tooling / Applications
  • Dashboard
  • Solutions
    For Individuals For Businesses
  • Ranking
  • Newsletter
  • Documentation
    FAQ Support Pro Accounts Pro+ Accounts Business Accounts Gift API CLI/TUI Privacy Troubleshooting Interviews
  • Blog
  • Pricing
  • Gift
    Gift Purchase Gift Redeem
  • About
Log In - Sign Up
  1. Labs
  2. Disk volumes
  3. Guide

Guide

Concepts and learning path

Troubleshooting

Failure modes and fixes

Cheatsheet

Commands to keep handy

Disk volumes guide

How Linux sees storage

Physical or virtual disks appear as block devices under /dev/ (for example /dev/sda, /dev/nvme0n1, /dev/vda). A disk can hold one or more partitions (/dev/sda1) or be used whole. Each partition (or whole disk) must be formatted with a filesystem (ext4, xfs, btrfs, …) and then mounted on a directory such as /mnt or /var so it can be used. That directory becomes the mount point after the filesystem is mounted.

Partitions: mbr and gpt

MBR (Master Boot Record) and GPT (GUID Partition Table) are two different ways of storing partition information on a disk.

MBR was created in the DOS era and the main limitation is that only four primary partitions can be created, or three primary partitions and one extended partition, where the extendedpartition can hold many logical partitions.

So, while MBR can handle only four primary partitions, GPT handles by default 128 primary partitions, and more can be handled by increasing the partition table size, thus, there is no need of extended or logical partitions in GPT.

The second limitation is that MBR cannot create a single partition larger than 2TB, whereas GPT has a limit of 9.4 Zettabytes, which is virtually unlimited.

Filesystems: ext4 and xfs

A filesystem is the on-disk structure that tracks files, directories, permissions, and free space. You create one with mkfs.ext4 or mkfs.xfs on a partition or logical volume before mounting it.

ext4 is the default on most Debian/Ubuntu systems. It is mature, well understood, and supports online grow with resize2fs after the underlying partition or LV is extended. It handles the general-purpose workloads you see on web servers, app hosts, and small databases.

xfs is the default on RHEL/CentOS/Rocky and common for large volumes and heavy I/O. It performs well on big files and parallel writes. Grow with xfs_growfs /mount/point (the mount point, not the device path). xfs cannot be shrunk — plan capacity accordingly.

Check the active type with df -T or lsblk -f. The type in /etc/fstab must match what blkid reports, or the mount will fail at boot.

What is an inode?

An inode is the filesystem's metadata record for a file or directory: ownership, permissions, timestamps, size, and pointers to the data blocks. The filename lives in the directory; the inode is the actual object the kernel works with. Every filesystem is created with a fixed inode count — you can run out of inodes even when plenty of disk space remains (common with millions of tiny cache or session files).

Use stat to inspect inode metadata for any path:

$ stat /etc/passwd File: /etc/passwd Size: 2841 Blocks: 8 IO Block: 4096 regular file Device: 253,1 Inode: 131334 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)

The Inode: number is unique within that filesystem. Check inode usage across mounts with df -i — when IUse% hits 100%, new files cannot be created until inodes are freed.

LVM in brief

Logical Volume Manager (LVM) adds a flexible layer: physical volumes (PV) are grouped into volume groups (VG), and logical volumes (LV) are carved out for filesystems. You can grow an LV and its filesystem without repartitioning — common on cloud VMs when you resize the underlying disk.

Typical flow: pvcreate → vgcreate → lvcreate → mkfs → mount. To extend: pvresize / add PV → lvextend → grow the filesystem (resize2fs for ext4, xfs_growfs for xfs).

Persistent mounts (/etc/fstab)

Mounts configured only with the mount command are lost on reboot. /etc/fstab lists what to mount at boot. Each line has six fields: device (or UUID), mount point, filesystem type, options, dump flag, fsck order. Use UUID= or LABEL= instead of /dev/sdX so device names can change safely.

Key concepts to know

  • Capacity vs inodes — a filesystem can be full on space or on inode count
  • Bind mounts — mount an existing directory tree at another path
  • Swap — can live on a partition or file; low memory pushes pages to swap
  • Cloud block storage — attach volume, rescan bus, partition/LVM grow, then filesystem grow
  • Read-only remount — often a symptom of I/O errors or a full root filesystem

Learning resources

  • Filesystem Hierarchy Standard — refspecs.linuxfoundation.org/FHS_3.0 (where things live on a Linux system)
  • LVM HOWTO (TLDP) — tldp.org/HOWTO/LVM-HOWTO (PV/VG/LV concepts and workflows)
  • fdisk(8) — href="https://man7.org/linux/man-pages/man8/fdisk.8.html (standard tool for disk partitioning)
  • parted(8) — href="https://man7.org/linux/man-pages/man8/parted.8.html (disk partitioning tool that handle wide range of partition table formats)
  • fstab(5) — man7.org/linux/man-pages/man5/fstab.5 (persistent mount file format)
  • lsblk(8) — man7.org/linux/man-pages/man8/lsblk.8 (block device tree)
  • Arch Wiki — LVM — wiki.archlinux.org/title/LVM (practical resize and troubleshooting examples)

Practice scenarios

Hands-on Disk volumes scenarios on live Linux VMs: disk volumes

Troubleshooting →
SadServersSadServers

Real-world Linux and DevOps scenarios for hands-on learning and technical assessment.

Uptime Robot ratio (30 days)
Product
  • Scenarios
  • For Individuals
  • For Businesses
  • Pricing
Resources
  • FAQ
  • Blog
  • Newsletter
Company
  • About Us
  • Support
  • Privacy Policy
  • Terms of Service
  • Contact
Connect With Us
info@sadservers.com

Made in Canada 🇨🇦
Updated: 2026-06-13 16:06 UTC – 2d2950a