* fix(obs): open cleaner compression source with O_NOFOLLOW The compressor opened the source log via File::open, which follows a symlink at the final path component. Between the scanner selecting a regular file and this open, an attacker with write access to the log directory could swap the entry for a symlink (TOCTOU) pointing at, say, /etc/shadow, whose contents would then be copied into an archive. Open the source with O_NOFOLLOW on Unix so such a swap fails with ELOOP; the temp/archive path already refused symlinks, this closes the source side. Refs rustfs/backlog#1210 Co-Authored-By: heihutu <heihutu@gmail.com> * fix(obs): recompress instead of trusting leftover cleaner archives archive_header_ok only checked the first 2-4 magic bytes before treating an existing .gz/.zst as a completed prior result and letting the caller delete the source log. A file with valid magic but a truncated or forged body passes that check, so an attacker with write access to the log directory (or a crashed prior run) could plant such a stub and make the cleaner delete the real log without ever producing a usable archive — silent audit-data loss. Chosen fix: stop trusting cross-process leftovers entirely and always recompress the source in this pass, rather than fully decoding every leftover to validate it. Full-decode validation would add real CPU cost and decode-bug surface for a rare crash-recovery case; the existing atomic create_new+rename already overwrites whatever sits at the archive path (a planted symlink is replaced, never followed) with a freshly written, fsync'd archive, so a partial/forged leftover can never gate source deletion. This is the lowest-regression option. Refs rustfs/backlog#1211 Co-Authored-By: heihutu <heihutu@gmail.com> * fix(object-data-cache): cap memory-gate reservation at cache growth headroom The memory gate subtracts `admitted_since_refresh` from the snapshot's available bytes so a burst arriving faster than the 5 s refresh cannot over-allocate. That counter is GROSS: it only rolls over on the refresh and never rolls back when a fill is later evicted, cancelled, or loses the invalidation race. Under sustained high-throughput churn (net footprint flat and far below `max_capacity`) the raw counter balloons past the memory the cache actually holds, so `effective_available` collapses and the gate reports false memory pressure — skipping the hottest fills with SkippedMemoryPressure until the next 5 s refresh. This only lowers hit rate; it never returns wrong data and self-heals each refresh. Fix direction 1 (minimal regression): cap the reservation deduction at the cache's own growth headroom (`max_capacity - weighted_size()`) instead of letting the unbounded gross counter shrink the system-available budget. The cache can never hold more than `max_capacity`, so a burst adds at most that headroom of real memory before moka evicts to stay bounded (net-zero churn beyond that point) — capping the deduction there keeps the reservation honest without treating gross churn as growth. Chosen over net-accounting (direction 2, releasing bytes on every failure/cancel/eviction path) because that only plugs the leak on failed fills and would not address the core defect: churn of *successful* insert/evict fills over the 5 s window. It also touches only the gate plus one call site rather than every failure path in moka_backend. The cap only ever raises `effective_available`, so real memory pressure (a low snapshot at refresh) still suppresses fills; when the cache is at capacity the headroom is 0 and the deduction vanishes, correctly reflecting net-zero churn. `MokaBackend` now stores `max_capacity` and passes the live headroom into `allows_fill`. Adds targeted gate tests: gross churn far above headroom no longer falsely suppresses, yet the reservation still bounds a burst while the cache can genuinely grow. Refs rustfs/backlog#1212 Co-Authored-By: heihutu <heihutu@gmail.com> * test(ecstore): assert native O_DIRECT path runs in uring read test uring_preserves_o_direct_for_eligible_reads only compared bytes through LocalDisk::read_file_mmap_copy. On a filesystem that rejects O_DIRECT the read silently degrades to the buffered StdBackend fallback and the byte check still passes, so the test could go green without the native read_at_direct path ever executing -- a vacuous pass. Add a per-disk native_direct_reads counter on UringBackend, incremented only when pread_uring_direct completes, and rebuild the test to drive a real UringBackend's pread_bytes and assert the counter is non-zero (every eligible read went through the native tier). When io_uring or O_DIRECT is unavailable on the host filesystem (restricted CI runners, tmpfs), the test skips loudly via eprintln instead of asserting a tautology, while still checking byte-correctness on whatever tier served the read. The counter also gives a gray release a positive signal that the O_DIRECT tier is serving reads, not just a fallback count. Refs rustfs/backlog#1213 Co-Authored-By: heihutu <heihutu@gmail.com> * fix(ecstore): warn + count read-time EINVAL on native O_DIRECT reads classify_direct_read_error is only reached from the read side: the O_DIRECT open in pread_uring_direct already succeeded (an open-time refusal is handled earlier as DirectOpenError::ODirectRefused). So an EINVAL/EOPNOTSUPP arriving here is a read-time error on an fd the kernel accepted for O_DIRECT -- far more likely an alignment bug in the aligned read path than an unsupported filesystem. The old code latched the disk's native path off with only a once-per-disk debug trace, hiding a potential correctness regression behind a silent buffered-read downgrade. Diagnostics only: the fallback behaviour is unchanged (the native path is still latched off and the caller still reads via StdBackend). This adds a rustfs_io_uring_direct_read_einval_total counter and promotes the once-per-disk trace from debug to warn so an operator can see an alignment regression instead of an unexplained latency/CPU shift. Refs rustfs/backlog#1214 Co-Authored-By: heihutu <heihutu@gmail.com> * docs(ecstore): document data-blocks-first default and its tail-latency cost DEFAULT_RUSTFS_GET_DATA_BLOCKS_FIRST_READER_SETUP is true and must stay true: deferred-parity is the deliberate, already-rolled-out full-object GET default from backlog#1159/#923. Flipping it back to false in code would silently revert that rollout for every deployment that has not set the env var, so this commit only documents -- no behaviour change. The added notes explain what data-blocks-first does (schedule data shards up front, engage parity lazily on a missing/corrupt data shard), the known trade-off (parity is engaged late, so a slow-but-not-dead data drive raises GET p99 because the faster parity shards are not raced against it until a data shard is declared missing), and the operational rollback switch (RUSTFS_GET_DATA_BLOCKS_FIRST_READER_SETUP=false), which is intentionally an env override rather than a code default change. No metric was added: the low-risk observability hook for "slow data drive engaged deferred parity" would live at the deferred-stripe engage point, which is out of this file's scope; this change stays documentation-only to avoid touching the hot GET path. Refs rustfs/backlog#1215 Co-Authored-By: heihutu <heihutu@gmail.com> * docs(ecstore): document wide-directory walk stall hazard and tuning list_dir enumerates a whole directory in one os::read_dir call (count = -1), and the walk caller bounds that entire enumeration with the per-read stall budget (default 5s) as if it were a single read. For a wide, flat prefix -- one directory holding millions of immediate children -- a single readdir can exceed the budget on a healthy disk, trip DiskError::Timeout, and surface as a ListObjects 500 quorum failure though the drive is fine (a #2999 sub-class). This is documented, not rewritten: turning the one-shot readdir into a streaming/batched enumeration that refreshes the stall deadline between chunks is an architecture-level change with high regression surface (ordering, the count contract, quorum merge) and belongs in a separate follow-up. The supported mitigation today is operational, so the comments point wide-directory deployments at RUSTFS_DRIVE_WALKDIR_STALL_TIMEOUT_SECS and the high-latency drive-timeout profile, which widen the budget with no code change. Notes were added at list_dir, the scan_dir call site, and get_drive_walkdir_stall_timeout. No behaviour change. Refs rustfs/backlog#1216 Co-Authored-By: heihutu <heihutu@gmail.com> * docs(ecstore): document consumer-peek vs producer-stall coupling In list_path_raw the consumer's peek_timeout is drawn from the same source and same value (walkdir_stall_timeout, default 5s) as the producer-side walk stall budget, but the two measure different things: the producer stall bounds a single drive read, while the consumer peek bounds the gap between two ADJACENT entries arriving from a reader. Because they share a value, the consumer cannot wait meaningfully longer for the next entry than the producer is allowed to spend producing one. Walking a region dense with non-listable internal items can make a HEALTHY drive miss the budget between visible entries; the consumer then declares it stalled and detaches it, dropping a good drive from the merge and capping the "large prefix succeeds" guarantee. Documented, not decoupled: giving the consumer peek an independent, strictly-larger budget would cut these false detaches but equally delays detaching a genuinely dead drive and shifts listing tail-latency semantics, so it wants soak data before changing the default. The comment records the invariant any such follow-up must keep -- consumer peek >= producer stall, never stricter -- so it can never fail a drive before the producer would. No behaviour change. Refs rustfs/backlog#1217 Co-Authored-By: heihutu <heihutu@gmail.com> * fix(io-metrics): add time-based trigger for low-IOPS latency percentiles Percentiles were recomputed only every 128 IOs and seeded to 0, so a low-traffic deployment exported p95/p99 = 0/stale for a long time after startup. Add a 10s wall-clock trigger alongside the count throttle so the first recompute can fire before 128 samples accrue. Hot-path per-op mean update is unchanged. Refs rustfs/backlog#1218 Co-Authored-By: heihutu <heihutu@gmail.com> * test(e2e): cover codec-streaming parity under fault injection and NoSuchKey The codec-streaming compat A/B previously ran only against a healthy 4-disk EC set with successful full GETs: the DiskFaultHarness was constructed but never faulted, the error path was untested, and the range assertion silently compared legacy-vs-legacy (ranges always fall back to the duplex path), overstating what it proved. Add two genuinely-failable scenarios reusing the existing harness and fixtures: - Parity reconstruction A/B: take one data disk offline and re-run the full object matrix on both phases while the EC 2+2 set rebuilds each large object from the surviving shards. Assert codec == legacy byte-for-byte (sha256) and header-for-header, and assert the codec phase served the reconstructed objects with zero duplex-pipe fallback (the reader gate is drive-health-independent, so the codec fast path is really exercised through reconstruction). - NoSuchKey negative path: compare the HTTP status + S3 error code of a missing-key GET across the legacy and codec phases and require them to be identical (404/NoSuchKey), guarding against the codec env perturbing the error path. Also clarify the range-phase comment so it is not misread as codec-range correctness coverage: both sides are served by the same legacy range path, so the assertion only proves ranges keep working and keep falling back to legacy with the gates open. Verified: cargo check/--no-run pass and the test passes locally (1 passed; dup_codec=0 confirms the codec path ran). Refs rustfs/backlog#1219 Co-Authored-By: heihutu <heihutu@gmail.com> * ci(ecstore): exercise native O_DIRECT read path on an ext4 loopback The uring-integration leg ran on the runner's default TMPDIR, which may sit on tmpfs/overlayfs where open(O_DIRECT) fails and the native read_at_direct path silently latches off to the aligned StdBackend fallback. Mount a dedicated ext4 loopback and point TMPDIR at it so the real io_uring dep (bumped git->0.1.0->0.2.0->0.2.1) and the native O_DIRECT read path are actually covered rather than validated only by signature diffing. Refs rustfs/backlog#1220 Co-Authored-By: heihutu <heihutu@gmail.com> --------- Co-authored-by: heihutu <heihutu@gmail.com>
rustfs-io-metrics
· Home · Docs · Issues · Discussions
Overview
rustfs-io-metrics is the metrics and configuration module for RustFS, a distributed object storage system. It provides:
- Cache Configuration: L1/L2 tiered cache configuration management
- Adaptive TTL: Dynamic TTL adjustment based on access frequency
- Metrics Collection: Unified metrics recording and reporting
- Bandwidth Monitoring: Real-time bandwidth observation and analysis
- Performance Metrics: I/O performance metrics collection
- Unified Configuration: Centralized configuration management
- Exporter Boundary: Emit via
metrics, export viarustfs-obs, no Prometheus HTTP endpoint
Features
Cache Configuration
Tiered cache configuration management:
use rustfs_io_metrics::{CacheConfig, CacheConfigError};
// Create configuration
let config = CacheConfig::new();
// Validate configuration
if let Err(e) = config.validate() {
println!("Invalid configuration: {}", e);
}
// Custom configuration
let config = CacheConfig {
max_capacity: 10_000,
default_ttl_seconds: 300,
max_memory_bytes: 100 * 1024 * 1024, // 100 MB
..Default::default()
};
Adaptive TTL
Dynamic TTL adjustment based on access frequency:
use rustfs_io_metrics::{AdaptiveTTL, AdaptiveTTLStats};
use std::time::Duration;
let config = CacheConfig::new().with_ttl_range(60, 300, 3600);
let ttl = AdaptiveTTL::new(config);
// Cold object (few accesses)
let cold_ttl = ttl.calculate_ttl(Duration::from_secs(60), 1, 0.8);
println!("Cold object TTL: {:?}", cold_ttl);
// Hot object (many accesses)
let hot_ttl = ttl.calculate_ttl(Duration::from_secs(60), 100, 0.8);
println!("Hot object TTL: {:?}", hot_ttl);
Access Tracking
Track cache item access patterns:
use rustfs_io_metrics::{AccessTracker, AccessRecord};
use std::time::Duration;
let mut tracker = AccessTracker::new(1000, Duration::from_secs(300));
// Record accesses
tracker.record_access("object-key-1", 1024);
tracker.record_access("object-key-1", 1024);
tracker.record_access("object-key-2", 2048);
// Get access count
let count = tracker.get_access_count("object-key-1");
println!("Access count: {}", count);
// Detect hot/cold
if tracker.is_hot("object-key-1", 1) {
println!("Hot object");
}
// Get top keys
let top_keys = tracker.top_keys(10);
for (key, count) in top_keys {
println!("{}: {} accesses", key, count);
}
Metrics Recording
Unified metrics recording functions:
use rustfs_io_metrics::{
// I/O scheduler metrics
record_io_scheduler_decision,
record_io_strategy_change,
record_io_load_level,
// Cache metrics
record_cache_size,
// Backpressure metrics
record_backpressure_event,
record_backpressure_state,
// Timeout metrics
record_timeout_event,
record_operation_duration,
};
// Record I/O scheduler decision
record_io_scheduler_decision("sequential", "high_priority");
// Record cache size
record_cache_size("L1", 1024, 1);
// Record backpressure event
record_backpressure_event("warning", 0.85);
// Record operation timeout
record_timeout_event("GetObject", Duration::from_secs(30));
Internode Transport Metrics
Internode metrics are recorded by src/internode_metrics.rs. Aggregate metrics
remain unlabeled for compatibility with existing dashboards:
| Metric | Meaning |
|---|---|
rustfs_system_network_internode_sent_bytes_total |
Total internode bytes sent by this node. |
rustfs_system_network_internode_recv_bytes_total |
Total internode bytes received by this node. |
rustfs_system_network_internode_requests_outgoing_total |
Total outgoing internode requests. |
rustfs_system_network_internode_requests_incoming_total |
Total incoming internode requests. |
rustfs_system_network_internode_errors_total |
Total internode errors. |
rustfs_system_network_internode_dial_errors_total |
Failed internode connection attempts. |
rustfs_system_network_internode_dial_avg_time_nanos |
Average internode dial duration. |
Operation-level metrics use the same low-cardinality label set:
| Metric | Labels | Meaning |
|---|---|---|
rustfs_system_network_internode_operation_sent_bytes_total |
operation, backend |
Bytes sent for an internode operation. |
rustfs_system_network_internode_operation_recv_bytes_total |
operation, backend |
Bytes received for an internode operation. |
rustfs_system_network_internode_operation_requests_outgoing_total |
operation, backend |
Outgoing request attempts for an internode operation. |
rustfs_system_network_internode_operation_requests_incoming_total |
operation, backend |
Incoming request attempts for an internode operation. |
rustfs_system_network_internode_operation_errors_total |
operation, backend |
Failed internode operation attempts. |
rustfs_system_network_internode_operation_classified_errors_total |
operation, backend, classification |
Classified internode transport failures. |
rustfs_system_network_internode_operation_retries_total |
operation, backend, classification |
Retry attempts for retryable internode transport failures. |
rustfs_system_network_internode_operation_retry_successes_total |
operation, backend, classification |
Successful recoveries after retryable internode transport failures. |
rustfs_system_storage_erasure_write_quorum_failures_total |
stage, dominant_error |
Erasure write quorum failures grouped by failure stage and dominant error class. |
Current operation values are read_file_stream, put_file_stream,
walk_dir, grpc_read_all, and grpc_write_all. Current backend values are
tcp-http for the InternodeDataTransport TCP/HTTP path and grpc for the
remaining gRPC byte paths. The compatibility wrapper uses unknown only for
callers that have not been classified yet.
Success/failure is intentionally not a high-cardinality label today. Failures
are represented by rustfs_system_network_internode_operation_errors_total;
successful completions are not emitted as a dedicated result-labeled metric.
Adding completion/result labels is a follow-up once stream completion semantics
are defined consistently for request setup, body transfer, and shutdown.
Current low-cardinality classification values come from the TCP/HTTP internode
path and include:
connect_timeoutconnection_refuseddns_resolution_failedconnection_resetbody_stream_abortedhttp_429http_502http_503http_504http_status_otherunknown
scripts/run_internode_transport_baseline.sh --metrics-url ... records metric
deltas with operation and backend columns, so the TCP baseline can attribute
bytes and request/error counts to tcp-http transport operations.
Unified Configuration
Centralized configuration management:
use rustfs_io_metrics::{
IoConfig, CacheSettings, IoSchedulerSettings,
BackpressureSettings, TimeoutSettings,
};
let config = IoConfig::new()
.with_cache(CacheSettings::new()
.with_max_capacity(10_000)
.with_ttl(std::time::Duration::from_secs(300)))
.with_scheduler(IoSchedulerSettings::new()
.with_max_concurrent_reads(64))
.with_backpressure(BackpressureSettings::new())
.with_timeout(TimeoutSettings::new());
// Access configuration
println!("Cache capacity: {}", config.cache.max_capacity);
println!("Max concurrent reads: {}", config.scheduler.max_concurrent_reads);
Module Structure
rustfs-io-metrics/
├── src/
│ ├── lib.rs # Module entry
│ ├── cache_config.rs # Cache configuration
│ ├── adaptive_ttl.rs # Adaptive TTL
│ ├── config.rs # Unified configuration
│ ├── io_metrics.rs # I/O metrics
│ ├── backpressure_metrics.rs # Backpressure metrics
│ ├── deadlock_metrics.rs # Deadlock metrics
│ ├── lock_metrics.rs # Lock metrics
│ ├── timeout_metrics.rs # Timeout metrics
│ ├── internode_metrics.rs # Internode transport metrics
│ ├── bandwidth.rs # Bandwidth monitoring
│ ├── global_metrics.rs # Global metrics
│ └── performance.rs # Performance metrics
└── Cargo.toml
Testing
# Run all tests
cargo test --package rustfs-io-metrics
# Run specific tests
cargo test --package rustfs-io-metrics --lib adaptive_ttl
# Run benchmarks
cargo bench --package rustfs-io-metrics --bench metrics_pipeline
Documentation
This crate records metrics through the Rust metrics crate and leaves
exporting to rustfs-obs or the application-level observability pipeline. It
does not expose Prometheus-compatible HTTP endpoints such as
/rustfs/v2/metrics/cluster or /rustfs/v2/metrics/node.
API documentation can be generated locally:
cargo doc --package rustfs-io-metrics --no-deps --open
Useful source references:
Related Modules
- rustfs-io-core: Core I/O scheduling
- rustfs: Main storage service
License
Apache License 2.0