mirror of
https://github.com/rustfs/rustfs.git
synced 2026-07-28 09:08:58 +00:00
weisd
f9475e10dc
* Preserve multipart replication recovery state Multipart uploads previously only scheduled replication after completion, leaving no persisted pending state for scanner recovery if the initial async work was lost. Persist the same pending replication metadata during multipart initialization and let completion evaluate the object metadata that was actually stored. The scanner heal path also treated ordinary pending objects as delete-replication candidates. Restrict that path to delete markers and version purge state so pending objects remain eligible for object replication heal. Constraint: Bucket replication recovery depends on persisted object metadata after the async queue is unavailable. Rejected: Rely only on immediate completion-time scheduling | it cannot recover after process restart or worker loss. Confidence: high Scope-risk: moderate Directive: Keep multipart upload initialization aligned with single PUT replication metadata semantics. Tested: cargo fmt --all --check Tested: cargo clippy --workspace --all-features --all-targets -- -D warnings Tested: LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 make pre-commit Tested: Runtime replication outage check confirmed multipart xl.meta stores PENDING status and timestamp. * fix(replication): preserve version purge scanner state Role-derived replication configs need target-scoped status strings before scanner heal can build per-target purge status. The duplicated replication-status assignment left version purge status unset, so scanner recovery could lose the target-level purge state. Constraint: Scanner heal derives per-target purge decisions from version_purge_status_internal. Rejected: Leave the duplicate as a harmless cleanup | it changes recovery behavior for role-only configs with version purge state. Confidence: high Scope-risk: narrow Directive: Keep role-derived replication and version purge internal status mapping symmetric. Tested: cargo fmt --all --check Tested: cargo test -p rustfs-ecstore heal -- --nocapture --------- Co-authored-by: wly <wlywly0735@126.com> Co-authored-by: houseme <housemecn@gmail.com>
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