HW requirements

[TristisOris]

I read the HW and network requirements. It's unclear - are these ideal requirements for high load, maximum load? If for 1TB of data the file operations aren't very intensive and regular traffic isn't high, what will the actual network load be?
What's the overhead coefficient - if traffic is 100 Mbit without S3, how much will it be under the same conditions but with S3?

[yhay81]

Those numbers are production sizing recommendations, not a hard minimum per terabyte. Capacity and network throughput are independent: storing 1 TB does not itself create traffic. The important inputs are request rate, average object size, read/write ratio, concurrency, and whether this is a single-node or distributed erasure-coded deployment.

There are two different kinds of “overhead”:

1. Client ↔ RustFS (S3 protocol). A 100 Mbit/s stream of object payload is still approximately 100 Mbit/s of payload on the client-facing link. HTTP headers, TLS records, TCP/IP, and S3 request metadata add overhead, but there is no fixed S3 multiplier. With large sequential objects it is normally a small percentage; with many tiny objects, per-request headers and connections can dominate. So it would be misleading to promise “100 becomes exactly 110 Mbit/s.”

2. RustFS node ↔ node. This exists only in a distributed/erasure-coded setup. For an RS (k,m) set, each object produces k data shards plus m parity shards, so stored bytes are approximately:

payload × (k + m) / k

For the documentation's RS(10,4) example, that is about 1.4× stored data. If the request lands on a node which distributes the shards, normal write-side east/west traffic is on the order of the remote shards (roughly payload × (k+m-1)/k when one shard is local), in addition to the client ingress. Reads normally need only enough shards to reconstruct the payload, but failures, healing, rebalancing, replication, or scanning can temporarily use much more bandwidth.

For your stated low-load case, a small single-node deployment can run far below the published production hardware table; the official test baseline is 1 core/1 GB and a single node. However, single-node/single-disk mode has no erasure-code redundancy and is not highly available. The 4+ node and 10GbE guidance is aimed at production durability, concurrency, and especially keeping rebuild/healing time reasonable—not merely at holding 1 TB.

If your current useful payload is 100 Mbit/s, a 1GbE link has ample normal-operation headroom for a low-concurrency single node. For a distributed cluster, size the client link for the 100 Mbit/s workload and the storage network separately for erasure writes plus failure recovery. The reliable way to choose is to run an S3 benchmark with your real object-size distribution and observe per-interface RX/TX (or Prometheus rate(node_network_receive_bytes_total[5m]) / ...transmit...) during PUT, GET, and a healing test.

References: RustFS hardware selection, production hardware guide, and erasure-coding explanation.

[TristisOris]

That's literally what the documentation does — it gives data calculated per terabyte. 10 Gbps+ is listed as the bare minimum.

Ok, got it, need to try.