10 Linux Filesystem Tricks Most Users Learn Too Late

Raja ishaq Nabi Khan

8 min read

·

Oct 28, 2026

--

1

Listen

Share

Understand what is really happening behind your files, directories, disk space, and symbolic links.

Most Linux users learn how to create files, copy directories, and delete unwanted data. But the filesystem has several behaviors that are not immediately obvious.

Why does a disk appear full when du cannot account for the used space? Why can a file still consume disk space after being deleted? What is the difference between a symbolic link and a hard link? And why can two paths point to the same underlying file?

Understanding these details makes you better at troubleshooting, managing storage, and avoiding mistakes that can cost you hours of work.

Here are 10 Linux filesystem techniques worth learning.

1. Understand That a Filename Is Not the File Itself

Linux filesystems commonly use inodes to store metadata about files, including ownership, permissions, timestamps, and references to the file’s data blocks.

A filename is an entry in a directory that points to an inode. This distinction explains several otherwise confusing behaviors.

Inspect a file’s inode with:

ls -i report.txt

For more detailed metadata, use:

stat report.txt

You can inspect the inode number, file size, permissions, ownership, and timestamps.

Why does this matter?

• Multiple filenames can refer to the same inode through hard links.
• Renaming a file within the same filesystem generally changes its directory entry, not the underlying file data.
• Deleting a filename does not necessarily remove the underlying data immediately.

Professional habit: When investigating file identity, metadata, or unexpected storage behavior, use stat instead of relying only on the filename.

2. Know When to Use Hard Links and Symbolic Links

Both hard links and symbolic links provide alternative ways to access files, but they work differently.

A hard link is another directory entry referring to the same inode. A symbolic link, or symlink, stores a path to another file or directory.

Create a hard link:

ln original.txt hardlink.txt

Create a symbolic link:

ln -s original.txt symlink.txt

Inspect them with:

ls -li original.txt hardlink.txt symlink.txt

The original file and hard link normally share the same inode number. The symbolic link has its own inode.

The practical differences are important:

• Hard links generally cannot cross filesystem boundaries and usually cannot be created for directories by ordinary users.
• Symbolic links can point across filesystems and can reference directories.
• A symbolic link can become broken if its target is moved or deleted.
• Removing one hard-linked filename does not remove the file’s data while another hard link remains.

When to use them: Use symlinks for convenient paths, alternate directory layouts, and references to files on other filesystems. Use hard links when you deliberately want multiple names for the same underlying file.

3. Find Out Where Your Disk Space Actually Went

One of the most common Linux troubleshooting problems is a filesystem that is nearly full even though the visible files do not appear large enough to explain the usage.

Start with:

df -h

This reports filesystem-level capacity and usage in human-readable units.

Next, inspect directory usage:

du -sh /path/to/directory

To identify the largest immediate subdirectories:

du -h --max-depth=1 /path/to/directory | sort -h

These commands answer different questions:

• df reports space usage from the filesystem's perspective.
• du estimates space used by files and directories it can traverse.

If their results differ significantly, possible explanations include deleted files that are still open by running processes, inaccessible directories, filesystem metadata, reserved blocks, or differences between allocated and apparent file sizes.

To inspect large directories without crossing into other mounted filesystems:

sudo du -xhd1 /var 2>/dev/null | sort -h

The -x option keeps du on the same filesystem, which can make the results easier to interpret.

Professional habit: Use df to identify the affected filesystem, then use du to investigate its directories. Do not assume that the largest visible file is necessarily the cause.

4. Remember That Deleting a File Does Not Always Free Its Space

This is one of the most useful filesystem behaviors to understand.

On Linux, a process can keep a file open even after its directory entry has been removed. The file’s storage remains allocated until the final open reference is closed.

This often happens with application logs.

Imagine a log file grows to several gigabytes. You delete it to free space, but df -h still shows almost the same usage.

Check for deleted files that are still open:

sudo lsof +L1

Look for entries showing deleted files with open file descriptors.

If a process is holding a deleted log file open, the usual solution is to use the application’s supported log-reopen mechanism or restart the relevant service when safe and appropriate.

Avoid blindly killing processes or writing to file descriptors you do not understand.

Why this matters: On production systems, this can explain why deleting a large log file does not recover the expected disk space.

5. Use findmnt to Understand Mounted Filesystems

Linux presents storage devices through a unified directory tree. A separate filesystem can be mounted at a directory such as /mnt/data, /home, or /var.

This means two directories that appear close together in the directory tree may reside on different filesystems.

To see what is mounted and where:

findmnt

To inspect the filesystem backing a particular path:

findmnt -T /home

You can also use:

df -hT /home

The -T option displays filesystem types alongside capacity information.

Why is this useful?

• A directory may be on a separate disk or partition.
• Moving files between filesystems is generally a copy-and-remove operation rather than a simple metadata rename.
• A filesystem mounted over an existing directory hides the directory’s previous visible contents until it is unmounted.

That last point is particularly important when troubleshooting missing files under mount points.

Professional habit: Before moving large amounts of data or investigating storage issues, determine which filesystem actually backs the path.

6. Inspect Symbolic Links Instead of Guessing Their Targets

A symbolic link may look like an ordinary file or directory in a listing, but it points somewhere else.

Display a link’s target with:

ls -l mylink

Resolve the final path with:

readlink -f mylink

For example:

ln -s /var/log/application.log app.log
readlink -f app.log

The resolved path helps establish where the link ultimately leads, provided the target can be resolved.

You can also inspect the link itself rather than the target:

stat -c '%N' mylink

This is useful when dealing with application configuration, shared directories, software installations, or paths that contain several layers of symbolic links.

One important detail: a relative symbolic link is resolved relative to the directory containing the link, not relative to the shell’s current working directory.

Professional habit: When a path behaves unexpectedly, check whether it is a symbolic link before changing or deleting anything.

7. Use mktemp Instead of Inventing Temporary Filenames

Temporary files are useful for intermediate results, downloads, scripts, and test output. But manually choosing a name such as temp.txt can cause collisions when multiple commands or users operate at the same time.

Use mktemp to create a unique temporary file:

tmpfile=$(mktemp)

For a temporary directory:

tmpdir=$(mktemp -d)

Use the resulting path in your script:

printf 'Temporary data\n' > "$tmpfile"
cat "$tmpfile"

When finished, remove the file or directory you created:

rm -f -- "$tmpfile"

For a temporary directory, ensure it contains only data that you intend to remove before running a recursive deletion.

For scripts that need cleanup even after interruption, a trap can help:

tmpfile=$(mktemp) || exit 1
trap 'rm -f -- "$tmpfile"' EXIT

This schedules cleanup when the shell exits normally or through many common error and interruption paths. It does not guarantee cleanup after every possible failure, such as a forced termination.

Professional habit: Use mktemp for temporary paths, and quote variables whenever they represent filenames.

Press enter or click to view image in full size

8. Distinguish Apparent File Size From Disk Space Used

A file’s reported size is not necessarily equal to the amount of storage allocated to it.

Compare these commands:

ls -lh largefile.img
du -h largefile.img

ls -lh reports the file's apparent size. du -h reports the space allocated to the file, rounded for display.

Sparse files illustrate the difference. A sparse file can contain large regions of logical zeroes that do not require corresponding physical data blocks.

Create a test file:

truncate -s 1G sparse.img

Now inspect it:

ls -lh sparse.img
du -h sparse.img

The file appears to be 1 GB in logical size, but its allocated space may be much smaller.

Sparse files are useful for virtual disk images, database files, and applications that benefit from representing empty regions efficiently. However, not every tool, filesystem, or storage destination preserves sparseness in the same way.

Professional habit: When investigating storage, check both apparent size and allocated space. They answer different questions.

9. Use install to Create Directories and Deploy Files Cleanly

Many users create directories, copy files, and then change permissions in separate commands. The install utility can combine some of these steps.

Create a directory with specified permissions:

install -d -m 755 /tmp/myapp

Copy a file while setting its destination permissions:

install -m 644 config.conf /tmp/myapp/config.conf

Install an executable with executable permissions:

install -m 755 myscript.sh /tmp/myapp/myscript.sh

Unlike a plain cp, install is designed for deployment-style copying and can set destination permissions. It does not preserve all source metadata by default, so choose the appropriate method when ownership, timestamps, ACLs, extended attributes, or other metadata must be retained.

Also, the modes above are examples, not universal recommendations. Choose permissions appropriate for the content and the users who need access.

When to use it: install is especially handy in shell scripts, deployment procedures, and Makefiles where files need to be placed at known destinations with predictable permissions.

10. Use Atomic File Replacement to Avoid Partially Written Configuration Files

Suppose a script updates a configuration file by writing directly to it:

generate_config > config.conf

If the generating command fails after writing only part of the output, the original configuration may already have been truncated or replaced with incomplete content.

A safer pattern is to write to a temporary file first, verify that generation succeeded, and then rename it into place.

tmpfile=$(mktemp ./config.conf.XXXXXX) || exit 1

if generate_config > "$tmpfile"; then
    mv -f -- "$tmpfile" config.conf
else
    rm -f -- "$tmpfile"
    exit 1
fi

Because the temporary file is created in the same directory, the final rename is normally atomic on a local filesystem that supports standard rename semantics. Readers will see either the old file or the new file, rather than a partially written intermediate version.

There are important caveats:

• The generating command must report failures correctly.
• The destination directory must be writable.
• Atomic visibility does not by itself guarantee that data has been durably written to physical storage after a sudden power loss.
• Replacing a file this way can change ownership, permissions, and other metadata unless you deliberately preserve or set them.

Professional habit: For configuration files and other critical outputs, generate first, validate second, and replace the destination only after success.

Final Thoughts

Linux filesystem expertise is not just about memorizing ls, cp, mv, and rm. It is about understanding how names, inodes, storage allocation, mounts, and file descriptors interact.

The most valuable habits from this list are:

• Use stat when you need to understand file metadata.
• Know the difference between hard links and symbolic links.
• Use df and du together to investigate storage.
• Check for deleted files that remain open.
• Inspect mount points before moving or troubleshooting data.
• Use mktemp for safe temporary paths.
• Understand apparent size versus allocated disk space.
• Replace critical files carefully rather than overwriting them prematurely.

These details may seem small, but they make a real difference when debugging storage problems, writing reliable scripts, or maintaining Linux systems.

The goal is not to know more commands. It is to understand what the filesystem is actually doing.