mirror of
https://github.com/rustfs/rustfs.git
synced 2026-08-02 11:29:17 +00:00
Zhengchao An
e2257325a2
peer_rest_recovery_probe_logs_keep_request_id_span_context failed ~10% of `cargo test -p rustfs-ecstore --lib -- cluster::rpc::` runs with left: "request-span", right: "recovery-monitor". The recovery-monitor info_span! was evaluating to Span::none(), so the probe's log line landed under the caller's span. tracing caches each callsite's Interest in process-global state, and the first thread to reach a callsite fixes that value. While at most one dispatcher is registered, tracing-core takes a fast path that derives the interest from the registering thread's own subscriber, and registration is once-only (CAS). Under libtest a sibling test reaches recovery_monitor_span via mark_offline_and_spawn_recovery from a thread with no subscriber, so the interest is derived from NoSubscriber and cached as Interest::never() for the whole process. Add pin_callsite_interest_for_test(): registering a second, inert dispatcher rebuilds every registered callsite's interest against the live dispatcher set (repairing a poisoned value) and keeps tracing-core off the single-dispatcher fast path (preventing new ones). This also covers the production marked_suspect / recovery_monitor_started event callsites that remote_disk_network_error_starts_recovery_monitor_with_request_context asserts on. rename_data_response_accepts_legacy_json_without_decode_error is a separate root cause: it snapshots the process-global internode metrics and asserts the decode-error counter did not move, which siblings that record decode errors (or reset the counters) invalidate. Put the 11 tests that observe those counters in one #[serial(internode_metrics)] group. Both races are impossible under nextest, which runs each test in its own process, so neither test belongs in the ecstore-serial-flaky test-group (that serializes across process boundaries) nor in the ci-profile quarantine (they never redden CI). Verified: cluster::rpc:: subset 0/30 failures under libtest (was 3/30); target test paired with its poisoner 0/30 (was 4/20); 5/5 clean under nextest at 179/179.
RustFS ECStore - Erasure Coding Storage
High-performance erasure coding storage engine for RustFS distributed object storage
📖 Documentation
· 🐛 Bug Reports
· 💬 Discussions
📖 Overview
RustFS ECStore provides erasure coding storage capabilities for the RustFS distributed object storage system. For the complete RustFS experience, please visit the main RustFS repository.
✨ Features
- Reed-Solomon erasure coding implementation
- Configurable redundancy levels (N+K schemes)
- Automatic data healing and reconstruction
- Multi-drive support with intelligent placement
- Parallel encoding/decoding for performance
- Efficient disk space utilization
📚 Documentation
For comprehensive documentation, examples, and usage guides, please visit the main RustFS repository.
📄 License
This project is licensed under the Apache License 2.0 - see the LICENSE file for details.
Copyright 2024 RustFS Team
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
RustFS is a trademark of RustFS, Inc.
All other trademarks are the property of their respective owners.
Made with ❤️ by the RustFS Storage Team