Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[BUG] Host status Disk metric reports a pseudo-filesystem (squashfs always 100%, efivarfs ~89%)

Closed Beginner friendly
  • Is something wrong?
#1,340 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
observability, operating-systems

Research direction

Start in src/backend/hosts/metrics/widgets/disk-collector.ts and inspect PSEUDO_FS_RE and findWorstMountIndex. Reproduce with mounts containing squashfs or efivarfs, then verify that the Disk metric selects real storage rather than pseudo-filesystems and no longer reports those mounts as the fullest.

Written by the indexing model from the issue text.

Description

bug good-first-issue host-metrics platform-docker platform-linux platform-web
Title

Host status Disk metric reports a pseudo-filesystem (squashfs always 100%, efivarfs ~89%)

Platform

Website - Other Browser

Server Installation Method

Docker

Version

2.8.0

Troubleshooting
  • I have examined logs and tried to find the issue
  • I have reviewed opened and closed issues
  • I have tried restarting the application
  • I have checked open issues and ensured this is not a duplicate
The Problem

The host-status Disk figure reports a pseudo-filesystem instead of real storage, so it is wrong on two of my hosts in different ways:

  • A StartOS server reads Disk 100% permanently. StartOS mounts around 100 squashfs images (one or more per package container), and a squashfs is 100% full by construction.
  • An Ubuntu desktop reads ~89%. Its "worst" mount is efivarfs at /sys/firmware/efi/efivars, which is UEFI NVRAM, not storage. It has no squashfs at all, so it's the same defect by a different route.

Why: In src/backend/hosts/metrics/widgets/disk-collector.ts (unchanged on the 2.8.0 tag) the exclusion list is

const PSEUDO_FS_RE = /^(tmpfs|devtmpfs|overlay|udev|none|shm)$/;

and findWorstMountIndex then reports whichever remaining mount has the highest used/total. squashfs and efivarfs aren't excluded, so they win the maximum.

Suggested fix: Widen the exclusion, e.g. squashfs|efivarfs|ramfs|proc|sysfs|cgroup2?|debugfs|securityfs|pstore|configfs|fusectl|bpf|tracefs, or better, consider only mounts backed by a real block device.

A related caution, if the figure is ever meant to be exact: on btrfs, df reports usage of allocated chunks, not of the device. My server's pool showed 98.56% used while ~570 GiB of its 1.81 TiB was still unallocated. btrfs filesystem usage gives the honest number.

How to Reproduce
  1. Add a host whose mounts include a squashfs (any snap-using Ubuntu, or StartOS) or an efivarfs (any UEFI Linux).
  2. Open its host status. Disk shows the fullest pseudo-filesystem (100% for squashfs) rather than real storage.
Additional Context

Not a duplicate of #977, #1046 or #1067, which were about which real mounts are counted. Originally filed as Termix-SSH/Termix#1467, which was closed and redirected here. Also sent by email to [email protected] on 2026-09-22.

Dominant language
No language data
Stars
28
Forks
4
No merged PRs in 30d

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Termix-SSH/Support

All issues in Termix-SSH/Support

Similar issues

More Observability & SRE issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.