Skip to content

dashdot v6 reports -1 for all storage on ZFS; fix with FS_VIRTUAL_MOUNTS + FS_DEVICE_FILTER

TL;DR.

dashdot 6.x cannot attribute usage to ZFS pool member disks and returns -1 per disk. Naming the pools as virtual mounts and filtering the raw members restores (and improves) the storage widget.

Problem

After upgrading dashdot (mauricenino/dashdot) from 5.x to 6.x on a ZFS host, GET /load/storage returns [-1,-1,-1,...] — one -1 per physical disk — and the Storage widget shows nothing useful. GET /info still enumerates the disks correctly, so it is an attribution failure, not a detection failure.

Verify it is a regression rather than a config problem by running both versions side by side; the old image is still local right after the pull:

docker run -d --rm --name cmp --privileged -p 30002:3001 -v /:/mnt/host:ro <old-image-id>
curl -s localhost:30002/load/storage   # 5.2.3 -> one aggregate byte count, then zeros
curl -s localhost:30001/load/storage   # 6.3.4 -> [-1,-1,...]

Cause

ZFS pool members have no mounted filesystem of their own, so dashdot cannot map sda..sdj to usage. The pool itself appears in df under a name that is not a device path (qi, rpool/ROOT/ubuntu), which dashdot treats as a virtual filesystem it must be told about.

Fix

Name the pools as virtual mounts, and hide the raw members:

-e DASHDOT_FS_VIRTUAL_MOUNTS=qi,rpool/ROOT/ubuntu \
-e DASHDOT_FS_DEVICE_FILTER=sda,sdb,sdc,sdd,sde,sdf,sdg,sdh,sdi,sdj

Use the exact filesystem name from df -PT (the dataset, e.g. rpool/ROOT/ubuntu), not just the pool name — rpool alone yielded no entry while rpool/ROOT/ubuntu did. Result is better than 5.x: every pool reports separately instead of one aggregate number.

Also worth knowing

The only documented breaking change in dashdot 6.0.0 is a units flip in the static speedtest file, which is unrelated and only matters if you supply one.

No signals yet