dewDrive

Storage Telemetry & macOS USB Bridge Architecture

Hardware & Telemetry• 3 min read• Updated 2026-08-28

Kernel-level USB Mass Storage limitations, NVMe vs SATA SMART diagnostics, and the 3-Tier diagnostic hierarchy established for dewDrive hardware telemetry.

This document details the technical journey, empirical benchmark results, hardware behavior, kernel limitations, and self-learning signature engine rules established for dewDrive storage telemetry.

1. Executive Summary & Diagnostic Hierarchy

dewDrive storage telemetry adheres to a strict 3-Tier Diagnostic Hierarchy:

[ Tier 1: Verified Signatures ]
            │ (Known Controller / VID:PID Match)
            ▼
[ Tier 2: Live Engine Probe   ]
            │ (smartctl 7.4 Sandboxed CLI / Kernel Passthrough)
            ▼
[ Tier 3: OS Kernel Diagnostics ]
            │ (macOS IOKit / Win32 DeviceIoControl / Linux sysfs)

Core Telemetry Principles

  1. Never delete or swallow comments documenting platform-specific behavior.
  2. Never display artificial fallback numbers in place of missing lifetime SMART attributes. If kernel-restricted, display strict -- dashes with informative warning tooltips.
  3. Strict Immutable Anchoring: Never identify or index disk entities by transient strings (e.g., mount points or raw device names). All matching is anchored to immutable hardware serial numbers and system UUIDs.

2. Kernel-Level Insights (Apple IOUSBHostFamily & Bridge Operations)

1. Formatted Filesystems vs Raw GPT Disks on macOS

  • Empirical Discovery: Formatting an external USB drive (APFS, exFAT, or NTFS) enables macOS to report volume free space, filesystem personality, APFS TRIM readiness, and real-time I/O transfer velocities.
  • Kernel Boundary Reality: However, Apple's IOUSBHostFamily kernel driver blocks raw NVMe Log Page 0x02 (GetLogPage failed: system=0x38, sub=0x0, code=706) over USB pass-through regardless of filesystem type.
  • Architecture Decision: dewDrive utilizes filesystem metadata for active volume monitoring, but respects the kernel boundary by returning wear_life_pct: null when Log Page 0x02 is restricted.

2. SATA-over-USB vs NVMe-over-USB Protocol Split

  • SATA-over-USB (USB-SAT): Apple's IOUSBHostHIDDevice / SAT driver translates ATA opcodes (0xB0 SMART READ DATA) into SCSI pass-through. Full native SMART telemetry is extracted (Wear Leveling Count, Power On Hours, Temperature, LBAs Written).
  • NVMe-over-USB (USB-NVMe): Apple's IOUSBHostFamily USB NVMe driver blocks raw NVMe Admin Log Page 0x02. Requires Swarm Signature Calibration or -- badging on macOS.

3. Four-Mode Dynamic Telemetry Governor

The background daemon (dewdrive-agent-rmm) dynamically adapts its polling frequency and sensor depth according to machine operational status:

Mode Trigger Condition Polling Rate Monitored Metrics
AC Standard Connected to wall power Every 30s CPU, RAM, NVMe temps, I/O bandwidth, SMART status
Battery Eco Running on DC battery Every 180s Low-frequency battery health, high-level disk capacity
Spectator Turbo User actively viewing UI Every 3s Sub-second IOPS, disk read/write bandwidth counters
Emergency Forensics Temp spike > 65°C or SMART fail Every 10s Complete SMART attribute dump, emergency cloud alert

This governor ensures zero perceptible battery drain during routine background operations while guaranteeing sub-second responsiveness during active administrative inspections.

Tags:#telemetry#smart#nvme#sata#macos#usb#hardware