mirror of
https://github.com/rustfs/rustfs.git
synced 2026-09-01 09:48:20 +00:00
Zhengchao An
75cd3885f3
TierAzure.storage_class and .sp_auth round-trip faithfully through the admin API and on-disk config (ExternalTierAzure encode/decode in tier.rs), so an operator can configure them, read them back via ListTier, and never learn they do nothing. They are dropped only at the WarmBackendAzure construction boundary: the Azure warm backend goes through the same S3-compatible TransitionClient as every other provider and has no Azure Blob-native client or Azure AD dependency (confirmed: no azure_* crate anywhere in the workspace), so neither field can actually be honored today. MinIO's reference implementation (cmd/warm-backend-azure.go) treats both as first-class: storage_class sets the blob access tier on every PUT, and sp_auth is a full alternative to access/secret-key auth via azidentity, mutually exclusive with it. Rather than the larger, riskier options (add a native Azure SDK dependency and a parallel non-S3 client path, or break the persisted config format by removing the fields), this closes the silent-failure gap with the minimal safe fix: TierConfigMgr::add now rejects an Azure tier config with either field set, before backend construction, returning ERR_TIER_INVALID_CONFIG with an explicit message instead of accepting and ignoring. The fields stay in the config type (no format break); already-persisted tiers with these fields set are grandfathered in un-rejected (edit does not touch sp_auth or storage_class either). Full support remains a larger follow-up if ever prioritized. Also removes TierAzure::is_sp_enabled(), which had zero callers repo-wide (backlog#2055 flagged this) and would have been misleading dead weight once this decision was made — reusing it for the new gate would also have been wrong, since it requires *all three* sp_auth fields non-empty (&&), while the gate must reject on *any* one being set. Refs rustfs/backlog#2055 (cherry picked from commit 8d148c4e9b2507a1c5075e3d9513adb8b5851ef5)
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