Skip to main content
Settings
Color Mode
Theme Skin
Background

Appearance preferences are saved in this browser only.

Environment
Current Environment Production

Built with JEKYLL_ENV=production. Changes require deployment.

Theme & Build
Jekyll v3.10.0
Last Build Jul 14, 10:34
Page Location
Page Info
Layout article
Collection tools
Path _tools/ncdu-vs-gdu-honest-review.md
URL /tools/ncdu-vs-gdu-honest-review/
Date 2026-07-14

ncdu vs gdu: the honest review

Verdict: install both. Reach for ncdu when you’re SSH’d into a box you don’t own and want a disk map that costs 2.4 MB of RAM to build; reach for gdu when the tree is huge and you’d rather spend 668 MB of memory to get the same answer in two-thirds the time. But understand what you’re holding: these aren’t viewers like duf and dust. They’re viewers with a delete key — and one of them pre-selects “yes.”

ncdu and gdu are both free and open source (MIT). We have no relationship with either project and nothing to sell. We’ve already reviewed the read-only half of this shelf: duf draws your mounted filesystems, dust draws a usage tree and stops. Both are safe to run half-asleep because the worst they can do is print. These two are different in exactly one dangerous way, and that difference is the review.

The one feature that separates them from dust

dust’s own review ends by pointing here: the interactive option, it says, is ncdu, which “gives you an arrow-key file browser to drill into hogs and delete them in place.” That’s the whole pitch. You scan a directory, you arrow down to the 13 MiB node_modules that shouldn’t be on a production box, you press d, and it’s gone — no second terminal, no rm -rf you have to retype and pray over.

Here’s ncdu looking at a throwaway tree we built for the occasion (a logs/, a cache/, a node_modules/ stuffed with 40 tiny files):

ncdu 1.19 ~ Use the arrow keys to navigate, press ? for help
--- /tmp/disktest --------------------------------------------------------------
   13.0 MiB [###############] /node_modules
    4.8 MiB [#####          ] /logs
    1.9 MiB [##             ] /cache
  788.0 KiB [               ] /src
  300.0 KiB [               ] /tmp
*Total disk usage:  20.8 MiB   Apparent size:  20.7 MiB   Items: 50

gdu shows you the same census. Unlike ncdu, it also has a non-interactive mode (-n), which is genuinely useful for scripts and for a review, because we can paste the exact bytes instead of a screenshot:

$ gdu -n --no-progress /tmp/disktest
   13.0 MiB /node_modules
    4.8 MiB /logs
    1.9 MiB /cache
  788.0 KiB /src
  300.0 KiB /tmp

Both agree, and both round the same way dust does — the du figure for that tree is 21M, because du -h rounds each line up. That last-digit disagreement is its own review; it isn’t the story here. The story is the d key.

The delete is real — we deleted things to prove it

We don’t publish “you can delete files” on faith. We drove each tool in a real terminal and pressed the button, and both removed the file from disk. But the two confirm dialogs are not the same, and the difference is the single most important thing in this review.

ncdu asks, and the cursor sits on no. Press d on a file and you get:

                    ┌───Confirm delete──────────────────────────────┐
                    │ Are you sure you want to delete "blob.bin"?    │
                    │                                                │
                    │        yes      no     don't ask me again      │
                    └────────────────────────────────────────────────┘

The no is pre-highlighted. Hit Enter on reflex and nothing happens — we tried, the 1.9 MiB file was still there. To actually delete it we had to arrow left onto yes and then confirm. That’s a deliberate speed bump, and it’s the correct default for a tool whose entire purpose is to be run on servers.

gdu asks, and the cursor sits on yes. Same directory, same d:

                ╔══════════════════════════════════════════╗
                ║     Are you sure you want to delete       ║
                ║                "scratch"?                 ║
                ║    yes     no     don't ask me again      ║
                ╚══════════════════════════════════════════╝

Press Enter and it’s gone. We confirmed with a bare Enter and the pane redrew to Total disk usage: 0 B ... Items: 0. The file was deleted from disk. gdu is one muscle-memory keystroke closer to an empty directory than ncdu is. That is not a bug and it’s not a dealbreaker — but if you’re the kind of tired that presses d-Enter to dismiss a dialog, gdu will happily oblige, and there is no undo. The trash isn’t involved; the inode is freed.

Neither tool asks twice. Neither moves the file anywhere recoverable. “Delete in place” means unlink, immediately.

The scan cost: gdu buys speed with your RAM

The demo tree above is 21 MB and both tools finish instantly. The interesting numbers show up on something real. We pointed both at /usr39 GB across 670,052 files — and measured with /usr/bin/time -v, cache warm, twice each:

$ /usr/bin/time -v gdu -n --no-progress /usr
    Elapsed (wall clock) time (h:mm:ss or m:ss): 0:01.76
    Maximum resident set size (kbytes): 668172

$ /usr/bin/time -v ncdu -o /dev/null /usr
    Elapsed (wall clock) time (h:mm:ss or m:ss): 0:02.52
    Maximum resident set size (kbytes): 2460

Read those twice. gdu scanned 39 GB in 1.76 seconds — it’s written in Go and walks the tree in parallel, and it’s genuinely quicker. It paid for that speed with 668 MB of resident memory. ncdu took 2.52 seconds, about 43% longer, and did it in 2.4 MB — roughly 275× less RAM. That’s not a rounding wobble; it’s a design decision. gdu holds a fat parallel model of the tree in memory; ncdu is a C program that stays featherweight on purpose.

Which one is “better” depends entirely on where you’re standing:

  • On your workstation with 32 GB of RAM, gdu’s 668 MB is free money and the second you save is real. Take the speed.
  • On a 512 MB VPS whose disk is full — the exact box you ncdu onto at 2 a.m. — gdu allocating 668 MB to investigate why there’s no room is a way to make the outage worse. ncdu’s 2.4 MB is the whole reason it’s on every server rescue checklist.

The tool that’s faster on your laptop is the tool that can OOM the machine you most need to inspect. Pick per-situation, not per-favorite.

Installing them, and gdu’s small identity crisis

Both apt install cleanly on Ubuntu 24.04, which already puts them ahead of dust (which ships under no apt name at all):

$ apt-cache policy ncdu
ncdu:
  Installed: 1.19-0.1
$ apt-cache policy gdu
gdu:
  Installed: 5.25.0-1ubuntu0.24.04.3

ncdu’s version is a clean 1.19. gdu’s is 5.25.0-1ubuntu0.24.04.3 — the same distro-mangled tail that made duf clam up about its real version. And gdu carries a naming footnote worth knowing before you script around it: on this Ubuntu box the binary is a plain /usr/bin/gdu, but the project ships under alternate command names (gdu-go, gdu_go) on distros where gdu would collide with another package. Check what landed on your PATH before you bake the command into a playbook — same lesson bat/batcat and fd/fdfind teach, one aisle over. On the box we tested, gdu --version and ncdu --version both answered to their plain names.

Where duf and dust still win

The whole reason to keep the read-only tools around is that a destructive TUI is the wrong instrument for a glance:

  • A one-line answer. When the question is “what’s eating this directory,” dust -d 1 dir prints a sorted, colored tree and exits. No arrow keys, no full-screen takeover, no delete key one fat-finger away. For “is the disk okay across all my mounts,” duf does the same for filesystems. You don’t launch a modal file browser to read one number.
  • Scripts. dust and du emit text you can pipe. ncdu is a viewer only — its -o export is a JSON dump, not a report — and gdu -n is close but still a TUI tool wearing a script hat. For a stable integer, stay with du -sb.
  • Safety by construction. You can hand duf or dust to a nervous junior and the worst outcome is a wrong number. Hand them gdu and one of the buttons that’s already selected is yes.

ncdu and gdu are for the next step — find it and act — not the glance.

What it costs and the free alternative

Both cost nothing: open source, no account, no telemetry, in the Ubuntu archive. The free alternative to both is the pair you already have — dust (or du -h --max-depth=1 | sort -h) to find the hog, then a plain rm to remove it. What ncdu/gdu buy you is collapsing those two steps into one screen so you never retype a path into an rm -rf. That’s a real ergonomic win and, on a bad night, also a real way to rm -rf the wrong thing without the friction of typing it. The tool removes the keystrokes and the pause those keystrokes gave you.

What made us close the tab

Nothing made us uninstall either — they earn their place on the “disk is full, and I need to fix it from inside a terminal” checklist. The honest caveats, in the order they’ll bite:

  • They delete, and there’s no undo. unlink, not trash. Both are viewers with a live wire in them.
  • gdu’s confirm dialog defaults to yes. One reflexive Enter deletes the highlighted entry. ncdu defaults to no and makes you arrow over — the safer choice for the servers these tools live on.
  • gdu is faster but RAM-hungry. 668 MB to scan a 39 GB tree, versus ncdu’s 2.4 MB. On a memory-starved box — the exact place a full disk hurts most — that speed can cost you the machine.
  • gdu’s command name isn’t guaranteed to be gdu. It’s gdu on Ubuntu 24.04, but ships as gdu-go/gdu_go where it would collide. Verify before scripting.

When it goes wrong: if you pressed d in ncdu and the file is still there, that’s not a bug — you hit Enter on the pre-selected no. Arrow left to yes and confirm. And if you’re about to run gdu as root on a nearly-full production box, stop and run ncdu instead: the file you’re hunting is the same, but the tool that finds it shouldn’t be the one that also needs 668 MB you don’t have — and shouldn’t be the one where the delete button is already lit.