不重造 S3 轮子：PowerFS 如何把 RustFS 变成自己的 S3 服务面

一套自研分布式文件系统，要在不改 S3 语义代码的前提下，把 RustFS 的 S3 API / IAM / 控制台完整复用起来，同时让对象数据继续落在自己的 needle 存储上。本文记录了这次集成的方案选型、注入点设计、元数据与数据面映射，以及在 EC、压缩、Multipart 读路径上踩过的几个"会坏数据"的坑。

一、为什么不再自己写 S3

PowerFS 最初有一套自研的 S3 实现（powerfs-s3 + master 内置 handler）。它够用，但只够用到"PUT/GET/LIST 能跑通"为止。

一旦用户真的拿 AWS CLI、SDK、S3 Browser、Databend、Spark、Velero 这些工具接上来，问题就暴露了：

签名与鉴权：SigV4 的 canonical request、chunked signature、presigned URL，每一处都是协议细节；
语义面 ：条件请求（If-Match / If-None-Match）、Multipart、版本化、删除标记、对象锁、Tagging、Storage Class；
管理面：IAM/STS、Bucket Policy、生命周期、事件通知、审计、Web 控制台；
兼容性：各种客户端对错误码、响应头、XML 命名空间的"事实标准"要求。

这些不是写几个 handler 的事，而是一整个协议栈。继续自研，等于用一个小团队去追一个成熟项目的多年积累。

所以方向确定：S3 协议面和管理面交给 RustFS，PowerFS 只负责自己最擅长的 needle 数据存储与元数据一致性。

RustFS 是 Rust 编写、Apache-2.0、与 MinIO 语义高度兼容的 S3 服务，自带 S3 API、IAM、策略、控制台、生命周期、通知、审计。它已经把"协议"这件事做完了，我们需要的只是一个能把自己的存储接进去的口子。

二、先划边界：谁负责什么

集成后的职责划分非常清晰：

复制代码

S3 客户端
   │ HTTPS (SigV4)
   ▼
[rustfs-server]        S3 API / Admin API / Console / IAM / 策略 / 生命周期 / 通知
   │ rustfs-storage-api 存储契约
   ▼
[powerfs-rustfs-store] 适配层：契约 → PowerFS API、错误码映射、能力快照
   │ gRPC（元数据）           │ TLV（数据）
   ▼                          ▼
[powerfs-filer]           [powerfs-volume]
Raft 强一致对象元数据      needle 持久化、卷分配、复制/EC

一句话总结：

RustFS：协议解析、鉴权、S3 语义、管理面；
适配层：把存储契约翻译成 PowerFS 的 Filer/Volume 调用；
Filer：bucket / object / multipart 元数据的唯一权威，Raft 线性一致；
Volume：对象正文以 needle 形式落盘，卷复制与 EC 由 PowerFS 既有机制负责。

这样做有一个隐含但很重要的好处：同一份数据可以同时被 POSIX（FUSE）和 S3 访问。S3 写进去的对象，在 FUSE 挂载点下就是一个普通文件；FUSE 写的文件，也能被 S3 读出来------因为它们共享同一套 Filer 元数据和 Volume needle。

三、四种方案，三次否定

真正开始改代码之前，我们先做了方案评估。结论先放这里：最终选择的是"在 ECStore 内部做委托"，而不是最初设想的"替换 AppContext"。

方案 A：把 `Arc<ECStore>` 换成 `Arc<dyn StorageEngine>`

看起来最干净：RustFS 的 App 上下文持有的是具体类型 Arc<ECStore>，只要把它抽象成 trait，注入 PowerFS 实现即可。

实测结果很直接：

引用 AppContext::object_store() 的生产文件 33 个；
Arc<ECStore> 出现在 118 个文件；
storage 层调用的 ECStore 方法 36 个。

这不是"改一个类型"，而是"重写半个项目"。方案 A 否决。

方案 B：把 PowerFS 伪装成 RustFS 的一块磁盘

需要完整复刻 xl.meta、版本目录、bitrot 校验、remote-disk 语义。更糟的是，PowerFS 自己已经有卷复制/EC，再叠加一层 RustFS 的冗余，容量和维护成本都翻倍。否决。

方案 C：做一个 S3 代理

请求先进 RustFS，再转发给 PowerFS 的 S3。双跳、双套鉴权、双套元数据，版本化和生命周期依然无法统一。而且 RustFS 里的 "gateway" 指的是 S3 协议栈，不是存储网关，代理并没有现成入口。否决。

方案 D：回到自研

等于放弃前面所有的语义与管理面能力。否决。

最终方案 A′：ECStore 内部委托

不碰 AppContext，不碰 rustfs/src/app/**，只在 crates/ecstore 里加一个"外部后端"缝：

新增 store::external，定义 StorageDriver 与 ExternalBackend 契约；
在 BucketOperations / ObjectOperations / MultipartOperations 等 trait 实现的入口判断：已安装外部后端就委托，否则走原路径；
IamSys<ObjectStore>、Admin、控制台、生命周期、通知全部零改动。

最终 fork 侧只改了 5 个左右的源码文件，满足"补丁 ≤25 文件、不改 S3 语义"的门槛，也保证了后续还能跟着上游 rebase。

四、注入缝：一个契约 + 一次进程级安装

缝的核心是"按桶路由"：每个操作先看这个 bucket 归谁管。

复制代码

// rustfs/crates/ecstore/src/store/external.rs（示意）
pub trait ExternalBackend: Send + Sync {
    fn make_bucket(&self, bucket: &str, opts: &MakeBucketOptions) -> Result<()>;
    fn get_object_info(&self, bucket: &str, object: &str, opts: &GetObjectInfoOpts)
        -> Result<ObjectInfo>;
    fn get_object_reader(&self, bucket: &str, object: &str, range: Option<HTTPRangeSpec>)
        -> Result<GetObjectReader>;
    fn put_object(&self, bucket: &str, object: &str, data: &mut Reader,
        opts: &PutObjReader) -> Result<ObjectInfo>;
    // ... bucket / multipart / list 同理
}

安装发生在进程启动阶段，只有一个入口：

复制代码

// 启动接线（示意）
if std::env::var("RUSTFS_STORAGE_DRIVER").as_deref() == Ok("powerfs") {
    let store = PowerFsStore::new(StoreConfig::from_env()?)?;
    install_external_backend(Arc::new(store));
    // 构造失败直接退出，绝不静默回退 native
}

这里有两个关键设计。

1. 系统桶必须留在 native

RustFS 的 .rustfs.sys / .minio.sys 里放着 IAM、config/config.json、scanner 状态，启动阶段就会被读写。如果把这些桶也委托给 PowerFS，外部存储里没有对应数据，IAM 初始化会卡死，S3 端口一直返回：

复制代码

503 Service Unavailable
x-rustfs-readiness-pending: iam

所以委托点统一走 backend_for_bucket()：

复制代码

// 系统桶不委托，用户桶才走外部后端
fn backend_for_bucket(&self, bucket: &str) -> Option<&Arc<dyn ExternalBackend>> {
    if is_control_plane_bucket(bucket) {
        return None;
    }
    self.external.as_ref()
}

"控制面留在本地、数据面走外部"是这次集成里最重要的一个边界。少了这条判断，服务根本起不来。

2. 漏一个固有方法，就会出现"能写不能删"

只改 trait 方法是不够的。RustFS 的 S3 PUT / DELETE 实际会走一些固有方法：

S3 PUT → put_object_with_old_current_size；
S3 DELETE → delete_object_with_tier_delete_journal_and_guards；
批量删除 → delete_objects_with_tier_delete_journal_and_accounting；
删除前查询 → get_object_info_for_delete。

这些方法如果不一起委托，就会出现"对象写进去了，但 DELETE 报桶不存在"这种看似灵异、实则是走了本地盘的问题。判断标准很简单：写路径和它的前置查询必须在同一个后端。

五、元数据：8 个 RPC 把 S3 语义压到 Filer

PowerFS 的 master 已经把文件系统元数据全部迁到了 Filer（master 的 get_entry 等 RPC 现在直接返回 UNIMPLEMENTED）。所以适配层不复用旧的目录树客户端，而是直接调 Filer 新增的 8 个 S3 元数据 RPC：

复制代码

rpc EnsureBucketRoot(EnsureBucketRootRequest) returns (EnsureBucketRootResponse);
rpc GetBucketRoot(GetBucketRootRequest) returns (GetBucketRootResponse);
rpc ListBucketRoots(ListBucketRootsRequest) returns (ListBucketRootsResponse);
rpc DeleteBucketRoot(DeleteBucketRootRequest) returns (DeleteBucketRootResponse);
rpc PutObjectMeta(PutObjectMetaRequest) returns (PutObjectMetaResponse);
rpc GetObjectMeta(GetObjectMetaRequest) returns (GetObjectMetaResponse);
rpc DeleteObjectMeta(DeleteObjectMetaRequest) returns (DeleteObjectMetaResponse);
rpc ListObjectMetas(ListObjectMetasRequest) returns (ListObjectMetasResponse);

命名空间映射

Bucket = Filer inode 0 下的一个同名目录；
Object = 该目录下的一个扁平条目，name 就是完整 S3 key（key 里的 / 不创建中间目录）；
对象数据指针放 chunks；
S3 元数据（etag、content-type、用户元数据、tags）放 extended 的 s3.* 键。

扁平命名空间的好处是：S3 的 prefix/delimiter 列举不需要真的建目录树，直接在 Filer 的有序索引上做前缀扫描即可。

覆盖写必须是一次原子 RPC

S3 的 PUT 覆盖同一个 key 是常态。如果实现成"先删旧、再建新"，中间就会有一个 404 窗口，并发读会看到对象消失。

Filer 的 PutObjectMeta 对已存在的 key 做原地替换（size / chunks / extended 一起换），所以覆盖写是单次原子提交：

复制代码

// 适配层：先写数据，再一次性提交元数据
let (volume_id, file_key) = assign_volume().await?;
write_needle(volume_id, file_key, body).await?;
put_object_meta(bucket, key, size, chunks, extended).await?;

顺序不能反：数据先落盘并可见，元数据后提交。未提交的 needle 属于孤儿数据，由后续 GC 回收；反过来则会出现"元数据指向不存在的数据"，那才是真正的读取错误。

Leader 不在本机：重试策略比 RPC 本身更重要

Filer 不做服务端转发。非 leader 收到写请求会返回 not_leader。更麻烦的是读类 RPC ：follower 的 apply 可能滞后，于是会返回一个"看起来很正常"的 bucket not found / object not found，而不是 not_leader。

适配层的处理是把"未找到"也当成可重试信号：

复制代码

// 每个端点各试一次，直到命中 leader
for endpoint in endpoints {
    match client.get_object_meta(bucket, key).await {
        Ok(meta) => { leader_hint.store(endpoint); return Ok(meta); }
        Err(status) if is_retryable(&status) => continue,  // not_leader / not found / timeout
        Err(status) => return Err(map_status(status)),
    }
}

写路径上还加了写后可见性校验：提交后回到所有端点确认 size / chunks / extended 已经一致，不一致就幂等重发。删除同理，要确认对象在所有端点都不可见，否则紧接着的删桶检查会因为"桶非空"而失败。

Filer 侧也做了一处关键修正：桶是否存在的权威，是 inode 0 下已 apply 的 Raft 目录项 ，而不是本地 root_inodes 缓存。那个缓存不随 Raft 复制，跨节点删桶后会残留，导致 HeadBucket 谎报存在。

一个差点被"静默成功"吞掉的 bug

P2c 验收时出现过 10%--30% 概率的诡异现象：

GET 偶尔缺 ContentType，ContentLength=0；
GetObjectTagging 返回空；
s3-tests teardown 偶发 BucketNotEmpty。

根因不是 Raft，而是适配层的重试分类写错了：mutation_outcome 把非重试类的业务失败 也当成了成功。Filer 在异步持久化模式下，propose 返回即视为返回，于是元数据永久停留在"只创建、未更新"的状态------对象存在，但 size=0、extended 为空。

修复原则只有一句话：任何业务失败都不能静默接受。要么跨端点重试，要么明确报错；写成功之后还必须做一次读校验确认可见。

这件事之后，我们给适配层定了一条硬规则：元数据写入的成功标准是"读得到"，不是"RPC 没报错"。

六、数据面：needle、2MB 分块与 Range

对象正文最终写到 Volume Server 的 needle 上。这里有两个容易踩的点。

1. `grpc_port` 其实是数据面端口

master 心跳返回的 DataNodeInfo.grpc_port，注释里写得很清楚：这个字段承载的是 powerfs-net 数据面端口，不是 tonic gRPC 端口。

如果按名字直觉去拨 tonic VolumeClientPool，会直接被 TLV 握手拒绝。正确做法是走 powerfs_net::TlvVolumeClient。这也是我们把 TlvVolumeClient 从 filer 迁到 powerfs-net 的原因------它属于协议层，Filer 和 S3 适配层都应该共用同一份实现。

2. TLV 单帧上限 2MB，大对象必须分块

单个 TLV DATA 帧上限是 MAX_DATA_SIZE = 2MB。所以写路径按 2MB 切分：

复制代码

object body ──► 2MB slice ──► assign_volume ──► write_needle ──► chunks[]
                 (每块独立分配卷)

chunks[] 按 offset 升序登记；
ETag 仍然是整个对象正文的 MD5（S3 单段对象的定义）；
0 字节对象不写 needle，chunks=[]，读取返回空 body。

读路径则遍历 chunks[]，只拉取与请求 Range 相交的块，按边界裁剪后拼接。跨块 Range、末尾跨界、单字节 Range 都需要单独测------这类边界是最容易"看起来对、实际差几个字节"的地方。

七、Multipart：隐藏桶、零拷贝完成、重放幂等

Multipart 是 S3 语义里最复杂的一块，但适配层刻意没有新增 Filer RPC，而是复用了对象元数据：

会话与分块放在内部隐藏桶 .powerfs.multipart；
键为 <bucket>/<upload_id>/__session 与 <bucket>/<upload_id>/{part:05}；
list_buckets 过滤掉这个桶。

几个语义细节必须和 native 对齐：

场景	行为
非末块 < 5MiB	`EntityTooSmall`
分块 ETag 不匹配	`InvalidPart`
会话不存在 / 归属不符	`InvalidUploadID`
完成 ETag	`md5(concat(hex_decode(part etags)))-count`
重放 Complete	按对象上的 `mpu.upload-id` + `mpu.part-etags` 逐块比对，命中则返回既有对象

完成路径是零拷贝拼接：不重写数据，只把各分块的 chunk 偏移整体平移后登记到对象元数据上，提交成功后才删除分块元数据与会话。这样 5GiB 的分段上传在 Complete 阶段是元数据操作，不产生等量数据拷贝。

跨卷复用 needle_id：一个真实的坏数据事故

test_multipart_upload_resend_part 在 powerfs 后端间歇失败，native 稳定通过。复现后看到 30MiB 对象在 9--30MiB 区间被别人的数据覆盖。

根因和 S3 无关，在存储层：

Master 的 file_key 是按卷独立计数器（步长 1MiB）；
同一个数值会在不同卷上分别分配给不相关的文件；
scrubber 的 replicate_inode 直接把源 chunk.needle_id 复用到目标卷；
如果目标卷上这个 key 已被占用，就直接覆写对方数据。

修复是让 scrubber 复制时向 Master 申请目标卷的新 key （MsgType::AssignNeedle），而不是复用源 key。同批还加固了：

只有该 shard 的 Raft leader 才执行复制（非 leader 的 propose_ff 会静默丢弃，新 key 方案下会泄漏孤儿 needle）；
复制失败时清理已写但未提交的副本；
GC 回收列表纳入 replica_chunks；
scrubber 的 volume_id → addr 解析改用 Master 拓扑，而不是只含反亲和子集的 Zone 视图。

修复后重传探针 30MiB × 5 种模式、102 次上传逐字节比对，0 错乱。

这类 bug 提醒我们：S3 语义正确不等于数据正确。 协议层测试全绿，也可能被底层存储的 key 分配策略打穿。

八、EC 与压缩：读路径是数据正确性的最后一道闸

1. EC 转换后，S3 读出了"半截好数据"

scrubber 把对象转成 EC(4+2) 之后，30MiB 对象的 S3 GET 出现：

前 4MiB 完全正确；
之后到文件尾全部错乱；
HEAD Content-Length 和 ETag 都正常。

这是最危险的一类问题：元数据看起来全对，数据是坏的，且是持久性的。

根因有两个：

update_to_ec 把 info.chunks 整体替换成 EC 分片列表。数据分片 offset = group_start + i * shard_size，校验分片 offset = group_start（与数据分片 0 重叠）；
S3 读路径按"平铺 chunk"顺序拼接，既不知道对象是 EC，也会把校验分片的 offset 当数据读。

修复分三层：

元数据暴露 ：filer.proto 的 Entry 增加 EcLayout（data / parity / shard_size），只以 reliability_state == EC 为权威。状态不一致、chunks 为空或不是 data+parity 的整数倍时，打 warn 并返回 None，退回平铺读而不是猜布局。

读路径分叉 ：ec.rs 按 group 读取，分片身份只按 group 内索引判定 （i < data 是数据分片），绝不用 offset 判断------校验分片的 offset 天然和数据分片 0 重叠。

降级与失败语义：

快路径：只读与请求区间相交的数据分片，逐片 CRC32 校验；
降级路径：任一数据分片失败/长度不符/CRC 不符，整组读满 data+parity，用 Reed-Solomon 重建；
不可恢复：可用分片 < data 时返回 500，不返回任何部分数据。

验证覆盖了 1MiB / 4MiB+1B / 8MiB / 30MiB / 100MiB 的尺寸矩阵、跨 shard/跨 group/后缀/末字节的 Range 矩阵，以及真实停容器的降级读：停 1--2 个数据分片可重建，停 3 个返回 500 且无错数据。

2. EC 与 Multipart 的隐藏冲突

EC 开启后又发现两个 multipart 用例失败。原因是 scrubber 把 .powerfs.multipart 的分块也转成了 EC，而 complete_multipart_upload 是按原偏移拼接分块的------拼出来的对象自然错乱。

解决方式是给分块打豁免标记：

gateway 写 MPU 分块时在 extended 里写 powerfs.ec-exempt；
filer 的 list_pending_ec 跳过带该键的 inode；
complete_multipart_upload 兜底：分块仍带 ec_layout 就直接报错，绝不静默拼坏。

修复后，EC 开 / 关两种配置下，s3-tests 的失败清单逐条相同。

3. P7：zstd 压缩与"压缩标记不能串"

P7 给副本 chunk 加了 zstd 压缩：scrubber 后台把 Replicated 的平铺 chunk 压成 zstd，元数据里记录算法 tag。

协议上，FileChunk 增加 compression 字段：

复制代码

// P7: 压缩算法 tag（0=None, 1=Zstd）。size 为逻辑（解压后）长度，
// crc32 为存储（压缩后）字节 CRC。缺省 0 = 未压缩，兼容旧数据。
uint32 compression = 7;

S3 读路径必须先解压、再校验长度、最后裁剪 Range：

复制代码

let algo = CompressionAlgo::from_tag(chunk.compression as u8)
    .unwrap_or(CompressionAlgo::None);

let data = if algo.is_compressed() {
    let plain = decompress(algo, &needle)?;
    if plain.len() as u64 != chunk.size {
        return Err(Error::other("decompressed length mismatch"));
    }
    plain
} else {
    needle
};

三条约束：

解压失败绝不回退为"原样返回压缩字节"，宁可 5xx；
EC 与压缩互斥：EC 分片永远不压缩，读路径遇到"EC 对象 + 压缩 chunk"直接判元数据不自洽并拒绝，避免把压缩字节喂给 RS 解码；
压缩比不足就不压：原始/压缩 ≥ 1.05 才值得换存储，随机数据压完反而变大。

还修了一个很隐蔽的状态机 bug：陈旧的 chunk-sync 会把已压缩 inode 重置回未压缩 。原因是 update_inode_size_chunks 在数据变更时复位 reliability，但没有同步复位压缩状态。现在的规则是：chunks 变化且原状态为 Replicated | EC 时，状态回到 PendingReplicated，同时清空 replica_chunks 和压缩标记------任何布局变更都必须让旧标记失效。

九、验证：用 native 做对照，而不是只盯通过数

这次集成最重要的测试方法，是同一组用例、两个后端、逐条对照失败清单：

阶段	结果
native 基线（T0.3）	56 例：49 通过 / 7 失败（均为上游未实现或测试配置）
P1c 基础对象组	powerfs 19/19，native 19/19
P2a 大对象	20/20（含 3/4/8/16MB、跨块 Range、单字节 Range）
P2c 条件请求 + Range	20/20，重跑两次稳定
P2d Multipart（`-k multipart`）	powerfs 32 通过 / 30 失败，native 42 通过 / 20 失败；差异 10 例全部落在已声明非目标（SSE-C、校验和、版本化、对象锁）
P6 EC 开 / 关对照	`-k multipart` 与条件/Range 组失败清单逐条相同
P7 压缩	尺寸矩阵与 Range 矩阵逐字节一致；EC 分片压缩标记被正确拒绝

失败清单一致，比"通过率更高"更有意义。它证明我们没有引入新的语义偏差，而不是碰巧绕过了某些用例。

性能上，100MiB 顺序 GET：

模式	TTFB	总耗时	吞吐
EC 关闭（平铺 chunk）	493.9 ms	546.7 ms	182.9 MiB/s
EC 开启（1MiB shard 快路径）	645.6 ms	692.4 ms	144.4 MiB/s

EC 读约为平铺的 79%，主要开销是逐分片 RPC 和 CRC32 校验。这个代价换来的是容量效率和降级读能力，属于可接受范围；后续可以通过合并相邻分片 RPC、加分片级缓存继续优化。

十、怎么跑起来

适配器刻意放在主 workspace 之外，普通部署不需要拉 rustfs 子模块。需要 S3 能力时：

复制代码

# rustfs 使用 edition 2024，需要 Rust 1.99+
rustup toolchain install 1.99
git submodule update --init rustfs
cargo +1.99 build --manifest-path powerfs-rustfs-store/Cargo.toml --release

启动 RustFS 时打开 powerfs 驱动：

复制代码

RUSTFS_STORAGE_DRIVER=powerfs \
POWERFS_MASTER_ENDPOINTS=master-1:9333,master-2:9333 \
POWERFS_FILER_ENDPOINTS=filer-1:8889,filer-2:8889 \
POWERFS_S3_COLLECTION=default \
POWERFS_S3_REPLICATION=001 \
  rustfs /tmp/rustfs-powerfs-control

环境变量	必填	默认	含义
`RUSTFS_STORAGE_DRIVER`	否	`native`	`powerfs` 时安装外部后端
`POWERFS_FILER_ENDPOINTS`	powerfs 模式必填	无	Filer gRPC 端点，逗号分隔
`POWERFS_MASTER_ENDPOINTS`	powerfs 模式必填	无	master gRPC 端点（卷分配/定位）
`POWERFS_S3_COLLECTION`	否	`default`	分配 volume 的 collection
`POWERFS_S3_REPLICATION`	否	`001`	分配 volume 的 replication
`POWERFS_S3_CLIENT_ID`	否	进程 UUID v4	Filer 写请求标识
`POWERFS_RPC_TIMEOUT_MS`	否	`5000`	Filer / volume RPC 超时

然后用任意 S3 客户端验证：

复制代码

aws --endpoint-url http://127.0.0.1:9000 s3 mb s3://demo
aws --endpoint-url http://127.0.0.1:9000 s3 cp ./model.bin s3://demo/model.bin
aws --endpoint-url http://127.0.0.1:9000 s3 cp s3://demo/model.bin ./copy.bin
md5sum ./model.bin ./copy.bin

十一、这次集成留下的几条设计原则

协议不要自研，边界要自划。 S3 语义、IAM、控制台交给成熟项目；自己只做数据与元数据。集成点越靠近存储契约，需要改的上层代码越少。
控制面与数据面必须能分桶路由。 系统桶留在 native，用户桶走外部后端。少了这条，IAM 初始化会直接把服务卡死。
"RPC 成功"不等于"写入生效"。 异步持久化 + follower 滞后会制造大量"看起来成功、实际没生效"的状态。写后读校验、跨端点重试、幂等重放，是适配层的基本功。
绝不在读路径返回可疑数据。 解压失败、CRC 不符、EC 分片不足、布局不自洽------统一选择报错，而不是"尽力返回"。文件系统承载的是用户数据，错数据比 5xx 可怕得多。
能力要显式声明，不要假装支持。 capability() 把 EC、版本化、Multipart、对象锁、生命周期逐项列出；不支持的返回 501 并在 Admin 展示。这比"悄悄返回空结果"诚实，也更容易排查。
失败清单对照 > 通过率。 同一组 s3-tests，在 native 与 powerfs 下逐条比对失败项。只要清单一致，就说明没有引入新的语义偏差。

十二、下一步

目前 P0--P2d、P6 EC Read、P7 压缩已经落地，后续重点：

版本化与删除标记 ：多版本链、versionId、delete marker；
校验和 ：x-amz-checksum-*（CRC32C / CRC64NVME / SHA256）；
对象锁与保留：legal hold、retention 与删除拦截；
生命周期与批量删除条件：把 lifecycle 接到同一套删除 API；
多节点与故障注入：master leader 切换、卷离线、GC 与悬挂 blob 清理；
性能：EC 分片批量读、S3 侧分片缓存、1TB 数据集基准。

RustFS 负责把 S3 这张"脸"做得足够标准，PowerFS 负责把底下这张"账本"和"仓库"做得足够可靠。两者通过一层薄薄的 ExternalBackend 契约连接起来------这大概就是"复用成熟生态"最舒服的姿势。

本文基于 PowerFS 私有仓库当前实现撰写。相关代码位于 powerfs-rustfs-store/（适配层）、powerfs-filer/（S3 元数据 RPC 与 EC 布局）、rustfs/crates/ecstore/src/store/external.rs（注入缝）。

不重造 S3 轮子：PowerFS 如何把 RustFS 变成自己的 S3 服务面

一、为什么不再自己写 S3

二、先划边界：谁负责什么

三、四种方案，三次否定

方案 A：把 Arc<ECStore> 换成 Arc<dyn StorageEngine>

方案 B：把 PowerFS 伪装成 RustFS 的一块磁盘

方案 C：做一个 S3 代理

方案 D：回到自研

最终方案 A′：ECStore 内部委托

四、注入缝：一个契约 + 一次进程级安装

1. 系统桶必须留在 native

2. 漏一个固有方法，就会出现"能写不能删"

五、元数据：8 个 RPC 把 S3 语义压到 Filer

命名空间映射

覆盖写必须是一次原子 RPC

Leader 不在本机：重试策略比 RPC 本身更重要

一个差点被"静默成功"吞掉的 bug

六、数据面：needle、2MB 分块与 Range

1. grpc_port 其实是数据面端口

2. TLV 单帧上限 2MB，大对象必须分块

七、Multipart：隐藏桶、零拷贝完成、重放幂等

跨卷复用 needle_id：一个真实的坏数据事故

八、EC 与压缩：读路径是数据正确性的最后一道闸

1. EC 转换后，S3 读出了"半截好数据"

2. EC 与 Multipart 的隐藏冲突

3. P7：zstd 压缩与"压缩标记不能串"

九、验证：用 native 做对照，而不是只盯通过数

十、怎么跑起来

十一、这次集成留下的几条设计原则

十二、下一步

方案 A：把 `Arc<ECStore>` 换成 `Arc<dyn StorageEngine>`

1. `grpc_port` 其实是数据面端口