Amazon正式为S3挂载文件系统，我带着测试工具前去"找茬"

我花了十多年时间逢人就说"S3不是文件系统"——回头想想，这确实是个挺奇怪的开场白。所以当AWS周二正式推出S3 Files（允许将S3存储桶挂载为NFS共享）时，我做了一件任何理性人都会做的事：启动一个EC2实例，然后开始尝试把它搞崩。

在和Andy Warfield通话之前，我大概有四个小时的时间。Andy是AWS的VP兼杰出工程师，也是实际主导S3工程团队的人（不管他承不承认），与他同行的还有S3团队的部分成员。我想带着数据去，而不是带着观点。观点不值钱，关于存储的观点更是危险，而我关于存储的观点，说起来都是笑料。

好消息是：核心产品相当扎实。我精心设计了十个并发冲突场景——同时通过NFS挂载和S3 API向同一个键写入——结果S3每一次都赢了，两秒以内完成收敛，没有出现任何脑裂状态。对于那些曾经不幸依赖过s3fs-fuse或goofys等社区FUSE驱动的人来说，这两个工具历来的"冲突解决方案"不是数据损坏就是一脸茫然。相比之下，这才是真正经得起考验的工程实力。

S3 Files基于EFS基础设施构建，收费标准也与EFS相同（存储{zhiding_content_info_22}.30/GB，读取{zhiding_content_info_22}.03/GB，写入{zhiding_content_info_22}.06/GB），这个价格对齐是有意为之的。团队告诉我："在两者之间提供更有利的经济性，那就不寻常了。"关键在于，你只需按实际落在文件系统上的那部分热数据付费，其余数据仍以{zhiding_content_info_22}.023/GB的价格保存在S3中。挂载一个PB级存储桶，活跃使用其中1TB，按实际用量付费即可。

团队花了数月时间，试图让文件与对象之间的边界彻底隐形，最终却意识到：保留这道边界，才是正确的设计。一位工程师告诉我："我们一直在试图兼顾两者的最低公分母。"文件系统客户端每10毫秒就在修改对象？这在NFS里完全正常，但对S3存储桶来说就是噩梦。于是他们将两个世界分开，通过自动同步相互关联。S3始终是权威数据存储，文件系统只是一层视图，而不是副本。

三种速度，一套产品

我测量到了三种截然不同的同步速度，这恰好揭示了其架构逻辑。来自文件系统的写入会在固定的60秒窗口内聚合，然后以单次PUT操作提交到S3。通过S3 API新建的文件，大约30秒后会出现在NFS挂载点上。而文件系统已知文件的更新传播速度则为1.8秒——比新文件创建快了整整15倍。

当我把这些数字拿给团队看时，他们确认60秒窗口目前是固定的，但也暗示未来可能会变为自适应（如果你在意这一点，不妨去找你的AWS客户经理施压）。30秒的数字只是S3事件传播延迟，而1.8秒的更新速度，则是文件系统让已缓存的inode失效，走的是一条快得多的路径。

超过128KB的读取（默认值，可配置为低至0——不是说你应该这么做，但你绝对可以……）会完全绕过文件系统，直接从S3流式读取，完全不收取S3 Files的费用。这个操作让我想起了亚马逊以客户为中心的黄金年代。绕过路径目前每客户端支持约3 GB/s的并行GET速度。

然后我开始"发挥创意"了。

我创建了十个带边缘情况键名的S3对象：末尾带斜杠的、双斜杠的、路径遍历模式的、256字符路径组件的、只叫"."和".."的、带表情符号的，还有EICAR字符串——就是想看看会发生什么。然后我挂载存储桶，执行了ls命令。

其中六个消失了。客户端没有报错，日志里也什么都没有。它们仍然存在于S3中——只是从文件系统视角完全看不见。

我最初对此有所误判，但事实证明，CloudWatch里确实存在一个对应指标：AWS/S3/Files命名空间下的ImportFailures，按FileSystemId维度区分。对我所有的不兼容键，它都正确触发了。但客户端侧完全没有任何提示——ls没有报错，实例上没有日志，NFS响应里什么都没有。你必须主动去找一个你从来没听说过的CloudWatch命名空间中的某个特定指标，而这个服务刚刚才上线。更完善的可观测性已在路线图上，包括通过CloudWatch日志直接指向未成功导入的具体对象。但目前，如果你挂载的存储桶多年来积累了各种"创意"键名，其中一部分对象将无法可见，而你唯一的信号是一个没人会主动去查的CloudWatch计数器。

删除传播的结果则相当诡异：通过S3删除的文件，在NFS挂载点上仍可读取6秒或18秒，两者之间没有任何中间值——呈现出极为干净的双峰分布。"这确实很有意思，我不会预料到这种情况，"Warfield说道。团队怀疑这是S3内部删除通知机制的一个表现。从实际角度来看，这意味着你可以在已删除文件被彻底清除前的18秒内，读到完整有效的内容。不算理想，但也不是灾难性的，只是值得知道。

通过访问点访问文件时，如果S3赢得了冲突，会产生一个明显的陷阱。由于我的测试方式，我直接踩了进去。通过API创建的S3对象不携带POSIX所有权元数据，因此导入的文件默认归属为root:root，权限为0644。如果你的访问点强制使用不同的UID，你可以读取该文件，但无法再写入——权限不匹配。"这其实不是我预期的行为，"一位工程师告诉我。两个系统各自都没有问题，是两者的组合产生了问题。团队正在研究解决方案。

此外，文档中说冲突的文件系统版本会被放入lost+found目录。确实如此——目录名为.s3files-lost+found-<filesystem-id>，位于真实的文件系统根目录。但如果你通过一个限定在某个子目录的访问点挂载，就看不到这个目录。这是访问点的工作原理：它限制了你的视图范围，这意味着你创建冲突的那个挂载点，反而看不到冲突产生的痕迹。团队同意文档需要明确说明这一点，或许在你读到这篇文章时，相关说明已经补充完毕。

AWS开源FUSE驱动Mountpoint for S3并没有被放弃，而是被定位为面向不同场景的不同工具。Mountpoint适合大文件高吞吐场景，不支持的操作会快速失败，设计如此。S3 Files则面向一切需要真正NFS接口的场景。读取绕过技术实际上正是从构建Mountpoint的经验中汲取而来，这是一段不错的工程传承。

AWS文件与对象存储服务总经理Ed Naim描绘了一个比本次发布更有野心的愿景。他认为S3 Files将演变为数据管道中的临时文件系统视图——为任务期间临时创建S3数据的文件视图，完成工作后将特定变更同步回去，然后销毁视图。以API驱动的同步控制，而非当前自动的60秒推送，已在路线图上。这是一个和"把存储桶挂成NAS"相当不同的产品形态。作为一个老派系统管理员，对于这个我眼中全新而令人不安的使用场景，我内心充满了莫名的抵触。

S3 如今已支持对象、文件、表、向量和高性能计算。我问接下来还会有什么。他们的回答我完全没听进去，只是在笔记上写下了"数据库"两个字，四周还画了几颗心。只要你用得足够歪，什么都能是数据库。

我问他，我是不是该停止说"S3不是文件系统"了。"不用，"他说，"S3不是文件系统，但S3 Files在它上面给了你一个文件接口。"

我说了十多年"S3不是文件系统"。结果证明，我一直都是对的——AWS只是决定不再抗争，而是在前面架了一个真正的文件系统。

Q&A

Q1：S3 Files和传统的S3有什么区别？

A：S3 Files允许将S3存储桶挂载为NFS共享，提供真正的文件系统接口，而传统S3只支持对象存储API。S3 Files基于EFS基础设施，存储计费{zhiding_content_info_22}.30/GB，读取{zhiding_content_info_22}.03/GB，写入{zhiding_content_info_22}.06/GB。未被文件系统活跃使用的数据仍以{zhiding_content_info_22}.023/GB存储在S3中。S3依然是权威数据存储，文件系统只是其上的一层视图，两者通过自动同步保持关联。

Q2：S3 Files的同步延迟是多少？

A：S3 Files有三种同步速度：文件系统写入会在固定60秒窗口内聚合后提交到S3；通过S3 API新建的文件约30秒后出现在NFS挂载点；文件系统已知文件的更新传播约1.8秒，比新文件创建快约15倍。此外，超过128KB的读取会直接从S3流式读取，绕过文件系统层，不收取额外费用，速度约3 GB/s。

Q3：S3 Files有哪些已知问题需要注意？

A：目前已知几个问题：一是带特殊字符的键名对象（如末尾斜杠、路径遍历等）在文件系统视图中不可见，且客户端无任何报错提示，只能通过CloudWatch的ImportFailures指标发现；二是通过S3删除的文件在NFS挂载点上仍可读取最长18秒；三是通过访问点访问时，若文件缺少POSIX元数据，可能出现权限不匹配导致无法写入的问题；四是冲突文件归入的lost+found目录在通过访问点挂载时不可见。