Linux Disk Usage and Filesystem Troubleshooting with df, du, lsblk, mount, and fstab: Practical Implementation Guide

Intro

Linux disk usage and filesystem troubleshooting with df, du, lsblk, mount, and fstab is essential because production containers are easy to start but much harder to operate consistently. A useful technical guide shows what to configure, which command proves the configuration works, and what failure looks like when the setup is wrong.

This article targets developers, DevOps consultants, and technical startup teams. It connects the core tools — df, du, lsblk, mount, fstab — with common symptoms such as "no space left on device" so you can move from concept to local verification.

The goal is practical: understand the moving parts, test them locally, and avoid surprises when the same pattern is reused in CI/CD or a production‑like environment. Typical first steps include running df -h to see overall capacity, df -i to check inode exhaustion, and du -sh /var/log to pinpoint large directories.

Workflow Overview

Start by identifying the resource you are investigating, the configuration change that affects it, and the command that proves the setup is working. Keep the workflow tight: configure one thing, verify the observed state, then document what breaks when the setup is missing, misconfigured, or used under production‑like load.

In practice, the Workflow Overview is where teams often discover hidden assumptions. Local paths, image tags, network names, environment files, resource limits, and permissions can behave differently across laptops, CI runners, and production hosts. Make those assumptions explicit before relying on the setup.

Key concepts covered:

Linux disk usage fundamentals
df, du, lsblk, mount, and fstab syntax
Linux filesystem troubleshooting workflow
Interpreting "no space left on device" errors

Related areas such as the Linux filesystem hierarchy, Linux permissions, and Linux storage troubleshooting matter because a storage choice can affect deployment, debugging, backup, and rollback decisions.

Practical check for the workflow: define the expected input, the command or configuration change, the expected output, and the failure signal before you change the environment.

A useful local test should be repeatable by another developer from a clean checkout, with the commands and assumptions written down near the configuration files.

Example verification steps

df -h /
df -i /
du -sh /var/log
lsblk -f
findmnt /data

Each command runs independently and prints a clear result you can compare against the expected values.

Local Pilot Plan

Apply the same identify‑configure‑verify loop to a concrete scenario: a dedicated data volume mounted at /data on a server or VM.

Identify the block device that will hold the data.

   lsblk -f

Note the UUID of the target partition (for example, UUID=1234-5678).

Create a filesystem if one does not exist.

   mkfs.ext4 /dev/sdb1

Add a persistent mount entry to /etc/fstab using the UUID.

   echo "UUID=1234-5678  /data  ext4  defaults,noatime  0  2" >> /etc/fstab

Create the mount point and mount the volume.

   mkdir -p /data
   mount -a

Verify the mount and available space.

   findmnt /data
   df -h /data
   df -i /data

Simulate a growth scenario and watch the usage.

   dd if=/dev/zero of=/data/testfile bs=1M count=512
   du -sh /data
   df -h /data
   df -i /data

Clean up the test file.

   rm /data/testfile

If any step fails — for example, mount -a reports "wrong fs type" or df -h /data shows 0 % used — you have a concrete failure signal to investigate before the same configuration reaches production.

Conclusion

Linux disk usage and filesystem troubleshooting with df, du, lsblk, mount, and fstab works best when the team treats the configuration as something to test, not just something to copy. The safest path is to keep examples small, run the commands locally, and confirm the expected behavior before adding more services or automation.

For a next step, choose one service and document the exact commands used to build, run, inspect, stop, and recreate it. Then compare the result with related areas such as the Linux filesystem hierarchy, Linux permissions, and Linux storage troubleshooting so the implementation fits the larger operating model.

A reliable workflow makes failure visible: logs are easy to find, persistent data survives container rebuilds, and local behavior is close enough to production to catch mistakes early. Adding automated alerts on df -h thresholds and df -i inode thresholds completes the safety net for production environments.