评审存储方案的时候有三类需求最常见把 MySQL 的数据目录挪过去、给虚拟机提供磁盘、给全公司当一个共享网盘。这三类需求听着都像存东西但对象存储对其中两类是接不住的。先分清三种存储各自承诺了什么再决定要不要上 S3比先选产品再补课省事得多。块、文件、对象接口语义先分清块存储承诺的是一块磁盘应用拿到的是一段固定大小的 LBA 地址空间可以原地覆写任意扇区数据库靠这个语义和 fsync 配合保证事务落盘。文件存储承诺的是一棵目录树POSIX 语义重命名、目录遍历、文件锁都是基本操作。对象存储承诺的是另一套东西扁平的 key通过 HTTP 接口以整个对象为单位做读写。这三种承诺没有高低之分差别在语义。数据库要的是第一种共享目录要的是第二种S3 提供的是第三种。数据库和虚拟机的盘放不进去把 MySQL 的 datadir 放到对象存储上最先撞上的是覆写语义。S3 的 PUT 是整对象替换改一个 16KB 的页也要重写整个对象InnoDB 每秒成百上千次的页修改会把这个放大量放大到不可用。虚拟机磁盘同理qemu 需要的是块设备语义随机写、discard、精简置备这些在对象接口上都没有对应物。RustFS 的协议列表是 S3、WebDAV、FTP(S)、Swift 和 MCP里面没有块接口。这不是功能缺失是定位它服务的是整对象的工作负载。虚拟机磁盘和数据库盘该留在块存储或本地盘上。FTP(S)、Swift 这两个协议也在列表里但都改变不了结论FTP 传的还是整文件Swift 说的还是对象语义。列表里真正的分界线是 WebDAV它把目录和重命名这两个文件操作带了进来下一节展开说。共享目录的需求WebDAV 能接一部分部门共享盘是中间地带。RustFS 内置了一个 WebDAV 网关编译在标准二进制里支持 PROPFIND 列目录、MKCOL 建目录、PUT 上传、GET 下载、MOVE 重命名、DELETE 删除。Windows 资源管理器、macOS Finder、GNOME Files 都能直接挂客户端地址写法Windows 资源管理器https://host:8080/macOS Finderhttp://host:8080/GNOME Filesdav://host:8080/或davs://host:8080/认证用的是 HTTP Basic用户名和密码就是 RustFS 的 access key 和 secret key网关拿它过一遍 IAM用户自己的 S3 策略对每个操作照样生效。授权失败的 MOVE 不动源对象这点比很多自建网盘实现得干净。MOVE 的代价也要先有预期S3 层没有重命名原语官方对 MOVE 的权限要求是读取和删除源对象、写入目标位置这个组合暴露了它的本质落到底层就是复制加删除。大对象改名等于一次完整搬运再加一次删除请求开销和文件体积成正比POSIX 那种纯元数据的轻量重命名在这条路上不存在把重命名当轻操作反复做的应用会先撞上它。上传体积也有一条线WebDAV 走单次 PUTRUSTFS_WEBDAV_MAX_BODY_SIZE默认 5 GiB 封顶放文档、安装包、设计源文件都够用几百 GB 的数据集备份这类大件脚本里走 S3 接口做 multipart就不受这条线管。边界也要说清楚WebDAV 补的是目录和重命名这类文件操作POSIX 文件锁和局部覆盖依然没有。官方支持的方法列表里没有 LOCK多客户端同时写同一路径也没有冲突保护后完成的写入直接盖掉先完成的双方都不会收到任何提醒。共享盘场景要防这个要么按人划目录各写各的要么明确接受最后写入者赢的规则。还在用 Excel 共享编辑、依赖文件锁的老应用这条路走不通。客户端侧还有一个甩不到存储头上的坑Windows 自带的 WebDAV 客户端在大文件和高延迟链路上历来不稳这类超时和中断多半出在客户端层排查时别急着把锅扣到服务端官方文档给的排查法是用 curl 直连隔离问题curl 通了而资源管理器不通答案就在客户端那头。另外文档明确写了对目录发 GET 请求会返回405 Method Not Allowed列目录要用 PROPFIND有些老客户端默认发 GET挂载失败先查这里。列举的语义也和目录树不同PROPFIND 沿着层级往下走S3 的 ListObjects 是拿前缀在扁平 key 空间里分页扫走的是两条完全不同的路径从文件系统脚本迁过来的工具要重看这一段。对象存储接得住的活写一次、读多次的场景是对象存储的主场备份包、容器镜像、视频素材、训练数据集、日志归档。拿 MySQL 说同一个数据库的两种形态在这里分家datadir 是运行中的数据目录靠原地覆写活命前面说过它放不进来mysqldump 出来的备份包是写一次读多次的整对象天生就是这层的主场。同一个库形态不同答案相反评估前先分清手里的是哪种。RustFS 在这些场景上的能力有测试背书官方 S3 兼容矩阵里版本化、对象锁、range 读取、multipart 上传都在已测试列表里。对象锁给归档数据提供 WORM 语义range 读取让大文件不用整个拉回来。还有一样常被忽略的能力事件通知。桶上配好规则对象上传、删除这类事件可以推到 webhook解析管线拿它做触发器文件一落存储下游就开工轮询都省了。这套通知跟 WebDAV 那条路不冲突人从网盘拖一个文件进去程序照样收到事件。这些管理能力落到选型判断上也很直白备份包要回滚到上周是版本化的活归档数据要防篡改是对象锁的活文件一落存储就要触发下游是事件通知的活。过去在文件系统边上写脚本维护的那套杂务在这里变成桶的属性跟着桶走不跟着客户端走。配置 WebDAV 网关的完整参数是这五个TLS 默认是开的exportRUSTFS_WEBDAV_ENABLEtrue# 默认 falseexportRUSTFS_WEBDAV_ADDRESS0.0.0.0:8080# 默认 0.0.0.0:8080exportRUSTFS_WEBDAV_TLS_ENABLEDtrue# 默认 trueexportRUSTFS_WEBDAV_CERTS_DIR/path/to/certs# 开 TLS 必填exportRUSTFS_WEBDAV_MAX_BODY_SIZE5368709120# 默认 5 GiBS3 那条路不需要任何开关主监听端口 9000 自带 S3 API。同一个集群程序走 9000 的 S3 接口写备份包人走 8080 的 WebDAV 挂网盘看文件两条路落到同一份数据上。写入模型也顺带说一句S3 没有文件锁的概念并发写的正确姿势是各写各的对象key 不同就互不干扰撞同一个 key 才有覆盖问题。备份、日志、镜像仓库这类工作负载天然就是各写各的这正是它们和对象存储合得来的底层原因。拿需求对表判断顺序建议倒过来走先列出应用对存储做的每一种操作出现原地覆写、文件锁、高频重命名这份数据留在块或文件存储操作全是整对象的 PUT/GET/DELETE对象存储就够而且备份、版本化、生命周期这些管理能力是白送的。拿不准的应用有个成本很低的验证法把它的存储操作在 RustFS 的 S3 接口上跑一遍冒烟测试哪一步的语义对不上哪一步就是分界线。这套验证用mc加一个 alias 十分钟就能跑完比上线后发现日志写不进去再回退便宜得多。语义对不上的操作清单也是日后跟团队解释为什么这块不上对象存储时最省力的材料。验证用的接口清单不用凭记忆列官方文档的 S3 兼容矩阵把已测试与计划中的能力逐项分开写。RustFS 的 1.0.0 正式版在 2026 年 9 月 16 日发布版本化、对象锁、事件通知都已生产可用源码在 GitHub 的 rustfs/rustfs 仓库。