asomers / ztop

Display ZFS datasets' I/O in real time

ztop

Display ZFS datasets' I/O in real time

Overview

ztop is like top, but for ZFS datasets. It displays the real-time activity for datasets. The built-in zpool iostat can display real-time I/O statistics for pools, but until now there was no similar tool for datasets.

Platform support

ztop works on FreeBSD 12 and later, and Linux.

Screenshot

Minimum Supported Rust Version (MSRV)

ztop does not guarantee any specific MSRV. Rather, it guarantees compatibility with the oldest rustc shipped in the package collection of each supported operating system.

• https://www.freshports.org/lang/rust/

License

ztop is primarily distributed under the terms of the BSD 2-clause license.

See LICENSE for details.

Sponsorship

ztop is sponsored by Axcient, inc.

ztop's Issues

Linux support

I wish I was smart enough to actually fix and submit a patch, but the best I can do is show you errors.

   Compiling ztop v0.1.1 (/home/fryfrog/git/ztop)
error[E0433]: failed to resolve: use of undeclared type `SnapshotIter`
  --> src/app.rs:68:9
   |
68 |         SnapshotIter::new(pool)
   |         ^^^^^^^^^^^^ use of undeclared type `SnapshotIter`

error[E0412]: cannot find type `SnapshotIter` in this scope
  --> src/app.rs:67:47
   |
28 | struct Snapshot {
   | --------------- similarly named struct `Snapshot` defined here
...
67 |     pub fn iter(pool: Option<&str>) -> Result<SnapshotIter, Box<dyn Error>> {
   |                                               ^^^^^^^^^^^^
   |
help: a struct with a similar name exists
   |
67 |     pub fn iter(pool: Option<&str>) -> Result<Snapshot, Box<dyn Error>> {
   |                                               ^^^^^^^^
help: you might be missing a type parameter
   |
38 | impl<SnapshotIter> Snapshot {
   |     ^^^^^^^^^^^^^^

error[E0599]: no associated item named `CLOCK_UPTIME` found for struct `nix::time::ClockId` in the current scope
   --> src/app.rs:111:51
    |
111 |             let boottime = clock_gettime(ClockId::CLOCK_UPTIME).unwrap();
    |                                                   ^^^^^^^^^^^^
    |                                                   |
    |                                                   associated item not found in `nix::time::ClockId`
    |                                                   help: there is an associated constant with a similar name: `CLOCK_BOOTTIME`

Some errors have detailed explanations: E0412, E0433, E0599.
For more information about an error, try `rustc --explain E0412`.

Feel free to just close if you don't want this sort of not very helpful help. :)

Test for minimal dependencies in CI

Now that johalun/sysctl-rs#37 is fixed, ztop should once again test for minimal dependencies in CI.

Choose a good MSRV policy for ZoL

ztop is binary crate, not a library one. So the MSRV should be determined by the various package builders for each supported OS. For FreeBSD, that's easy: there's only one package collection to worry about. But what about ZoL? What's the oldest Rust toolchain used in the package collection of a modern, widely-used distro? @penryu do you have any ideas about this?

Columns disappear unpredictably with smaller terminal sizes

As of the master branch at f033275 (but not in the most recent release, 0.2.2), the main table doesn't get displayed correctly if there are less than about 90 columns. The constraint solver will prioritize the "Dataset" column and shrink or disappear one of the other columns, seemingly at random. This bug was introduced by 097d565, which replaced the tui crate with ratatui.

Ideally what would happen would be that we would specify a width for the "Dataset" columns of Constraint::Min(1) or something like that, and it would gobble up all available space not used by the other columns. But that doesn't work in either tui or ratatui. Instead, the "Dataset" column gets a fixed width of 1.

Formatting

I wonder if you want cargo fmt used on the codebase? There are substantial modifications to some files when used. If you want it I will make a PR just for formatting, and I will then cargo fmt any work that I push elsewhere. If you don't want to enforce formatting then I will just try to use sensible conventions that fit with your style in my work without running the tool.

Panic at src/app/freebsd.rs:53 on FreeBSD 12

On FreeBSD 12, ztop panics like this:

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `"objset-0xe751ca"`,
 right: `"objset-0x402343"`', src/app/freebsd.rs:53:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The cause is the lack of nunlinked and nunlinks fields in FreeBSD 12's ZFS dataset stats. Shouldn't be too hard to fix.

TTY state not correctly restored on exit when using bash

When the login terminal is bash, terminal settings will not be correctly reset on exit. When the login terminal is fish, everything works fine.

I have bisected this bug to 271a7e5

Steps to Reproduce

1. cargo run
2. press 'q'
3. type "stty" and hit enter
4. observe this garbled output:

speed 9600 baud;
                lflags: -icanon -isig -iexten -echo echoke echoctl
                                                                  iflags: -icrnl -ixon -ixany -imaxbel ignbrk -brkint
                                                                                                                     oflags: -opost tab0
                                                                                                                                        cflags: cs8 -parenb

5. Type anything else and observe that commands aren't visibly echoed to the screen

[documentation] Comparison to `iotop` rather than `top`?

It says "ztop is like top", but wouldn't it make more sense to compare it to iotop here?

Benchmarks for the backend

I spent a little time this evening to explore benchmarks for the backend, but this being a binary only crate I cannot figure out how to call any code from the linux module outside of the binary crate itself :/

Originally posted by @guygastineau in #13 (comment)

Feature: «batch» mode to print values to stdout

Hello,

I would love having a «batch» mode to print output of ztop to stdout, in a machine-parsable way.
Unfortunately I can’t code…
Great tool anyway. It fills a gap between zpool iostat and top -m io.

Define a better MSRV policy

Ztop's current MSRV policy is basically "The oldest possible, and never raise it without considering it a breaking change". That's a reasonable policy for a library crate, but not for a binary crate. Instead, since Ztop's consumers are OS package managers, Ztop should define its MSRV to be the oldest Rust compiler in any supported OS. Currently, that's:

• 1.55.0 for FreeBSD. https://www.freshports.org/lang/rust/

But if we gain Linux support, we should track a few others. @guygastineau what should ztop assume about the lowest Rust version in common Linux distros?