Linux Administration
Disk Partitioning and Mounting
In this lesson
Disk partitioning and mounting is the process of dividing a physical storage device into logical sections, formatting those sections with a filesystem, and attaching them to the Linux directory tree so the operating system and its users can read and write data. Every disk added to a Linux system — whether a cloud volume, a physical drive, or a USB device — must go through this workflow before it can be used.
Disks, Partitions, and Device Names
Linux exposes every storage device as a file under /dev/. The naming convention tells you the device type, its order, and which partition you are referring to. Understanding device names is the first step before any partitioning or mounting operation.
Fig 1 — Linux device naming conventions for SATA/SCSI and NVMe disks
# List all block devices — disks and their partitions in a tree view
lsblk
# List with filesystem type, UUID, and mount point — the most useful view
lsblk -f
# Show detailed disk and partition information
sudo fdisk -l
# List block device UUIDs (needed for fstab entries)
sudo blkid
# Show disk usage by mounted filesystem
df -hWhat just happened? lsblk -f revealed the full picture in one command — every disk, every partition, its filesystem type, its UUID, and where it is currently mounted. The UUID is the stable identifier used in /etc/fstab rather than the device name, because device names like sdb can change between reboots when disks are added or removed.
Partitioning with fdisk
fdisk is the standard interactive tool for creating and managing partitions on MBR (Master Boot Record) and GPT (GUID Partition Table) disks. It makes no changes to the disk until you explicitly write them — giving you a safe environment to plan your partition layout before committing.
Step 1 — Identify the target disk
Confirm the correct device name and that it is the disk you intend to modify. One wrong character here can destroy the wrong disk.
lsblk
sudo fdisk -l /dev/sdb
Step 2 — Open fdisk on the disk
Open the interactive fdisk prompt for the disk. Nothing is written yet. Type m inside fdisk to see all available commands.
sudo fdisk /dev/sdb
Step 3 — Create a new partition table and partition
Use g for GPT (recommended for disks >2TB or UEFI systems) or o for MBR. Then n to add a new partition.
g # create GPT partition table
n # new partition
# accept defaults for partition number and first sector
+50G # set size to 50 GB (or press Enter to use all remaining space)
Step 4 — Write the partition table to disk
w writes all pending changes and exits. This is the point of no return — the partition table is now written to the disk.
w # write and exit (p to print layout first to verify)
# Full non-interactive fdisk session — create one partition using all space on /dev/sdb
# (p=print, g=new GPT table, n=new partition, Enter×3=all defaults, w=write)
sudo fdisk /dev/sdb <<'EOF'
g
n
w
EOF
# Inform the kernel of the updated partition table without rebooting
sudo partprobe /dev/sdb
# Verify the new partition appeared
lsblk /dev/sdbWhat just happened? fdisk held all changes in memory until w was entered — meaning you could have typed q at any point to quit without touching the disk. After writing, partprobe told the running kernel to re-read the partition table without a reboot, and lsblk confirmed that sdb1 now exists and is ready to be formatted.
Formatting Partitions with mkfs
A partition is just raw space until it is formatted with a filesystem — the structure that organises data into files and directories. mkfs (make filesystem) creates that structure. The choice of filesystem type depends on how the partition will be used.
The Linux workhorse. Stable, well-tested, journaled. Default for most Linux partitions including / and /home. Supports files up to 16TB.
High-performance, excellent for large files and high-throughput workloads. Default on RHEL/Rocky. Cannot be shrunk — only grown.
Modern copy-on-write filesystem with built-in snapshots, checksums, and RAID support. Growing adoption on desktop and container workloads.
Cross-platform filesystems for USB drives, EFI boot partitions (vfat), and external drives shared with Windows/macOS.
Not a filesystem — a dedicated swap partition used as virtual memory overflow. Created with mkswap and activated with swapon.
# Format a partition as ext4 with a label (label is optional but useful)
sudo mkfs.ext4 -L "datastore" /dev/sdb1
# Format as xfs
sudo mkfs.xfs -L "appdata" /dev/sdb1
# Format as btrfs
sudo mkfs.btrfs -L "snapshots" /dev/sdb1
# Create and enable a swap partition
sudo mkswap /dev/sdb2
sudo swapon /dev/sdb2
# Verify swap is active
swapon --show
free -hWhat just happened? mkfs.ext4 created the filesystem structure — inode tables, journal, and superblock — and assigned a UUID. The UUID printed here is what goes into /etc/fstab for a persistent mount. The label datastore is a human-readable name you can also use in fstab as LABEL=datastore.
Mounting and Unmounting Filesystems
Mounting is the act of attaching a formatted partition to a directory in the Linux filesystem tree — called a mount point. Once mounted, the partition's contents appear at that directory path. Linux's unified filesystem tree means that /data might physically live on a completely different disk from /home — the directory structure hides this seamlessly from users and applications.
Analogy: Think of a disk partition as a USB drive and mounting as plugging it in. The moment you plug in a USB drive, its contents appear at a folder path on your desktop. Unmounting is safely ejecting it — flushing all buffered writes before disconnecting, so data is not lost or corrupted.
# Create a mount point directory (if it does not exist)
sudo mkdir -p /mnt/data
# Mount a partition at the mount point
sudo mount /dev/sdb1 /mnt/data
# Mount with specific options (read-only, noexec — useful for untrusted media)
sudo mount -o ro,noexec /dev/sdb1 /mnt/data
# Verify the mount
mount | grep sdb1
df -h /mnt/data
# Unmount a filesystem — must not be in use
sudo umount /mnt/data
# Unmount by device name (either works)
sudo umount /dev/sdb1
# Find what is using a mount point (if umount gives "device is busy")
lsof /mnt/data
fuser -m /mnt/dataWhat just happened? lsof caught the reason umount failed — alice's bash shell had its current working directory inside the mounted path. The fix is to cd out of the directory in that shell, then unmount. fuser -km /mnt/data would forcibly kill all processes using the mount, but that is a last resort.
Persistent Mounts with /etc/fstab
A mount created with mount is temporary — it disappears after a reboot. To make a mount survive reboots, add an entry to /etc/fstab (filesystem table). This file is read by the kernel at boot and by mount -a to mount all listed entries. A mistake in fstab can prevent the system from booting — always validate your entry before rebooting.
Fig 2 — The six fields of an /etc/fstab entry
# Get the UUID of the new partition — always use UUID, not /dev/sdb1
sudo blkid /dev/sdb1
# Back up fstab before editing — a broken fstab can prevent booting
sudo cp /etc/fstab /etc/fstab.bak
# Add the new entry (replace UUID with output from blkid)
echo 'UUID=c3d4e5f6-1234-5678-9abc-def012345678 /mnt/data ext4 defaults,noatime 0 2' \
| sudo tee -a /etc/fstab
# CRITICAL: test the new fstab entry before rebooting
# mount -a mounts all entries in fstab that are not already mounted
sudo mount -a
# Verify it mounted correctly
df -h /mnt/data
mount | grep /mnt/dataWhat just happened? mount -a is the most important validation step — it tests the fstab entry in the running system exactly as the kernel would at boot. Silent success means the entry is valid. Any error here tells you there is a problem to fix before you reboot. The noatime option skips updating the access time on every file read, which reduces disk writes and improves performance for most workloads.
Common Mount Options and Practical Patterns
The options field in fstab and the -o flag in mount control exactly how a filesystem behaves when accessed. Choosing the right options can improve performance, enforce security, and prevent accidents.
# Harden /tmp — no execution, no suid, no device files
# (add to /etc/fstab)
tmpfs /tmp tmpfs defaults,noatime,noexec,nosuid,nodev,size=2G 0 0
# Data partition — performance + security
UUID=c3d4... /mnt/data ext4 defaults,noatime,noexec,nosuid 0 2
# Optional/removable disk — boot even if absent
UUID=d4e5... /mnt/backup ext4 defaults,nofail 0 2
# Remount an already-mounted filesystem with new options (without unmounting)
sudo mount -o remount,ro /mnt/data
# Show all currently mounted filesystems with their options
findmntWhat just happened? findmnt displayed the full mount tree — showing exactly which device backs each directory path and which options are active. The /tmp line confirms the hardening options are in effect: noexec,nosuid,nodev. This is the clearest and most readable way to verify the live mount state of the whole system.
Always Test fstab with mount -a Before Rebooting
A typo in /etc/fstab — a wrong UUID, a missing mount point directory, or an unsupported option — will cause the system to drop into an emergency shell on the next reboot, requiring physical or out-of-band console access to recover. Always run sudo mount -a immediately after editing fstab and confirm the expected mount appears before rebooting. Keep the backup at /etc/fstab.bak until you have verified a clean reboot.
Lesson Checklist
lsblk -f output and identify device names, filesystem types, UUIDs, and mount points for all disks on a system
fdisk, and inform the kernel with partprobe
mkfs.ext4 or mkfs.xfs, mount it temporarily, and use lsof to diagnose a busy unmount
mount -a before rebooting
noatime, noexec, nosuid, and nofail mount options and can verify active options with findmnt
Teacher's Note
The most common real-world fstab disaster is using /dev/sdb1 instead of a UUID in fstab. When a second disk is added to the server, the device enumeration order can shift and sdb1 now points to the wrong partition — causing either a failed mount or, worse, mounting the wrong data at the wrong path. UUIDs are permanent and device-order-independent. Always use them.
Practice Questions
1. A new 200GB disk has been attached to a server as /dev/sdc. Write every command required to: create a single GPT partition using all available space, format it as ext4 with the label appdata, mount it at /srv/appdata, and make the mount persist across reboots.
2. You run sudo umount /mnt/backup and receive the error umount: /mnt/backup: target is busy. Describe how you would identify which process is holding the mount open and how you would safely resolve it.
3. Explain why the nofail option is important for secondary disks in an fstab entry, and describe a real scenario where omitting it would cause a serious problem.
Lesson Quiz
1. Why should you use a UUID rather than a device name like /dev/sdb1 in /etc/fstab?
2. What does the sixth field (fsck pass) value of 2 mean in an fstab entry?
3. After adding a new entry to /etc/fstab, what command should you run immediately to test it without rebooting?
Up Next
Lesson 19 — File System Types
A deeper look at ext4, xfs, btrfs, and tmpfs — how they differ, when to choose each, and how to manage them