feat(dashboard): investigate available space metric integration

[Starosdev]

Feature Request

Environment

• Affected: Both
• Component: Backend / Frontend / Collector

---

Description

Research and plan the integration of an "available space" metric into the Scrutiny dashboard. This metric would show users how much usable capacity remains on each drive, providing a practical engagement point alongside existing SMART health data.

Currently, Scrutiny focuses on SMART health attributes but does not display filesystem-level capacity information. Adding available space would give users a more complete picture of their drive status at a glance.

---

Research Areas

1. Data Source Identification

Determine the best approach for collecting available space data:

• smartctl capacity data — smartctl reports total drive capacity (User Capacity field) but not filesystem-level usage. This is already partially available in device registration data.
• Filesystem-level data — Requires additional collection (e.g., df, lsblk, or similar). This would need changes to the collector.
• NVMe Namespace Utilization — NVMe drives report namespace utilization via smartctl, which can approximate used space at the drive level.
• S.M.A.R.T attributes — Some drives expose:
  • NVMe: Data Units Written / Data Units Read (cumulative, not remaining space)
  • NVMe: Percentage Used (wear, not capacity)
  • SSD: Total LBAs Written

2. Implementation Approaches

Approach	Pros	Cons
Drive capacity only (from smartctl)	No new collection needed	No filesystem usage info
Collector gathers df data	Accurate filesystem usage	Requires mapping devices to mount points; complex in Docker
Optional agent/sidecar	Clean separation	More deployment complexity
User-provided capacity data	Simple, no collection changes	Manual, may go stale

3. Dashboard Integration

• Where to display: summary cards, detail view, or both
• Visualization: progress bars, percentage, absolute values
• Alerting: configurable threshold for "low space" notifications
• How it interacts with existing health status indicators

---

Technical Considerations

Location

• Collector device detection: collector/pkg/detect/
• Models: webapp/backend/pkg/models/
• Dashboard summary API: webapp/backend/pkg/web/ (/api/summary)
• Frontend dashboard: webapp/frontend/

Challenges

• Docker omnibus mode: The container sees raw block devices, not necessarily mount points. Mapping /dev/sdX to a filesystem mount requires additional logic.
• Hub/spoke mode: Remote collectors may not have filesystem context for the drives they scan.
• RAID/LVM/ZFS: Logical volumes don't map 1:1 to physical drives. ZFS pool capacity is already tracked separately.
• Drive capacity vs. filesystem capacity: A 4TB drive may have multiple partitions with different usage levels.

---

Acceptance Criteria

• Document available data sources for space/capacity metrics (what smartctl already provides vs. what requires new collection)
• Evaluate feasibility of each implementation approach for both omnibus and hub/spoke deployments
• Identify the minimum viable approach that provides user value without major collector changes
• Propose dashboard UI placement and visualization
• Consider interaction with existing ZFS pool capacity tracking
• Define whether this blocks on or complements the workload insights feature set

---

References

• Existing device model stores capacity from smartctl registration
• ZFS pool metrics already track capacity via /api/zfs/summary
• Workload insights feature (v1.30.0 milestone) may overlap with capacity tracking