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-，位于真實的文件系統根目錄。但如果你通過一個限定在某個子目錄的訪問點掛載，就看不到這個目錄。這是訪問點的工作原理：它限制了你的視圖范圍，這意味著你創建沖突的那個掛載點，反而看不到沖突產生的痕跡。團隊同意文檔需要明確說明這一點，或許在你讀到這篇文章時，相關說明已經補充完畢。

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目錄在通過訪問點掛載時不可見。