# dysk: a filesystem listing that reads more than df ever told you

> A small Rust utility from Canop that lists mounted filesystems on Linux, macOS and Windows, with sortable columns, filters, JSON output and a library underneath.

**Canop/dysk** — A linux utility to get information on filesystems, like df but better

- Repository: https://github.com/Canop/dysk
- Website: https://dystroy.org/dysk
- Stars: 2,856 · Forks: 60
- Language: Rust
- License: MIT
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/canop-dysk

## Why the author renamed it from lfs

The README keeps one line of history: dysk was previously known as lfs. That is not a cosmetic change. The name collision mattered, because `lfs` is also the name of a Lua filesystem library and an Android library, so anyone searching for a filesystem tool kept landing somewhere else. Renaming to dysk solved a discoverability problem that no amount of documentation could.

The substitution went further than the name. The README is now mostly screenshots, which tells you the author decided the tool is judged on output rather than on prose. There are six images in a row: the default table, two variants showing a custom column choice, the JSON output paired with jq, the filter view, and a sorted view. Every feature the project advertises is shown as rendered text rather than described.

The one-line summary is more specific than the repository description, which calls it a Linux utility to get information on filesystems, like df but better. The README says it: a utility listing your filesystems, on Linux, Mac, and Windows, with Windows marked experimental. The topic tags on the repository are filesystem, hacktoberfest, linux and rust, which is a fair summary of a project that grew out of contributions.

## Installing through Cargo, Conda or your distribution

There is no install command in the README, which tells you where this project actually distributes itself. The badges do the work: a latest-version badge pointing at crates.io, a conda badge pointing at conda-forge, and a repology badge pointing at distribution packaging status. Two links at the top go to the crate page and to an installation page on the project's own site.

For a Rust developer the path is the obvious one.

```bash
cargo install dysk
```

For everyone else the repology badge is the more useful signal, since it answers a question the README leaves open: which Linux distributions package dysk and at what version. That matters more than usual here because the 3.7.0 release notes mention that the archive no longer wraps its content in a `build` directory, which breaks packaging recipes that assumed a nested layout, and that a macOS Intel binary was added to the archive for the first time.

The manifest lists the author as dystroy, the crate under the MIT license, and both a repository and a documentation URL pointing at dystroy.org/dysk. The `Cargo.toml` also excludes `website` and the release zips from the published package, so the crate carries the binary and its code, not the documentation site.

## The columns are the feature

df gives you size, used, available and use percent, and gives you no way to reorder them, hide them, or add anything. dysk's central bet is that the columns should be yours to choose, which the README shows twice in adjacent screenshots with different selections, including one that adds `dev` to the default set and another that adds both `dev` and `inodes`.

The use column is where the recent work is concentrated, and reading the release notes explains why. Version 3.6.1 fixed a case where the use column was not accounting for some non-free space on Linux, and added a `--bar-width` parameter so the bar can be sized rather than fixed. Version 3.7.0 then reduced the size of messages in the use column depending on a heuristic, to cut wasted space, and fixed the used part of the use bar rendering empty when `--ascii` was passed. Those are three consecutive releases of someone caring about how a terminal column looks.

That attention carries over to `/boot`, which version 3.7.0 makes normal again, meaning its mounts are shown by default. A separate line in the same release notes says `dysk <path>` now shows the filesystem holding the path even when it is not normal. So which mounts are interesting is a policy the tool has, and 3.7.0 changed that policy.

## Sorting and filtering before you shell out

The sort screenshot is named for its argument, `dysk_s=free-d`, which reads as sort by free space descending, and the filter screenshot suggests arbitrary filter expressions. So the tool takes sorting and filtering as launch arguments rather than forcing you to post-process a table in awk.

The change in 3.7.0 that this pairs with is that `dysk <path>` resolves the filesystem holding that path. Combined with sorting, that turns dysk into something closer to a question-answering tool than a report generator: point it at the directory you suspect, order the results by free space, and the answer is in the first row.

The JSON output matters more than it first appears. The README pairs it with jq in a screenshot, which is a claim that the JSON is clean enough to pipe. Since dysk is also a library, that same JSON is what you would get from the crate, so a script can move to the API without changing its data handling.

There is a CSV option too, stated in one sentence under the screenshot. It is worth knowing about for the same reason JSON is: a table you export on one machine and analyse on another does not need a screen scraper in between.

## The timeout flag that stops dysk from hanging

Version 3.6.0, tagged v3.6.0b in December 2025, changed how dysk reads statistics on Linux: the read is now time bounded, which the release notes say avoids freezes on unresponsive remote volumes or on some invalid mounts. That is a real bug class. A network filesystem that has gone away can block a stat call indefinitely, and a disk usage tool that hangs is worse than no disk usage tool.

The knob is `--timeout`, and the notes give both ends of its range: `no` to turn bounding off, and a duration such as `5ms` to tune it. The author is direct about the consequence, saying the change should make the older `--remote-stats no` parameter mostly useless. That is a parameter retired by making the better version the default, which is a rare and welcome kind of deprecation.

The heuristic behind the use column sizing probably exists for a related reason. On a machine with dozens of mounts, some of them virtual or tiny, a fixed-width column wastes more space than it conveys, so the width adapts to what is actually in the table.

## A workspace of dysk, dysk-cli and lfs-core

The `Cargo.toml` shows a workspace with two members, `.` and `cli`, and the root crate depends on `dysk-cli` by path. The name matters: the argument parsing is a separate crate. Both the binary and the build script depend on it, and the manifest carries a warning that its version number is duplicated in build dependencies, so it has to be kept in step when bumping.

```toml
[dependencies]
dysk-cli = { version = "3.7.0", path = "cli" }
```

The build dependencies are unusual for a CLI and explain a behaviour you would otherwise find puzzling. `clap` with the derive and cargo features, plus `clap_complete` and `clap_mangen`, means the binary generates its own shell completions and its own man page at compile time, reading arguments from a TOML file via `serde` and `toml`. That is why a release can add a flag like `--bar-width` and have completions and documentation follow automatically.

The actual measurements live somewhere else entirely. The README states that the data displayed by dysk is provided by the lfs-core crate, and that you may use it in your own Rust application. So there are three layers: lfs-core gathers the statistics, dysk-cli defines the interface, and the dysk binary renders it. The manifest also sets the release profile to strip, and holds a patch section where four sibling crates are commented out as local paths, which is a note to the author's own machine rather than something a consumer needs.

## What the README leaves to dystroy.org

Almost everything operational lives off the repository. The README links exactly two documentation pages, an Overview and an Installation guide, both on dystroy.org/dysk, and then says complete documentation lives there. The repository itself holds the screenshots, a `CHANGELOG.md`, a `CONTRIBUTING.md`, a `doc/` directory, a `website/` directory that is excluded from the crate, `bacon.toml` for the author's background-check loop, and `fmt.sh`.

`bacon.toml` is a small tell worth noting. It means the author runs a watcher while working on this, which is the kind of setup a solo maintainer of a Rust CLI tends to accumulate, and `fmt.sh` alongside `rustfmt.toml` suggests formatting is scripted rather than left to each contributor's editor.

The README's tone is worth calling out because it is unusual. It is a page of badges and images with three sentences of description at the top and one line of naming history. There is no feature list, no comparison with ncdu or btop, no philosophy. The argument for dysk over df is made entirely by the pictures, and the pictures are genuinely the argument: more columns, chosen by you, sortable, and exportable.

What the repository does not settle is how the statistics are gathered on each platform, which is exactly the question lfs-core exists to answer. If you need to know what happens on an unusual filesystem, that crate's source is the place to look rather than the binary's help text.

## Conclusion

dysk is a better answer to the question df answers badly, and the honest limit on it is scope: it tells you which mount is filling up, not which file inside it is. Its real strength is that the same measurements are available as JSON and as a crate, so the tool you eyeball and the tool your script parses cannot drift apart. Version 3.7.0 landed on 2026-09-13 and its notes are worth reading before an upgrade, because that release raised the minimum Rust to 1.85, moved the crate to edition 2024, made `/boot` visible by default again and un-wrapped the release archive. Start at dystroy.org/dysk for the flag reference, then decide whether to call lfs-core directly or shell out to the binary.

## FAQ

### How to install a dysk on Ubuntu?

Two routes are shown by the README badges. Cargo works for anyone with a Rust toolchain, since the crate is on crates.io. Ubuntu users can also install the packaged build, and the repository links a repology badge that tracks which distributions carry dysk and at what version.

### How is dysk different from df?

df prints four fixed columns and no more. dysk lets you choose which columns appear, including device and inode counts, sort the table with a launch argument, filter it, and export it as JSON or CSV. It also resolves a path to the filesystem holding it. The measurements come from the same stat calls df uses, packaged by the lfs-core crate.

### What does the dysk --timeout option do?

It bounds how long dysk waits for statistics on Linux. Version 3.6.0 made time bounding the default to avoid freezes on unresponsive remote volumes and invalid mounts, and the flag takes either a duration such as `5ms` or `no` to disable bounding. The release notes say this makes `--remote-stats no` mostly unnecessary.

### Can I use dysk's filesystem data in my own Rust program?

Yes. The measurements come from the lfs-core crate, which the README describes as usable in your own Rust application. The dysk binary is built from that crate plus dysk-cli, the separate crate that holds the argument parsing and generates completions and the man page at build time.

## Sources

- [Canop/dysk on GitHub](https://github.com/Canop/dysk)
- [License: MIT](https://github.com/Canop/dysk/blob/main/LICENSE)
- [Project website](https://dystroy.org/dysk)
- [README](https://github.com/Canop/dysk/blob/main/README.md)
- [Releases](https://github.com/Canop/dysk/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/canop-dysk