GPUDirect Storage Ready: Are You Buying a Direct Data Path or Compatible File I/O?

Separate data movement from CPU control

In a conventional staged read, file data reaches a buffer in CPU system memory and is then copied into GPU memory for processing. That temporary host buffer is the CPU bounce buffer. GDS can avoid this staging step by enabling direct memory access, or DMA, between storage and GPU memory. The purchasing distinction concerns where the transferred bytes travel.

The CPU still has a role. NVIDIA's design guide distinguishes the control path, managed by system software running on the CPU, from the data path. In the cuFile model discussed here, avoiding a CPU-memory bounce does not mean that a GPU independently performs every part of a storage operation. CPU activity is therefore compatible with a direct data path.

Direct also needs a precise boundary. NVIDIA's best-practices guide describes cases with an intermediate GPU buffer and a device-to-device copy into the application's GPU buffer. Avoiding CPU-memory staging and eliminating every intermediate copy are different claims. An offer should state which behavior it includes rather than substitute an unrestricted zero-copy slogan.

References: [N2][N4]

Successful cuFile I/O can use fallback

The cuFile API reference describes compatibility mode as using conventional host-side file I/O and copying between host and GPU memory where applicable. It also documents cuFile support for host-memory buffers. The presence of the API in an application is consequently insufficient to establish a direct transfer to a GPU buffer.

Compatibility is useful: it lets an application retain functional file access in circumstances where the direct path is unavailable or not selected. Its success can therefore conceal a mismatch between the buyer's expected data movement and the narrower result supplied. A completed read establishes that the requested data was returned within the operation's scope. It does not, by itself, establish how those bytes reached GPU memory.

Keep three propositions separate when reading an offer: the combination is capable of GDS, the file operation succeeds, and the identified operation actually uses the promised direct path. A supplier can establish the first two while leaving the third unanswered.

References: [N3][N6]

Qualify the application, host and selected filesystem

The application or its I/O middleware must use cuFile for the relevant work; installing a library does not redirect every existing file reader. Have the software provider identify which application component reads into which memory destination. An application may use different readers or destinations at different stages, so its GPU compute capability does not settle its storage behavior.

The host and storage implementation must also support the selected path. NVIDIA's overview distinguishes user-level container contents from host kernel components and explains that missing or unsuitable host support can leave cuFile operating through compatibility mode. A container that starts successfully is an application packaging result, not evidence of the underlying transfer path.

Keep this qualification specific to the actual filesystem mount, storage implementation, host environment and supplied releases. NVIDIA's September 17, 2026 release notes record NVMe P2PDMA support introduced in GDS 1.13 for the documented Ext4/XFS NVMe case, removing the need for nvidia-fs.ko in that implementation. A single driver's presence or absence is therefore not a universal GDS verdict.

The appointed platform and storage specialists must qualify the actual hardware combination too. That qualification supplies an input to this decision; the buyer still needs to know which application operations will use it.

References: [N1][N3][N5]

Follow the application's first touch of the data

NVIDIA identifies the strongest intended fit as a pipeline in which GPU code has the first and last processing touch around storage transfers. For a read, ask where the data must be processed first after it leaves storage. For a write, ask where the output is produced before storage receives it. Those answers expose whether bypassing CPU-memory staging serves the application being bought.

Consider a fictional reader that must decode its input on the CPU before sending transformed data to the GPU. Directly delivering the original file bytes into GPU memory does not remove that stipulated CPU decoding task. The provider needs to explain the complete pipeline rather than price a direct-transfer label as though it automatically eliminates the existing host work.

By contrast, a reader that performs the relevant preparation on the GPU has a different data-movement opportunity. Avoiding a host staging step can be useful, but its business value still depends on whether storage transfers constrain the intended work. A path can be direct without being the dominant factor in application completion time. Compare the required pipeline result before paying for an optimization of one stage.

References: [N1][N2]

Compare two offers that both read the file

Consider two fictional offers for otherwise identical hardware, the same selected application and filesystem, and the same named software release. Both proposal descriptions say that the application successfully reads the requested file. These are invented comparison inputs; no benchmark, trace or actual test outcome is represented.

Offer A includes functional file I/O. Its proposed evidence identifies successful completion and correct returned data. It makes no claim about whether the operation uses a direct path or CPU-memory compatibility mode. That can satisfy a buyer whose appointed software team will assess data movement separately, or whose immediate requirement ends at functional access.

Offer B expressly includes qualified direct storage-to-GPU memory transfers for the identified application read operations. It also includes a return explaining the path actually used and any compatibility-mode coverage within that agreed work. B includes an additional result: establishing that the selected application's bytes avoid CPU-memory staging for the operations covered by the promise.

B's wording is still a proposed deliverable. Repeating A's successful-read evidence would leave B's additional claim unestablished. Its responsible provider must supply evidence that can distinguish the two behaviors on the specified configuration.

The same hardware and a matching read-success result do not make the offers equivalent. The buyer must decide whether that additional path result matters to the intended pipeline, and whether B actually includes the integration and verification needed to establish it.

Request evidence of the path used

NVIDIA's troubleshooting guide distinguishes compatibility-mode activity and provides user-level statistics and tracing facilities. It also explains that some I/O paths do not pass through the nvidia-fs driver. The useful purchasing question is therefore which evidence the appointed software provider will interpret for the application's actual path, rather than whether one familiar driver counter changes.

Ask for a result tied to the named application component, configuration and selected filesystem, with the read or write operations and verification coverage stated. It should distinguish functional completion, supported capability and observed transfer behavior. Where direct and compatibility behavior coexist, the return should identify the covered work and exceptions instead of extending one observation to every file operation.

A separate demonstration program can help qualify the environment. It cannot automatically establish how the customer's application performs its own I/O. Likewise, evidence for a read does not establish the path used for writes. Have the responsible specialists select the method and interpret the release-specific evidence; a generic throughput figure or successful-read count cannot answer the path question alone.

References: [N5][N6]

Connect the decision to physical deployment

Once the platform and storage owners have selected the implementation, use Leviathan's Complete Physical Infrastructure Deployment service to discuss the equipment receiving, rack integration, onsite installation, IT cabling and physical records the project needs. The storage-network handoff guide addresses the physical connection records that the next team receives.

Bring a nonconfidential equipment summary, the approved physical connection requirements, the appointed equipment/material supplier and the team receiving the installation. Application integration, GDS configuration and software path verification remain with separately appointed providers. Use the service and project-inquiry links below to define the physical work and its handoff without treating cabling completion as evidence of an application data path.