Making Linux disk sync visible

sync(1) is one of those commands whose silence is easy to mistake for a hang. It waits for dirty data in the Linux kernel's page cache to reach storage, but gives the person at the terminal no estimate of progress or throughput. psync wraps that operation with a live view: it samples the kernel's dirty and writeback counters while sync runs, then prints a summary. It also has a watch mode for observing writeback without initiating sync, and a follow mode that resyncs a scoped set of files after changes.

The project is a compact Linux command-line tool written in Go. It reads /proc/meminfo, /proc/diskstats, and mount information, uses inotify for follow mode, and builds its command interface with Cobra. Its demo command drives the real display with a deterministic simulated drain, which helps people see the output even when their own storage flushes too quickly.

A picker with two paths

One useful design decision came from issue 013. When follow or filesystem watch mode has no explicit target, psync needs the user to choose a mounted filesystem. The existing numbered prompt worked in scripts, but offered no keyboard navigation or filtering in a terminal. The proposed replacement, loom.Choice, was an interactive inline pane. That library opens the real terminal directly, so it cannot honor the picker's injectable reader and writer in the way a scanner can.

The implementation kept those two needs explicit. In a real terminal it uses loom.Choice and loom.RunPane; without a terminal it retains the scanner-based prompt. It checks both stdin and stdout before opening the pane. There was another subtlety: the widget filters and reorders its choices, so the returned position cannot safely index the original mount list. The implementation maps the selected item's unique mount-point name back to the domain entry instead. These decisions are recorded for reuse in docs/LoomAdoption.md, and issue 013 was closed after implementation and review (4485b28, 67e617d, 2026-09-11).

The canary work around that change exposed a more general integration trap. An API probe in a scratch Go module fetched the published Loom version, while psync's active local go.work redirected builds to a much newer sibling checkout. The API happened to match, but the probe had not checked the dependency psync would actually compile against. The team caught the provenance mismatch during review, inspected the sibling source, and wrote a feedback note with the corrective rule: check go env GOWORK in the target repository before trusting an isolated dependency probe. The note does not pretend the canary was correct; it preserves the failure mode so the next integration can avoid it.

The broader September work also created go.work.example templates and ignored local workspace links across sibling repositories, added a release configuration and generated man-page support, and prepared a container build path. The retrospective records a nine-repository verification effort and several distinct failure modes. That is evidence of multi-repository coordination and durable process learning, though the psync history alone does not establish that any individual feature was beyond a capable solo developer. The clearest agentic contribution here is breadth with traceability: issues, implementation commits, verification notes, reusable design guidance, and an explicit account of a misleading probe all live alongside the product.

Facts

psync's site already explains its Linux focus and offers examples, options, and release links. Its pinned download instructions still say v0.2.1 even though the repository has a v0.2.2 tag, a small but concrete reminder that product polish includes keeping the path from a convincing demo to a current installation accurate.