How to Find Large Files in Linux: find -size, the Top-10 du Pipeline, and the ncdu Drill-Down

CodexFuse Team · 2026-11-04T10:36:08.814Z · 13 min read min read

Find large files in Linux: the find -size threshold search, the du | sort | head top-10 pipeline, and the ncdu drill-down — with tested commands and real output.

A full disk on a server never announces itself politely — a deploy fails, a database refuses writes, or an update dies mid-install. The fix starts with knowing exactly which files are eating your space, so learning how to find large files in Linux is one of the highest-value skills a server admin can have. Three tools cover every situation: find -size hunts files above a threshold, the du | sort | head top-10 pipeline shows the biggest space hogs anywhere, and ncdu lets you drill through the whole filesystem interactively. Every command in this guide was run and verified on a live Linux box today, so the outputs you see are real — including two traps that catch even experienced admins. If you have not confirmed the disk is actually full yet, start with our guide to checking disk space on Ubuntu first.

This is the find-the-files satellite of the CodexFuse VPS-LINUX-OPS series. Everything here applies to any distro, but the examples are written for the place this matters most: a headless VPS hosting instance where the only interface is a terminal.

How to find large files in Linux, fast?

The fastest route is a three-step ladder: search by size with find, rank by size with du, then drill down with ncdu. Each step answers a sharper question — which files cross a threshold, which entries are biggest overall, and where exactly the gigabytes hide. Here is the complete workflow:

  1. Find files over a threshold. Run find / -xdev -type f -size +100M to list every regular file larger than 100 MiB on the root filesystem.
  2. Rank the biggest entries. Run du -ahx / 2>/dev/null | sort -rh | head -n 10 for the classic du sort head top 10 of the largest files and folders.
  3. Drill down interactively. Install ncdu (sudo apt install ncdu) and run ncdu -x / — on modern versions add -t8 for parallel scanning — then navigate with the arrow keys and check candidates with i.
  4. Understand before deleting. Confirm a file is really disposable (a 150M file can be sparse and occupy zero disk), then remove it deliberately — never with a blind -exec rm.
  5. Verify the space came back. Re-run the du pipeline and confirm the usage dropped with df -h.

How do I find files bigger than 1GB with find -size?

Use find / -xdev -type f -size +1G: -size matches by size, + means strictly greater than, and G means gibibytes (GiB, 1073741824 bytes). If you arrived here searching "linux find files bigger than 1gb", this is the canonical command every credible result points to — with the -xdev guard that keeps the scan on one filesystem. It is also the command to reach for at any other exact threshold, like +100M for 100 megabytes or +500K for 500 kilobytes.

The find(1) man page defines the syntax as -size n[cwbkMG] — "File uses less than, more than or exactly n units of space, rounding up." The suffix letters are verbatim from the manual: b means 512-byte blocks (the default when no suffix is given), c bytes, w two-byte words, k kibibytes (1024), M mebibytes (1048576), G gibibytes (1073741824).

SuffixUnitExampleMatches
cbytes-size +100cfiles larger than exactly 100 bytes
kkibibytes (KiB)-size +500kfiles larger than 500 KiB
Mmebibytes (MiB)-size +100Mfiles larger than 100 MiB
Ggibibytes (GiB)-size +1Gfiles larger than 1 GiB
(none)512-byte blocks-size +100files larger than 100 blocks (51,200 bytes)

A real run against a test directory shows the basic threshold search working. We created a corpus of files of assorted sizes, including one 2.5MB file, and asked for everything over 1 MiB:

$ find . -type f -size +1M
./bigblob.bin

And the headline command from the quick answer, scoped to the root filesystem so mounted volumes are not scanned:

$ find / -xdev -type f -size +100M -exec ls -lh {} +
-rw-rw---- 1 root nogroup 150M Nov  4 10:32 ./demo150.img

Two flags deserve a permanent place in your muscle memory. -xdev means "Don't descend into directories on other devices" — the man page's exact wording — so a scan of / will not wander into NFS mounts or separate partitions. And -exec ls -lh {} + batches the matched files through one command line (xargs-style, "the total number of invocations of the command will be much less than the number of matched files"), which is far faster than the older \; one-file-at-a-time form.

Why does find -size sometimes miss the file you expect?

Because -size rounds up to the next unit and +/- are strict — "an exact size of n units does not match." A 2,500,000-byte file (2.5 MiB) does not match -size 2M because it rounds up to 3M; it matches -size +2M. We verified this live:

$ find . -name exact25.bin -size 2M     → (no match: 2.5M rounds UP to 3M, ≠ 2M)
$ find . -name exact25.bin -size +2M
./exact25.bin

The man page carries an explicit warning about this rounding: "IMPORTANT: bear in mind that the size is rounded up to the next unit. Therefore -size -1M is not equivalent to -size -1048576c. The former only matches empty files, the latter matches files from 0 to 1,048,575 bytes." Our test confirmed it — -size -1M matched only an empty file.

A second trap is the missing suffix. With no suffix, find counts 512-byte blocks, not bytes — so -size +100 matches files larger than 51,200 bytes, not 100 bytes. A 51,200-byte file is exactly 100 blocks, and because + is strict, it does not match:

$ find . -name exact51200.bin -size +100   → (no match — strictly greater than)
$ find . -name exact51200.bin -size +99
./exact51200.bin
$ find . -name exact51200.bin -size 100
./exact51200.bin

The rule of thumb: always write the suffix (+100M, +1G), and remember that find -size +100M matches files of 100 MiB and one byte or more — not 100.0 MiB exactly.

How do I list the 10 biggest files and folders anywhere?

Run du -ahx . | sort -rh | head -n 10. This is the classic du sort head top-10 pipeline: du -a writes counts "for all files, not just directories", -h prints "sizes in human readable format (e.g., 1K 234M 2G)", -x skips "directories on different file systems", and sort -h compares "human readable numbers (e.g., 2K 1G)" in reverse so the biggest comes first. A real run against our test corpus:

$ du -ahx . | sort -rh | head -n 10
7.8M    .
2.4M    ./exact25.bin
2.4M    ./bigblob.bin
912K    ./file_a.bin
860K    ./file_d.bin
752K    ./file_c.bin
240K    ./file_e.bin
240K    ./file_b.bin
0       ./empty.txt
0       ./demo150.img

Notice the last line: ./demo150.img — a file that ls -lh reports as 150M — sorts at 0 in this pipeline. That is not a bug. It is the most misunderstood distinction in disk hunting, and it deserves its own section.

For a directory-level overview instead of per-file detail, swap -a for -s ("display only a total for each argument"): du -hsx * | sort -rh | head -10 ranks the top-10 items in the current directory as summaries — handy when you want to know which folder to descend into next.

Why does du show 0 for a 150MB file?

Because find and du measure two different things: find -size uses the file's st_size — its apparent size, "consistent with the result you get for ls -l" — while du estimates file space usage in disk blocks. A sparse file (one with holes, common for VM images and preallocated logs) can be huge in apparent size while occupying zero blocks.

$ ls -lh demo150.img
-rw-rw---- 1 root nogroup 150M Nov  4 10:32 demo150.img
$ du -h demo150.img
0       demo150.img
$ du -h --apparent-size demo150.img
150M    demo150.img
$ stat -c '%s bytes apparent, %b x 512-byte blocks' demo150.img
157286400 bytes apparent, 0 x 512-byte blocks

This is why the same file was matched by find -size +100M yet invisible to the du top-10 pipeline. Practically, it means deleting a sparse file may free far less than you expect — but a non-sparse file that du reports at full size always frees what it says. When the two tools disagree, stat settles it: apparent bytes versus blocks used.

ncdu vs du: when should I use each?

Use du for one-shot ranked answers and ncdu for exploration: "Ncdu is a disk usage analyzer with a text-mode user interface. It is designed to find space hogs on a remote server where you don't have an entire graphical setup available." The trade-off is simple — the du pipeline gives you the top-10 in one command with zero installs, while ncdu lets you walk the tree, sort on the fly, and inspect candidates without re-running scans.

du pipelinencdu scan
Installpreinstalled everywheresudo apt install ncdu / sudo dnf install ncdu
Best atone-shot top-N answerinteractive drill-down, re-sorting, inspecting
Re-sort without re-scanno — re-run the pipelineyes — n by name, s by size
Inspect a filemanual ls/stati shows info on the selected item
Delete from the interfacenod — with confirmation enabled by default
Viewflat ranked listbrowsable tree; g toggles percentage / graph / both
Scriptingexcellent (pipes, cron)none — it is interactive by design

If your server is low on disk and you need the answer once, run the du pipeline. If you need to understand where the space went — descending into /var/lib/docker, then into a container layer, then into a log directory — an ncdu scan is dramatically faster than typing the pipeline five times.

How do I scan a whole filesystem safely with ncdu?

Run ncdu -x /: the -x flag means "Do not cross filesystem boundaries, i.e. only count files and directories on the same filesystem as the directory being scanned" — the same safety rule as find -xdev and du -x, and the one the official manual's own examples recommend for full-filesystem scans. To run an ncdu scan on modern hardware at speed, add -t8: "Ncdu 2.5 adds support for parallel scanning, but it's not enabled by default. To give it a try, run with -t8 to scan with 8 threads." The -t, --threads flag takes the thread count and defaults to 1.

Once inside, the essentials are: arrow keys or j/k to move, enter to descend into a directory, h to go back up, s to sort by size, i for details on the selected item, a to toggle between disk usage and apparent size (remember the sparse-file trap), and q to quit. Deleting from inside ncdu is guarded: confirmation is enabled by default, and you can exclude noisy trees from the scan entirely with --exclude (repeatable — excluded files are still displayed but not counted toward totals).

The deletion warning, once and for all: never combine find with a blind -exec rm or a bare -delete on a production box. The find man page is blunt — "putting -delete first will make find try to delete everything below the starting points you specified" — and it turns -depth on automatically while refusing to remove non-empty directories. Always test the exact match list with -print (or -exec ls -lh {} +) first, delete deliberately, and keep ncdu's built-in confirmation on.

What should I do after finding the big files?

Verify the space actually returns, then stop the growth: re-run the top-10 pipeline, confirm with df -h, and fix the cause — rotated-but-uncompressed logs in /var/log, old package caches, abandoned Docker images and volumes, or a backup script writing locally instead of off-box. If the files are sparse and deleting them freed nothing, you were chasing the wrong hog — run the du pipeline again rather than the find threshold.

When the freed space is smaller than expected, re-check the whole picture with our disk-space walkthrough — df, du, and the inode trap covered end to end. And if the pressure is memory rather than disk, the next satellite in this series shows checking RAM usage on Linux with the same tested-output approach.

Sources

Frequently Asked Questions

How do I find largest files in Linux quickly?

For the fastest one-shot answer, run du -ahx / 2>/dev/null | sort -rh | head -n 10 — the du sort head top-10 pipeline ranks the largest files and folders on the root filesystem. For an interactive session where you descend into directories, an ncdu -x / scan is the better tool.

What does find -size +100M match exactly?

It matches regular files whose size, rounded up to the next mebibyte, is strictly greater than 100 MiB — i.e. files of 100 MiB + 1 byte and up. A file of exactly 100 MiB does not match; use -size +99M for "100 MiB or larger." Note that find measures apparent size (st_size), not disk blocks.

Why is ncdu better than du for finding space hogs?

ncdu is an interactive curses-based version of du: you browse the directory tree, re-sort by size or name on the fly, inspect items with i, and delete with confirmation — all without re-running scans. The trade-off is that ncdu needs an install and a terminal session, while the du pipeline works anywhere, including scripts and cron.

What does ncdu -t8 do?

Ncdu 2.5 added parallel scanning, which is not enabled by default. Running an ncdu scan with -t8 walks the filesystem with 8 threads instead of one — the official site's own recommendation: "run with -t8 to scan with 8 threads." The flag is -t / --threads and defaults to 1; note there is no -T threads flag in ncdu 2.x (-T belongs to sort). We make no speed claims beyond the official feature description — on multi-core machines with fast disks the walk finishes sooner.

Is it safe to delete files ncdu marks as huge?

Only after you confirm what they are. A huge file may be a live database, an active log a service is writing to, or a sparse file that frees far less than its apparent size. Check with i in ncdu (or stat), make sure no process holds it open (lsof), and keep a backup of anything you are unsure about. Never automate deletions with a blind find -delete.

Featured on Twelve Tools Hunt for Tools Featured on LaunchBuff Launch Llama Tools Launch your MCP Top Web Development Companies in the US - OnToplist.com Designer Listings Listed on SeeWhatNewAI