Introduction
Linux storage has several connected layers. A device can contain partitions, a partition or image can contain a filesystem, and a filesystem becomes accessible when it is attached to the directory tree at a mount point. Keeping these terms separate makes disk commands much easier to understand.
In this lab, you will inspect storage safely, analyze space usage, create an ext4 filesystem inside a regular file, mount and unmount it, read partition information, and build a practice fstab file. All write operations target disposable files created for the lab; you will not repartition a real disk or modify the system's /etc/fstab.
Understand the Linux Storage Layers
In this step, you will inspect the relationship between block devices, filesystems, and mount points, then prepare a safe workspace.
The lsblk command means "list block devices." Its -o option selects the columns to display:
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
Read the output from left to right:
NAMEidentifies the device or partition.TYPEdistinguishes disks, partitions, and loop devices.SIZEshows capacity.FSTYPEshows the detected filesystem type when one exists.MOUNTPOINTSshows where the filesystem is attached to the directory tree.
A disk can contain one or more partitions. A filesystem such as ext4 organizes files inside a partition or other storage object. A mount point is an ordinary directory through which Linux exposes that filesystem.
Use findmnt to identify the filesystem that currently contains the project directory. The -T option accepts any path and finds its mounted filesystem:
findmnt -T /home/labex/project
The exact source device can vary, but the output shows the source, target, filesystem type, and mount options.
The blkid command reads filesystem signatures, labels, and UUIDs. Administrative access is needed to inspect every available block device:
sudo blkid
A UUID is a filesystem identifier designed to remain stable even when a device name changes. You will use this idea later when studying persistent mounts.
Create and enter a dedicated workspace:
mkdir -p /home/labex/project/storage-lab
cd /home/labex/project/storage-lab
pwd
The final output should be /home/labex/project/storage-lab.
Analyze Filesystem and Directory Usage
In this step, you will compare df, which reports space for complete filesystems, with du, which measures files and directory trees.
Create two sample files with known apparent sizes. The truncate -s option sets a file's size efficiently without filling it with meaningful data:
cd /home/labex/project/storage-lab
mkdir -p usage/reports usage/archive
truncate -s 2M usage/reports/weekly.log
truncate -s 5M usage/archive/records.bin
Use df -h on the workspace. The -h option displays human-readable units such as MiB and GiB:
df -h /home/labex/project/storage-lab
df answers, "How much space is used and available on the filesystem containing this path?" Its important columns are Size, Used, Avail, Use%, and Mounted on.
Use du -sh to summarize the sample directory. Here -s means summary and -h selects readable units:
du -sh usage
Unlike df, du answers, "How much space belongs to this file or directory tree?" Sparse files created by truncate can have a large apparent size while consuming little allocated disk space. The --apparent-size option measures their logical sizes:
du -h --apparent-size --max-depth=1 usage
You should see that usage/archive is larger than usage/reports. Combine du with sorting to list the largest apparent items first:
du -ah --apparent-size usage | sort -rh | head -n 5
The pipe sends du output to sort; -r reverses the order and -h understands readable size suffixes. head -n 5 keeps the first five results.
Create and Inspect an Ext4 Filesystem
In this step, you will create a virtual disk image, format it with ext4, and inspect its filesystem metadata without touching a real disk.
Create a 128 MiB image file. This file will act as disposable storage for the rest of the lab:
cd /home/labex/project/storage-lab
truncate -s 128M virtual.img
Check its apparent size:
ls -lh virtual.img
Before formatting, file sees only generic data or an empty file:
file virtual.img
The mkfs.ext4 command creates an ext4 filesystem. The -F option confirms that a regular file is an intentional target, and -L assigns the label LABEXDATA:
sudo mkfs.ext4 -F -L LABEXDATA virtual.img
Formatting creates filesystem structures inside the image. Inspect the result with two tools:
file virtual.img
sudo blkid -p virtual.img
The output should identify ext4, show the label LABEXDATA, and include a generated UUID. Display only that UUID:
sudo blkid -s UUID -o value virtual.img
The UUID value is generated at formatting time and will differ between learners.
Mount, Use, and Unmount the Filesystem
In this step, you will attach the virtual filesystem to the Linux directory tree, write one file, and detach it safely.
A mount point is the directory where a filesystem becomes visible. Create one under /mnt, a standard location for temporary administrative mounts:
sudo mkdir -p /mnt/labex-virtual
Mount the image. The -o loop option asks Linux to associate the regular file with a loop device so that it can be treated like block storage:
cd /home/labex/project/storage-lab
sudo mount -o loop virtual.img /mnt/labex-virtual
Inspect the active mount:
findmnt /mnt/labex-virtual
The source usually appears as a loop device, the target is /mnt/labex-virtual, and the filesystem type is ext4. You can also ask df about this specific filesystem:
df -h /mnt/labex-virtual
Write a file inside the mounted filesystem. sudo sh -c is used because redirection is performed by the shell and the mounted root directory belongs to root:
sudo sh -c 'echo "stored inside the virtual filesystem" > /mnt/labex-virtual/welcome.txt'
cat /mnt/labex-virtual/welcome.txt
Unmounting flushes pending writes and detaches the filesystem from its mount point:
sudo umount /mnt/labex-virtual
Confirm that it is no longer mounted:
findmnt /mnt/labex-virtual
No output is expected, and findmnt returns a nonzero status because it found no active mount at that target. The mount point directory still exists, but the image's contents are no longer accessible through it until the image is mounted again.
Inspect Partition Tables Safely
In this step, you will use fdisk in read-only listing mode and distinguish a partition table from a filesystem signature.
List the system's visible disks and partitions:
sudo fdisk -l
The -l option means list. It reports disk sizes, sector sizes, partition-table types, and partitions without changing them. Never start an interactive partitioning session on an unfamiliar production disk.
Now inspect the virtual image:
cd /home/labex/project/storage-lab
sudo fdisk -l virtual.img
The image has a disk size but no partition entries. In this controlled example, ext4 was created directly in the whole image. On a physical disk, a common layout is:
disk device -> partition table -> partition -> filesystem -> mount point
Create a second empty image for comparison:
truncate -s 64M partition-demo.img
sudo fdisk -l partition-demo.img
It also has no partition table. Compare filesystem signatures with wipefs in its default read-only mode:
sudo wipefs virtual.img partition-demo.img
virtual.img should show an ext4 signature, while the empty comparison image should show no filesystem signature. Do not use the destructive wipefs -a option in this lab.
Build and Validate a Practice Fstab
In this step, you will learn the six fields of an fstab entry and safely test a separate practice file without modifying /etc/fstab.
The system reads /etc/fstab to decide which filesystems should be mounted consistently. View its non-comment lines without editing the file:
grep -Ev '^\s*(#|$)' /etc/fstab
An fstab entry has six whitespace-separated fields:
source mount-point filesystem-type options dump fsck-order
For physical partitions, UUID=<value> is usually safer than a name such as /dev/sdb1, because device names can change when hardware discovery order changes.
Capture the UUID of your image and place a commented UUID example in a practice file:
cd /home/labex/project/storage-lab
uuid=$(sudo blkid -s UUID -o value virtual.img)
printf '## Real block device example: UUID=%s /mnt/data ext4 defaults,nofail 0 2\n' "$uuid" > practice-fstab
Because this lab uses a regular file rather than a physical partition, its active practice entry uses the absolute image path and the loop option:
printf '%s\n' '/home/labex/project/storage-lab/virtual.img /mnt/labex-virtual ext4 loop,nofail 0 2' >> practice-fstab
Display and validate the practice file. --tab-file tells findmnt not to use the real /etc/fstab:
cat practice-fstab
findmnt --verify --tab-file practice-fstab
The final summary should report 0 parse errors and 0 errors. It also reports one warning that the source is a regular file. That warning is expected here because this controlled lab intentionally uses a file-backed loop filesystem rather than a physical block device.
Use the practice file for one controlled mount. The -T option tells mount to read the named alternative fstab file:
sudo mount -T practice-fstab /mnt/labex-virtual
findmnt /mnt/labex-virtual
The previously created welcome.txt should still exist, proving that mounting exposes the filesystem's stored data:
cat /mnt/labex-virtual/welcome.txt
Unmount it again so the lab finishes in a safe detached state:
sudo umount /mnt/labex-virtual
You validated persistent-mount syntax without changing the system boot configuration. A mistake in the real /etc/fstab can disrupt startup, so administrators commonly validate changes before rebooting.
Summary
You connected the main Linux storage layers: devices, partitions, filesystems, and mount points. You used lsblk, blkid, and findmnt to inspect them, then compared filesystem-wide usage from df with file and directory usage from du.
You created and labeled an ext4 filesystem inside a disposable image, mounted it through a loop device, preserved data across an unmount, and inspected partition information without altering real disks. Finally, you learned the six fstab fields, why stable UUIDs matter, and how to validate a separate practice fstab before using it.
