擴充檔案系統規格及其測試

檔案系統規格並不完整。它並未涵蓋所有作業，甚至未涵蓋檔案系統 API 中的介面和類別。對於它所涵蓋的部分，可能會有一些小問題，例如特殊情況、失敗模式和其他意外結果。標準檔案系統也可能與規格有顯著差異，因此需要在測試中記錄和處理此問題。

最後，檔案系統類別和方法並非一成不變。它們可能會擴充現有類別的新作業，以及潛在的全新類別和介面。

因此，不要將本規範視為一份完整的靜態文件，就像 Hadoop 程式碼的其他部分一樣。

  1. 將其視為一份隨附參考實作 (HDFS) 和用於驗證檔案系統的測試的動態文件。
  2. 不要害怕延伸或更正它。
  3. 如果您建議對 FileSystem API 進行增強，則應延伸規範以符合。

如何更新本規範

  1. 儘管在 hadoop-common 程式碼庫中找到，但 HDFS 團隊擁有 FileSystem 和 FileContext API 的所有權。在 hdfs-dev 郵件清單上與他們合作。

  2. 在 HADOOP 專案、元件 fs 中建立 JIRA 問題，以涵蓋 API 和/或規範的變更。

  3. 程式碼變更當然需要測試。理想情況下，規範本身的變更會伴隨著新的測試。

  4. 如果變更涉及已具有 Abstract*ContractTest 的作業，請將新的測試方法新增到類別，並驗證它們在對其進行子類別化的檔案系統特定測試中是否有效。這包括物件儲存空間以及本機和 HDFS 檔案系統。

  5. 如果變更新增新的作業，請新增一個新的抽象測試類別，其契約驅動架構與現有的相同，並為支援作業的所有檔案系統新增一個實作子類別。

  6. 新增測試方法以驗證無效的前提條件會導致預期的失敗。

  7. 新增測試方法以驗證有效的先決條件會導致檔案系統預期的最終狀態。每個測試盡可能少地進行測試，有助於追蹤問題。

  8. 如果可能，請新增測試以顯示並行處理預期。

如果 FileSystem 未通過新增加的測試，則可能是因為

  • 規範錯誤。
  • 測試錯誤。
  • 測試尋找錯誤的例外狀況 (即它太嚴格)。
  • 規範和測試正確，而檔案系統與預期不符。

HDFS 的行為必須被視為正確。如果測試和規範不符合此行為，則需要更新規範。即便如此，仍有可以變更 FS 的情況

  1. 引發的例外狀況是一般的 IOException，而可以引發更具資訊性的子類別，例如 EOFException。
  2. 當傳遞一組無效的引數時，FileSystem 無法正確失敗。這可能是可以修正的，但必須謹慎進行。

如果 LocalFileSystem 中有不相符的地方，那麼它可能無法修正，因為這是透過 Java IO API 存取的原生檔案系統。

對於其他 FileSystems，其行為可能會更新為更準確地反映 HDFS 和/或 LocalFileSystem 的行為。對於大多數作業來說，這很簡單，儘管 rename() 的語意很複雜，以致於不清楚 HDFS 是否是正確的參考。

如果測試失敗，而且感覺這是一個無法修正的特定於檔案系統的問題，那麼應該新增一個新的合約選項，允許對結果進行不同的詮釋，修改測試以回應選項的存在/不存在，並更新標準 FileSystems 的 XML 合約檔案，以指出何時存在功能/失敗模式。