mirror of
https://github.com/rustfs/rustfs.git
synced 2026-08-09 06:39:25 +00:00
houseme
c2e23411e8
* fix(filemeta): classify xl.meta CRC mismatch as FileCorrupt so heal repairs it A failed CRC means the metadata bytes on disk are not the bytes that were written — bitrot. Raising it as Error::other() surfaces a generic Io error, which should_heal_object_on_disk does not recognise as heal-worthy: the drive is skipped, disks_to_heal_count stays 0, heal_object returns ok, and the corrupted xl.meta is never rewritten — while the scanner re-submits the same no-op heal every deep-scan cycle. An explicit admin deep heal fails the same way, so no heal path repairs metadata bitrot, and every one of them reports success. check_xl2_v1 already classifies a short or wrong-magic header as FileCorrupt for exactly this reason (#5716); this completes the pattern for the two CRC sites. The existing From<rustfs_filemeta::Error> for DiskError conversion maps the variant to DiskError::FileCorrupt, which the heal path already handles. The previously silent is_indexed_meta site now logs the mismatch (structured event shape) like unmarshal_msg does. Regression test: corrupt one byte of a marshalled FileMeta and assert unmarshal_msg reports FileCorrupt; fails on the previous code, which returned Io(Other). Verified end-to-end on a 3-node / 12-drive EC:4 cluster: xl.meta corrupted on 2 of 12 drives via dd, admin deep heal — before this change the heal returns ok with the corruption intact and the scanner loops forever; with it, both copies are rewritten (decode-identical to the healthy quorum), the object reads back byte-correct, and a follow-up heal reports all twelve drives clean. * test(filemeta): cover crc heal classification Add regression coverage for the indexed xl.meta CRC path and the metadata-heal decision that consumes FileCorrupt. Co-Authored-By: heihutu <heihutu@gmail.com> --------- Co-authored-by: terem42 <9478806+terem42@users.noreply.github.com> Co-authored-by: heihutu <heihutu@gmail.com> Co-authored-by: zhi22915 <qiuzgang@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