RustFS Backend

RustFS is one optional S3-compatible provider for NoKV artifact blocks. It does not own namespace metadata, root placement, revision reachability, or garbage collection policy.

native CLI / direct SDK / optional Workbench MCP sidecar
  -> NoKV metadata and publication service
  -> S3-compatible object interface
  -> RustFS

Local Provider Profile

Treat the following as one reviewed deployment profile:

endpoint and region
bucket and exclusive prefix
access identity and credential source
TLS and certificate policy
path-style or virtual-host addressing
single-PUT and multipart limits
request timeout and retry policy

Use RustFS’s current installation and server documentation to start a local endpoint, then configure those values through NoKV’s deployment environment. Credentials belong in the environment or a secret manager—not metadata, manifests, logs, examples, or object keys.

For repeatable local testing, record the exact RustFS image or binary version, TLS mode, clean or reused data directory, bucket initialization, NoKV durability profile, and injected failures. Keep RustFS data and Holt metadata in separate durable locations. Reset them as a paired test deployment; an empty object directory is not compatible with metadata that still references old blocks.

Durable Object Namespace

Artifact blocks retain the provider-neutral key:

nokv/artifacts/{logical_shard_id}/{root_id}/{artifact_revision_id}/blocks/{object_index}

The configured bucket and prefix contain one immutable identity marker:

nokv/system/object-namespace

The control plane binds each RootId to that marker’s ObjectNamespaceId exactly once. Routes carry the id and the metadata root fence persists it with placement generation and owner epoch. A changed endpoint is safe only when it resolves to the same durable marker; another healthy RustFS prefix is still a different object namespace and is rejected before publication.

Write-Conformance Admission

Before business writes, NoKV probes reserved, unreferenced keys on the exact provider handle. Admission v1 verifies:

• fresh single-PUT create-if-absent;
• exact-byte replay and different-byte collision;
• whole-object and exact ranged readback;
• a concurrent different-byte create race with exactly one stored winner.

The receipt is scoped to that handle and to the maximum single-PUT size the probe exercised. Another handle, a missing receipt, or a larger block fails before object or metadata publication. Multipart creation, completion, and abort are not qualified by admission v1 and cannot inherit its receipt.

The deployment must also preserve ambiguous timeout outcomes for reconciliation, prevent provider lifecycle rules from deleting reachable NoKV objects, and avoid depending on bucket listing for recovery or reachability.

Failure Boundary

Publication remains object-first and metadata-last. Metadata failure leaves staged-object records for cleanup. Uncertain delete completion enters quarantine instead of being inferred from a later listing. Temporary provider failures surface as retryable object errors after bounded attempts, without exposing endpoint, bucket, prefix, credentials, or physical keys in public errors.

This local profile does not by itself qualify multipart behavior, crash recovery, process restart, owner replacement, or ambiguous-completion reconciliation. Those require separately retained evidence under the declared provider and durability profile.