swift-rust is the storage engine: the proxy, object, container and account
servers, every consistency daemon, erasure coding, the ring, the SQLite
backends, the middleware pipeline, and a bounded concurrency runtime: a
16-crate Rust workspace. It targets a
strangler migration model, but only formats and paths with explicit golden or
live evidence are claimable as compatible. It is not a general production
drop-in replacement.
The data path
A client request travels client → proxy → object / container / account servers → container-update side channel → container server. The proxy fans out to backends and picks a quorum best-response. Object bodies stream end to end through bounded chunks instead of being deliberately accumulated as one request-sized allocation. Exact peak-RSS and large-object limits remain G7/G8 measurements; this page does not turn the streaming design into a memory claim.
The network path is implemented with Hyper/Tokio. swift-runtime keeps
admission control, deadlines, traffic classes, bounded blocking work,
storage/DB execution, structured cancellation, and durability barriers behind
one infrastructure boundary. The isolated W070 result accepts G6 storage
semantics; it is not a G3, G7, G8, or production verdict.
What’s implemented
For a strict yes/no matrix (partial = not implemented), see Rust vs Python parity. Marketing claims must stay inside that page.
Servers & daemons
All four servers plus object/DB replicators, reconstructor, object & container updaters, expirer, account reaper, reconciler, relinker, auditors, recon, drive-audit. Container-sync is library-only — not a full product claim.
Erasure coding (Linux)
liberasurecode codec (fragments byte-identical to PyECLib), streaming multipart-MIME + multiphase-commit PUT, segment-wise + ranged GET, and a reconstructor that heals a lost fragment from its peers (lab-proven).
Container sharding
Backend + local cleave path + unit HTTP helpers. Multi-node KEEP is not claimed under the strict parity rule.
Middleware
tempauth, keystoneauth/authtoken (lab), copy, SLO/DLO, versioned_writes, symlink, staticweb, listings, quotas, ratelimit, s3api/s3token core path.
Build & test
cargo build --release
cargo test --workspace --exclude swift-ec
cargo clippy --workspace --exclude swift-ec --all-targets -- -D warningscargo build --release --features swift-proxy-server/ec,swift-object-server/ec
cargo test -p swift-ec -p swift-object-server -p swift-proxy-server \
--features swift-proxy-server/ec,swift-object-server/ecBinaries
The workspace builds the daemon/CLI set: swift-{proxy,object,container,account}-server,
swift-object-{replicator,reconstructor,updater,auditor}, swift-container-updater,
swift-db-replicator, swift-ring-builder, swift-recon, swift-drive-audit,
swift-manage-shard-ranges, swift-{account,container,object}-info,
swift-get-nodes, and swift-ring-sim.
Server configuration
Servers read SWIFT_DIR (rings + swift.conf) and take a conf file argument.
The candidate still has service-specific compatibility mappings:
| Service | Worker/admission behavior |
|---|---|
| proxy | numeric workers directly selects Tokio runtime threads; process_workers, max_connections, and max_active_requests are separate proxy knobs |
| account / container | numeric workers still maps through workers × max_clients, capped at 128 runtime threads; max_clients sizes the queue |
| object | the same product mapping applies without servers_per_port; port-worker mode supervises OS children and maps max_clients per child |
The latter mappings are compatibility debt, not Eventlet or one-thread-per-idle- connection behavior. The target remains independent finite budgets, but G3/G7 must prove the actual wiring and capacity of each service. See Configuration and Concurrency runtime before sizing a service.
See Testing for the verification strategy and Performance for measured throughput and the latency fixes shipped.