mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-10-15 18:48:32 +02:00
update
1 parent
0ded1de960
commit
20780af5b5
3 files changed
+14
-6
No files matched your search
+10
-3
@@ -60,7 +60,7 @@ To be sure, you can look at the function defined in the files `weed/s3api/s3api_
|
||||
* GetObject / HeadObject (returns x-amz-meta-* headers)
|
||||
* CopyObject (with metadata directive)
|
||||
|
||||
// Server-Side Encryption (NEW)
|
||||
// Server-Side Encryption
|
||||
* PutObject (with SSE-KMS, SSE-C, SSE-S3)
|
||||
* GetObject (with automatic decryption)
|
||||
* HeadObject (with encryption metadata)
|
||||
@@ -68,7 +68,7 @@ To be sure, you can look at the function defined in the files `weed/s3api/s3api_
|
||||
* Multipart uploads with encryption
|
||||
* Bucket default encryption
|
||||
|
||||
// Conditional Operations (NEW)
|
||||
// Conditional Operations
|
||||
* All object operations support conditional headers:
|
||||
- If-Match
|
||||
- If-None-Match
|
||||
@@ -114,10 +114,17 @@ To be sure, you can look at the function defined in the files `weed/s3api/s3api_
|
||||
* GetObjectLegalHold
|
||||
* PutObjectLegalHold
|
||||
* BypassGovernanceRetention (via x-amz-bypass-governance-retention header)
|
||||
|
||||
// Bucket Policies
|
||||
* PutBucketPolicy
|
||||
* GetBucketPolicy
|
||||
* DeleteBucketPolicy
|
||||
* Supported Conditions:
|
||||
- s3:ExistingObjectTag
|
||||
```
|
||||
|
||||
Not included:
|
||||
* Policy
|
||||
|
||||
|
||||
# User Metadata (Custom Attributes)
|
||||
|
||||
|
||||
@@ -12,6 +12,7 @@ However, data can become warm or cold after a period of time. They are accessed
|
||||
* **Memory Efficiency** Minimum memory usage. The volume server does not load index data into memory.
|
||||
* **Fast Startup** Startup time is much shorter by skip loading index data into memory.
|
||||
* **Rack-Aware** data placement to minimize impact of volume server and rack failures.
|
||||
* **Disk-Aware** data placement to ensure shards are distributed across different physical disks within a server, protecting against individual disk failures in JBOD setups.
|
||||
* **Flexible Server Layout** There are no minimum number of servers, or racks. SeaweedFS manages erasure coding data via volumes. If the number of servers is less than 4, EC can protect against hard drive failures. If the number of servers is greater than or equal to 4, EC can protect against server failures. If the number of racks is greater than 4, EC can protect against rack failures.
|
||||
|
||||
The downside:
|
||||
@@ -21,9 +22,8 @@ The downside:
|
||||
* Compaction would require converting back to normal volumes first.
|
||||
|
||||
Side Note:
|
||||
* The 10+4 can be easily adjusted via `DataShardsCount` and `ParityShardsCount` in
|
||||
https://github.com/seaweedfs/seaweedfs/blob/master/weed/storage/erasure_coding/ec_encoder.go#L17
|
||||
* If you are considering these enterprise-level customizations, please consider supporting SeaweedFS first.
|
||||
* The 10+4 configuration is the default for the open source version.
|
||||
* The SeaweedFS Enterprise version supports custom EC ratios.
|
||||
|
||||
## Architecture
|
||||
SeaweedFS implemented 10.4 Reed-Solomon Erasure Coding (EC). The large volumes are split into chunks of 1GB, and every 10 data chunks are also encoded into 4 parity chunks. So a 30 GB data volume will be encoded into 14 EC shards, each shard is of size 3 GB and has 3 EC blocks.
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
|
||||
|
||||
For an overview of SeaweedFS security architecture and communication layers, see [[Security-Overview]].
|
||||
For FIPS 140-3 compliance information, see [[Cryptography-and-FIPS-Compliance]].
|
||||
|
||||
The first step is generating `security.toml` file via `weed scaffold -config=security`:
|
||||
|
||||
|
||||
Reference in new issue
Block a user