DLPX-88427 Fix estat metaslab-alloc: no data on 2026.3 engines + garbled names

[dbshah12]

Background

estat metaslab-alloc is a BPF-based tracer that measures how long ZFS takes
to allocate a block of storage on each device in a pool (e.g. /dev/xvdb1).
It feeds per-device IOPS and latency data into Telegraf → InfluxDB.

After upgrading Ubuntu — which brought ZFS 2.4.99 / kernel 6.17 on 2026.3
engines — this metric stopped producing any data at all.

Problem

Main symptom: estat metaslab-alloc compiles and runs without errors but
emits zero JSON lines on 2026.3 engines. InfluxDB has no
estat_metaslab-alloc measurements since the Ubuntu upgrade.

Secondary symptom (some pre-2026.3 engines): the metric was occasionally
emitting garbled device names like \x2f\xa3\x00... (raw memory bytes
rendered as escape sequences) instead of readable paths like /dev/xvdb1.
These break Telegraf/InfluxDB JSON parsing.

Root Cause

Why no data on 2026.3+ (main issue)

Think of the BPF tracer as a stopwatch split across two checkpoints inside
ZFS's storage-allocation code:

1. Checkpoint A (metaslab_alloc_dva) — starts the stopwatch and tags it
   with the current thread ID.
2. Checkpoint B (metaslab_group_alloc) — finds that thread's stopwatch,
   measures elapsed time, and records it against the specific disk device.

In older ZFS the call chain was linear:

metaslab_alloc_dva  →  (internally calls)  →  metaslab_group_alloc

After the Ubuntu/ZFS upgrade (ZFS 2.4.99, 2026.3) ZFS was internally
refactored. The allocation path no longer goes through
metaslab_alloc_dva at all. metaslab_group_alloc is now invoked directly
by a different caller. Checkpoint A never fires. When Checkpoint B arrives it
looks for a stopwatch entry, finds nothing, and silently returns. Zero output.

Confirmed with raw kernel probes: metaslab_group_alloc fires ~900×/sec
during normal pool I/O while metaslab_alloc_dva fires 0 times.

Why garbled device names (secondary issue, some older engines)

On some intermediate ZFS versions the internal layout of the
metaslab_group_t struct changed. The BPF code that reads the device name
was reading from the wrong memory offset, copying random bytes into the metric
name field. These appeared as "name":"\x2f\xa3..." in the JSON output.

Solution

No-data fix (2026.3+)

Updated metaslab_group_alloc_entry to handle both ZFS code paths via a
dva_owned flag in data_t:

• Old path: metaslab_alloc_dva_entry sets dva_owned=1 and stores
  psize. metaslab_group_alloc_entry detects this via data->dva_owned
  and fills in vdev info without re-applying the pool filter.
• New path: if no dva_owned entry exists, metaslab_group_alloc_entry
  creates a fresh entry, applies the pool filter via explicit bpf_probe_read
  calls on mg->mg_class->mc_spa (with NULL guards), and sets dva_owned=0.

Using dva_owned rather than data->ts != 0 prevents a stale new-path
entry (from a missed kretprobe event) from bypassing the pool filter.

Restored allocation failures metric

metaslab_alloc_dva_exit now correctly emits an "allocation failures"
aggregation when the return value indicates failure. psize is stored in
data_t.size at entry time (kretprobe argument registers may be clobbered).
metaslab_group_alloc_exit leaves old-path entries alive so the dva exit
can always find them; new-path entries are deleted immediately.

Garbled-name fix

A #pragma unroll loop scans all bytes of vd_name up to the first NUL.
If the string is empty or any byte is outside printable ASCII (0x20–0x7e),
the whole name is replaced with "unknown".

Wrapper script removed

PR #120's grep-filter wrapper is deleted and telegraf.inputs.playbook
restored to call estat directly. The fix is in the BPF code itself.

Testing Done

Each fix was deployed to de-dev1.dlpxdc.co (ZFS 2.4.99-1delphix.2026.03.15,
kernel 6.17.0-1007) and verified — 0 compile errors, clean JSON output — before
committing. Final run:

{"name":"/dev/xvdb1","axis":"success","iops(/s)":"21","avg latency(us)":"4","throughput(k/s)":"329",...}
{"name":"/dev/xvdc1","axis":"success","iops(/s)":"18","avg latency(us)":"2","throughput(k/s)":"267",...}
{"name":"/dev/xvdd1","axis":"success","iops(/s)":"16","avg latency(us)":"3","throughput(k/s)":"234",...}
{"name":"total","iops(/s)":"55","throughput(k/s)":"832"}

Also verified on dhruv2.dlpxdc.co (ZFS 2.4.99-1delphix.2026.05.19,
kernel 6.17.0-1015) — same clean output.

Backward compatibility: metaslab_alloc_dva probes are retained; older
engines continue using the original code path unchanged.

Known gap — garbled-name fix: engines old enough to show this bug are not
currently available. Fix verified correct by code analysis.

Known gap — kernel 6.14 compile error: metaslab-alloc.c fails to compile
on kernel 6.14 due to an incomplete-type error in linux/bpf.h pulled in
transitively. Deferred to a follow-up (same class as DLPX-96701).