Bare-metal Installation

MinIO Warp is open-source software released under the GNU AGPL v3.

This page documents installing Warp on bare-metal systems. Warp runs as a standalone binary that provides S3 testing capabilities for evaluating storage system performance.

Prerequisites

Before installing Warp, verify that your system meets the following requirements.

  • Network access to the S3-compatible storage endpoints you plan to test.
  • Valid S3 credentials including an access key and secret key for the target storage system.

Install Warp

Warp provides pre-compiled binaries for common operating systems and architectures. Select the tab for your system to download and install the appropriate binary.

Install Warp with RDMA support

Version added
S3 over RDMA requires Warp 1.7.0 or later, installed from the separate warp-rdma package. Earlier versions of Warp cannot transfer over RDMA, and the standard Warp binary has no RDMA support at any version.

The standard binary installed above speaks S3 over HTTP. To benchmark S3 over RDMA, install the warp-rdma package instead. It ships the Warp binary together with libs3rdma, the library that carries the object payload across the fabric.

The binary links libs3rdma.so.0 as a hard dependency and carries a runtime search path of /usr/lib/warp, so the package works without any change to /etc/ld.so.conf.d. Installing the binary on its own produces a program that fails to start.

Prerequisites

The RDMA package needs the same fabric configuration on the client host as on a server:

  • An RDMA adapter with an ACTIVE port and an IPv4 GID, which RoCE v2 requires.
  • /dev/infiniband/uverbs0 and /dev/infiniband/rdma_cm readable by the user that runs Warp.
  • A driver file in /etc/libibverbs.d/, such as mlx5.driver.
  • An unlimited locked-memory limit.

Confirm each one:

rdma link show          # state ACTIVE physical_state LINK_UP
ls /dev/infiniband/     # uverbs0 rdma_cm ...
ls /etc/libibverbs.d/   # mlx5.driver ...
ulimit -l               # unlimited

Install the package

The package installs two paths:

Path Contents
/usr/local/bin/warp The Warp binary, built with RDMA support
/usr/lib/warp/libs3rdma.so.0 The RDMA transfer library

The bare binary is also published as warp.v1.7.0.rdma in the same directory. It is the executable only, so it still needs libs3rdma.so.0 from the package to run.

Verify the installation

warp --version
ldd $(command -v warp) | grep s3rdma
libs3rdma.so.0 => /usr/lib/warp/libs3rdma.so.0

A line reading libs3rdma.so.0 => not found means the library is missing. Reinstall the package rather than copying the binary on its own.

Run an RDMA benchmark

Pin the adapter that carries the fabric address, then select the transfer mode:

export S3RDMA_DEVICE=mlx5_0
warp get --host 198.51.100.11:9000 --tls \
  --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEY \
  --rdma=cpu --obj.size=64MiB --objects=500 --concurrent=32 --duration=5m

--rdma=cpu transfers into host memory and needs no GPU. --rdma=gpu transfers into CUDA device memory over GPUDirect RDMA, which needs an NVIDIA GPU with a compatible driver and CUDA runtime. For the GPU, PCIe, and driver requirements, see GPU in the AIStor documentation.

Address the storage nodes directly rather than a load balancer or a service name that resolves to a different interface. Traffic sent to an address that is not on the fabric leaves over the primary adapter and never uses RDMA.

When driving several client hosts, set S3RDMA_DEVICE in the environment of every warp client daemon. The driver does not propagate the variable.

Certificate trust for TLS endpoints

libs3rdma verifies the server certificate against the operating system trust store. The --insecure flag and the SSL_CERT_FILE environment variable reach only the Warp S3 client, never the RDMA transfer path.

If S3 control requests succeed but RDMA transfers fail, the S3 client may trust or bypass the issuer while libs3rdma still rejects it. The adapter counters stay flat, which can look like a broken fabric. Install the issuing certificate authority system-wide with update-ca-certificates on Debian and Ubuntu, or update-ca-trust on RHEL.

Run Your First Test

After installation, test Warp functionality.

The following command runs a basic mixed workload test against your S3-compatible storage:

warp put --host s3.example.com --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEY --duration 5m

Replace s3.example.com with your actual S3 endpoint. Replace YOUR_ACCESS_KEY and YOUR_SECRET_KEY with your valid credentials.

You can alternatively export credentials using environment variables. See the Environment variables for exact variable names and usage.

The test runs for five minutes and displays throughput and latency metrics. Successful completion confirms that Warp can connect to your storage system and perform test operations.

Next steps

After installing Warp, proceed to the Administration section to learn about test configuration and test types.

Review the Core Concepts documentation to understand test configuration, workload types, and result interpretation.

For distributed benchmarking scenarios requiring multiple client machines, see the Distributed benchmarking documentation.

Consult the Reference section for complete command-line options and detailed parameter descriptions.