A fast, lightweight disk-usage visualizer for Linux. It maps a filesystem as a squarified treemap — nested rectangles sized proportionally to what they consume — so the biggest space hogs are obvious at a glance. Think SpaceSniffer, but native, GPU-accelerated, and built for a single Linux machine.
A free and open-source project by Fopull LLC — project page at fopull.com/storage-sifter.
Right-click any file or folder for a "Safe to delete?" verdict — here, game audio is flagged "Probably keep — personal media."
- Squarified treemap, GPU-rendered. Every file and folder is a rectangle sized by real on-disk usage and colored by what it is, so the space hogs pop out instantly. Click to drill in with an animated zoom; a breadcrumb tracks where you are.
- "Safe to delete?" reports. Right-click anything for an instant verdict — Safe to delete → Don't delete — that names what a path actually is (cache, build output, personal media, a code project, credentials, installed software…) and explains why. A built-in knowledge catalog recognizes dozens of common tool directories and, when there's a cleaner way to reclaim the space than a plain delete, shows the exact recommended command to run — with one-click copy.
- Package-manager-aware cleanup. For system-managed caches it detects your distro's package manager (pacman, apt, dnf, zypper, apk, xbps, portage, or nix) and gives the matching clean command, so the advice is right wherever you run it.
- In-app audio playback. Click an audio file and the cell maximizes into a player with play/pause and a scrubbable timeline, so you can listen before deciding to delete. (Video opens in your default player for now.)
- Make it yours. Customizable color palettes with presets and per-color
pickers, shareable
SSP1-…palette codes, adjustable UI/text size, animation speed, folder-preview depth, and a tweakable hover drill-target highlight — all persisted and applied live. - Informative scanning screen. Live progress while it scans: items and size found, elapsed time, and scan rate — and, for a whole-disk scan, a percentage bar with the expected total and an estimated time remaining.
- Byte-exact with
du. Sizes use real on-disk block counts, de-duplicate hard links, and stay on one filesystem, so the numbers answer "how much will I actually reclaim?" - Safety first. Move-to-trash by default (reversible), tiered confirmation for permanent or out-of-home deletes, and protected system roots refused outright.
Latest release: v0.3.0. See the changelog for what landed in each version.
StorageSifter is a single, self-contained binary for x86-64 Linux. It needs a Vulkan-capable GPU driver (standard on modern desktops) and a Wayland or X11 session.
Download StorageSifter-*-x86_64.AppImage from the
latest release, then:
chmod +x StorageSifter-*-x86_64.AppImage
./StorageSifter-*-x86_64.AppImageComing soon. The AUR packages are prepared (see
packaging/aur/) and will be published shortly. For now, use the AppImage above. Once they're live, install with:
yay -S storagesifter-bin # prebuilt binary, fast
# …or build from source:
yay -S storagesifterGrab storagesifter-*-x86_64-linux.tar.gz from the
latest release,
then put the binary on your PATH:
tar xzf storagesifter-*-x86_64-linux.tar.gz
install -Dm755 storagesifter-*/storagesifter ~/.local/bin/storagesifter(The bundled INSTALL.txt covers optional menu-entry and icon integration.)
cargo install --git https://github.com/Fopull-LLC/StorageSifter --locked storagesifterYou can verify any download against the release's SHA256SUMS.txt:
sha256sum -c SHA256SUMS.txt.
- x86-64 Linux (no ARM builds yet).
- A Vulkan-capable GPU and driver. StorageSifter renders on wgpu/Vulkan with no software-rendering fallback, so a machine without working Vulkan (some VMs, very old GPUs) may not launch.
- A Wayland or X11 session.
- ALSA (
libasound, present on every Linux desktop) for in-app audio playback — nothing extra to install. - For the AppImage, FUSE 2 (
libfuse2) — or run it with./StorageSifter-*.AppImage --appimage-extract-and-run. - The prebuilt binaries target glibc 2.35+ (built on Ubuntu 22.04); current distributions are fine.
A Cargo workspace with the engine and layout kept strictly UI-free, so each part is testable and reusable on its own:
| Crate | Role |
|---|---|
crates/scanner |
Parallel, single-filesystem disk scanner. Arena tree, hard-link de-dup, safety classification. No UI dependencies. |
crates/treemap |
Squarified treemap layout (Phase 2). Pure geometry: rectangles in, rectangles out. |
crates/app |
The desktop UI — eframe/egui on the wgpu (Vulkan) backend. Glue only. |
The scanner produces an arena of nodes (Vec<Node>, addressed by u32 ids).
Every node stores its parent as well as its children, so deleting an item can
walk up the ancestor chain and subtract reclaimed bytes in O(depth) without
rebuilding the tree.
StorageSifter reports real on-disk consumption, computed as st_blocks * 512
— the number of 512-byte blocks the filesystem has actually allocated to a file.
This is deliberate: it is the number that answers "how much will I actually
reclaim if I delete this?" It accounts for sparse files and filesystem slack,
and it matches du rather than a file manager's "size" column.
A few consequences worth knowing so the numbers never surprise you:
- It can differ from apparent size (
st_size). A file manager usually shows apparent size — the logical length of the file. On-disk size can be smaller (sparse files, holes) or larger (block rounding). - Btrfs transparent compression. On CachyOS the root filesystem is typically
Btrfs, often with transparent compression (e.g.
zstd). There,st_blocksreflects the compressed on-disk size — the real bytes occupied. So a 1 GiB log that compresses to 200 MiB shows as ~200 MiB here, while a file manager may still report ~1 GiB. That ~200 MiB is the correct "reclaimable" figure, and it is exactly whatdureports too. - Hard links are counted once. A file with multiple hard links inside the
scan is counted a single time, matching
du. Such entries are flagged so a future delete can warn that removing one link may not free the data until every link is gone. - Single filesystem. A scan stays on the device the target path lives on; it
does not cross into other mounts (
/proc,/sys, external drives, etc.). This matchesdu -x.
Requires a Rust toolchain (install via rustup).
cargo build --release # build everything
cargo test -p scanner # run the scanner's correctness testscargo run -p storagesifter # pick a filesystem from the device list
cargo run -p storagesifter -- [PATH] # …or scan PATH directlyA dark, GPU-rendered window opens and a background scan fills in a squarified
treemap: cells sized by on-disk usage and colored by what they are — caches
and build artifacts (target/, node_modules/, .cache/, __pycache__, …)
and everything inside them glow amber so reclaimable space stands out at a
glance, with media green, applications cyan, code blue, documents yellow, and
archives pink. One level of nested preview is drawn inside each folder.
- Click a folder to drill into it — the view zooms in, growing out of the cell you clicked.
- Click an audio file to play it in-app — the cell maximizes into a player with play/pause and a scrubbable timeline, so you can listen before deleting. (Video files open in your default player for now.) Esc returns to the map.
- The breadcrumb (top bar) shows where you are; click any segment to jump back up. Backspace or Esc goes up one level.
- Hover a cell to read its full path, size, and category in the status bar.
- Rescan re-reads the directory; Devices (top-left) returns to the
picker. The picker lists each filesystem with its used/free space; picking one
scans the whole filesystem and crosses btrfs subvolumes (
/home,/var, …) — which are outlined in cyan so the boundaries are obvious. (Scanning a path directly still stays on its single filesystem, matchingdu -x.) - Ctrl/Shift-click cells to build a multi-selection; a bar shows the count and total reclaimable size, with Move to Trash / Delete / Clear.
- Right-click any cell for Safe to delete?, Properties, Reveal in file manager, or to delete. The trash is the default (reversible); every delete is confirmed, and permanent deletes — or anything outside your home directory — are flagged in the dialog. Protected system roots are refused outright.
- Safe to delete? opens an instant report that tells you what a file or
folder actually is — a cache, build output, version-control history, personal
media, installed software, a code project, credentials — and gives a plain
verdict (Safe to delete → Don't delete) with the reasons behind it. A
built-in knowledge catalog recognizes dozens of common tool directories
(npm/yarn/pnpm/pip/cargo/go/gradle caches, Docker & Podman storage, browser
profiles, the systemd journal, the pacman cache, Flatpak data, language
version managers, …) and, when a tool offers a cleaner way to reclaim the
space than a plain delete, shows the recommended command to run (e.g.
npm cache clean --force,docker system prune -a,paccache -r,journalctl --vacuum-time=2weeks) with a one-click Copy. For system-managed caches it detects your distro's package manager (pacman, apt, dnf, zypper, apk, xbps, portage, or nix) and gives the matching clean command, so the advice is right wherever you run it. The analysis reads only the already-scanned, in-memory tree (no re-scan, no disk reads, no network) and is computed once, so it never slows the app down. - Keyboard:
Deletetrashes the selection,Shift+Deletedeletes it permanently,Ctrl+Aselects everything in view,Escclears the selection,Backspacegoes up,F5rescans. All bindings are configurable in ⚙ Settings, which also controls the color palette (presets, per-color pickers, and shareableSSP1-…codes), UI/text size, animation speed, folder-preview depth, and the hover drill-target highlight. Settings persist to~/.config/storagesifter/settings.jsonand apply live.
The first build pulls in the GUI stack and takes a few minutes; after that,
rebuilds of the app are seconds. A --release build is available for maximum
scan speed but isn't needed for everyday use.
A throwaway CLI exercises the scanner and prints sizes in raw bytes so they
can be checked against du to the byte:
cargo run --release -p scanner --bin scan -- /path/to/dirIt prints the on-disk total, a summary line (node count, unreadable paths, hard-link count), and the top 20 consumers.
The scanner's total should match du exactly. Because the scan stays on one
filesystem, pin du to one filesystem too with -x:
du -xsB1 /path/to/dir # one number — should equal our "on-disk total"If they ever disagree, du -xB1 /path/to/dir gives a per-directory breakdown to
locate the discrepancy.
Built for one machine (CachyOS / Linux). It uses Linux-specific APIs directly and does not carry cross-platform abstractions.
Hit a problem or have an idea? Please open an issue. It helps to include your distro, GPU and driver, and session type (Wayland or X11) — plus any terminal output if it failed to launch.
StorageSifter is a free and open-source product of Fopull LLC — a software studio by Ty Johnston. Project page: fopull.com/storage-sifter. More projects at fopull.com.
MIT © 2026 Fopull LLC