NVIDIA Introduces gds-diag for GPUDirect Storage Checks; Optional Agent Skill Explains Findings Without Automatic Repair
NVIDIA's October 30, 2026, article introduces gds-diag, an open-source diagnostic utility from its GPUDirect Storage team. GPUDirect Storage (GDS) is a data path between storage and GPUs whose suitability depends on hardware, software, filesystem and workload. The new utility inspects an environment, reports findings and suggests mitigations.
NVIDIA's October 30, 2026, article introduces gds-diag, an open-source diagnostic utility from its GPUDirect Storage team. GPUDirect Storage (GDS) is a data path between storage and GPUs whose suitability depends on hardware, software, filesystem and workload. The new utility inspects an environment, reports findings and suggests mitigations. It does not silently change GDS settings or prove that an application has achieved a throughput improvement. The article presents both a deterministic Python command-line tool and an optional agent skill that helps users choose and interpret its commands.
The command-line tool is distributed in the NVIDIA Magnum IO repository under the gds-diag directory. To run the diagnostic script itself, the article calls for Linux and Python 3.8 or newer, with no other installation dependencies for the tool. A working GPUDirect Storage deployment has stronger requirements, including a NVIDIA data-center-class GPU and CUDA Toolkit 12.2 or newer. Those deployment requirements should not be described as dependencies of the diagnostic script. A user can clone the repository, enter the directory, run ./gds-diag.py --help and consult a subcommand's --help before choosing checks. This article does not execute the script on a GPU system or claim that our platform passes its tests.
The subcommands are grouped by question. `all /path/to/check` runs a complete diagnostic sequence for a selected path. Before installation, `support-matrix` shows supported storage combinations and `pre-install` checks GPU support and CUDA. After installation, `post-install` checks whether GDS is present and identifies blockers, while `config-audit` reviews settings and environment variables. For deeper investigation, `container-check` examines container environments such as Docker, containerd, Enroot and Kubernetes, and `mount-check` investigates a chosen directory or mount point. Choosing a command depends on whether one is planning, installing or troubleshooting a particular path; a successful general check need not answer every path-specific question.
Most output is organized into findings with status labels. FAIL is a hard blocker, WARN a possible blocker and INFO a notable observation. PASS appears only in verbose output. Each finding includes an explanation and a proposed mitigation plan; administrators decide whether and how to apply a change. The `--json` option emits structured output for archiving or further analysis. The `support-matrix` command instead produces a table with footnotes, and its `--static` form shows general support while `--live` includes the current system's configuration. A green table cell, a warning, and a successful workload benchmark answer different questions and should not be conflated.
The optional agent skill is located with the tool in the repository. In a supported coding assistant it interprets a natural-language question, selects appropriate gds-diag subcommands, coordinates multi-step checks and explains results or suggests remediation. NVIDIA says it validated this skill with Claude and Codex; that statement does not establish compatibility with every assistant. The underlying CLI remains the deterministic source of diagnostics. An example asks about GDS support in a container and shows the skill identifying the appropriate checks. An agent may propose edits after discussing a finding, but the diagnostic tool itself does not implement the mitigation. A human must review any changes before applying them to a production storage setup.
The article's operational value is a staged way to ask whether hardware is eligible, whether GDS is installed, what a configuration file means and whether a mount point or container can use the path. It also offers structured findings that can be compared across machines. It gives no performance benchmark for this tool and no claim that it automatically fixes a system. The published repository page captured with this story provides the tool and skill context, while the October 30 article establishes the date and the described workflow. Readers need to test their own platform and workload before treating a suggested mitigation as safe or effective.
Sources
FAQ
How should a new user choose and run gds-diag subcommands?
On Linux, obtain the Magnum IO repository, enter gds-diag and inspect ./gds-diag.py --help. Before installation use support-matrix and pre-install; afterward use post-install and config-audit. Choose container-check or mount-check for those specific environments. For a selected path, all /path/to/check runs a full sequence. Read each subcommand's help before use.
How do the status labels and support-matrix output differ?
FAIL is a hard blocker, WARN a possible blocker and INFO an observation; PASS appears only with verbose output. Most findings explain a problem and propose a mitigation, and --json exports structured results. support-matrix instead shows a footnoted table: --static describes general support, while --live adds current-system configuration. A green cell is not a performance benchmark.
Does the agent skill repair configurations automatically, and what do the script and GDS deployment respectively require?
No. The optional skill selects CLI checks and explains findings; the deterministic CLI performs the diagnostic but applies no mitigation. The script itself requires Linux and Python 3.8 or newer. A working GDS deployment separately needs an NVIDIA data-center-class GPU and CUDA Toolkit 12.2 or newer. NVIDIA validated the skill with Claude and Codex, not every assistant.