Linux Disk Commands: Space, inodes, and Disk Health

The server boots up, services run, but when you try to save a file, the response is No space left on device. You check with df -h and see that 40 percent of space is free. This is where you need to know that the problem isn't disk space, it's inode. Linux disk commands exist precisely for these moments: fast diagnosis, without guesswork.

df and du: How to tell the difference

Two commands, two different questions. df asks the filesystem "how much room do you have?" and du asks directories "how much have you used?".

df -hT
df -i
du -sh /var/log/*
du -xhd1 / 2>/dev/null | sort -h

The -T switch shows the filesystem type (ext4, xfs, overlay). -i brings up the number of used inodes and is the very command you should run first when df -h shows space but writing isn't possible. The -x switch in du prevents it from crossing filesystem boundaries; without it, on a server with multiple mounts, the output becomes meaningless and may take minutes.

A point that surprises many: if you've deleted a file but a process still has it open, du won't see it but the space hasn't been freed. Here you need to go for lsof +L1 and restart the process.

inodes are exhausted but space is free

I see this error a lot in practice, especially on servers where sessions or cache work heavily with tiny files. The symptoms are exactly these:

• df -h shows free space.
• df -i gives 100 on IUse%.
• Every write to disk fails, even touch /tmp/test.

The quick fix is to find the directory with the highest number of files:

for d in /var/*; do echo -n "$d: "; find "$d" -xdev | wc -l; done

Usually the culprit is /var/lib/php/sessions or /var/spool/postfix. If the number of files in a directory exceeds several hundred thousand, even ls becomes slow and you should clean up with find ... -delete, not rm -rf *.

Partition, mount, and fstab

When you add a new disk, the order of work matters. First, check with lsblk -f whether the disk is detected or not. If the output is empty, the problem is in the virtualization layer, not Linux. Then partitioning and formatting:

parted /dev/sdb mklabel gpt
parted /dev/sdb mkpart primary ext4 0% 100%
mkfs.ext4 -L data /dev/sdb1
mkdir -p /mnt/data
mount /dev/sdb1 /mnt/data

In /etc/fstab, never write the name /dev/sdb1. On a server where disks get moved around, this causes the server to enter emergency mode on the next boot. Use UUID:

UUID=8f3c1a2e-... /mnt/data ext4 defaults,noatime 0 2

Take the noatime option seriously. On a high-traffic server, eliminating access time updates can save dozens of IOPS per second. Before rebooting, always run mount -a and findmnt --verify. If it errors, don't reboot.

Checking disk health with smartctl

Disks give warning before they die. You just need to listen:

smartctl -a /dev/sda
smartctl -H /dev/nvme0

Look at three fields: Reallocated_Sector_Ct, Pending_Sector, and Media_Wearout_Indirect on SSD. If Pending_Sector goes above zero, replace the disk; this number doesn't come back down. For NVMe, the command nvme smart-log /dev/nvme0 gives the percentage of lifespan used directly.

Also run a short test: smartctl -t short /dev/sda and after two minutes smartctl -l selftest /dev/sda. If the test passes 90 percent of the time but fails once, that one time is enough.

This is where they go wrong

The most common mistake I see is this: someone runs df -h, sees that / is full, and then runs rm -rf /var/log/*. The result? Logs get deleted, space is freed, and two weeks later the same thing happens because nobody configured logrotate. Worse: some services like MySQL depend on the log directory and deleting them causes a startup error.

The sign is this: after cleanup, the service won't come up and in journalctl -xe you see a permission denied error on a log file. The right way is to configure logrotate with a specific maxsize and rotate, not manual cleanup.

Which tool to choose

If the server is on cloud infrastructure and the disk is connected over the network, du numbers may not match df; this is normal and due to reserved blocks and the storage layer. In this case, trust df, not du.

For servers under heavy load where disk I/O has become a bottleneck, before making any decision about hardware upgrades, read diagnosing the cause of high server load; many times the problem isn't the disk, it's a runaway query or process. And if you intend to move data, transferring files with scp and rsync shows the right way while preserving permissions and resume.

And if one day you completely lose access to the operating system, server reinstall and working with rescue mode explains the data rescue path step by step. For production servers where you can't take risks, a dedicated server with NVMe disks and full control over partitioning is the more logical choice; and if you have a variable workload, cloud server allows expanding the disk without downtime. For initial setup, Linux hosting is a simple starting point.

Frequently asked questions

Why does df show free space but I can't create a file?

It's almost always an inode problem. Check with df -i; if IUse% is at 100, the filesystem doesn't have the capacity to create a new file even with free space available. The solution is to find the directory with many tiny files and clean them up.

The second case is that the file was deleted but a process still has it open. Find the process with lsof +L1 and restart it so the space is freed.

What's the difference between du and df and which is more accurate?

df reports from the filesystem's perspective and du from the perspective of files and directories. Neither is "more accurate," because they measure two different things. For deciding whether the disk is full, df is the reference.

The numerical difference between the two usually comes from reserved blocks, open deleted files, and nested filesystems.

How do I know a disk is failing?

With smartctl -a /dev/sda and looking at the Reallocated_Sector_Ct and Pending_Sector fields. Any non-zero value in these two is a serious sign. On NVMe, the nvme smart-log command shows the percentage of lifespan used.

The short test smartctl -t short is also useful, but the absence of errors in the test doesn't mean the disk is definitively healthy.

Is noatime recommended on all servers?

For most web and database servers, yes. Eliminating access time updates reduces the write load on the disk and increases the useful life on SSD. The only exception is servers where a tool like tmpwatch or a backup script works based on atime.

In that case, instead of noatime, use relatime, which is the balance between the two.