當用戶調用hdfs dfs -mv時，HDFS保證重命名操作的原子性。當此命令運行時，客戶端對NameNode進行RPC調用。該RPC的NameNode實現在修改inode樹時保存鎖定，並且只有在重命名完成後才釋放該鎖定，無論是成功還是失敗。 (它可能失敗之類的東西許可或者違反配額。)

由於實施的NameNode內完全執行，僅操縱文件系統元數據，不涉及實際的數據移動。實際上在hdfs dfs -mv命令期間沒有與DataNode進行交互。所有文件的塊保持不變，與inode相關聯的塊列表保持不變。 NameNode只是從一個地方獲取該文件的inode，並將其移至文件系統樹中的另一個地方。不存在破壞塊數據的可能性。

由於NameNode會提供有保證的原子實現重命名的，也沒有元數據損壞的機率。不可能以「半完成」狀態結束，文件在這兩個地方都存在，甚至更糟的是完全被刪除。

現在我需要添加上述回答了微妙的變化。大多數情況下，當運行HDFS shell命令時，通常與HDFS交互作爲後備文件系統。但是，這不是唯一可能的文件系統實現。 Apache Hadoop發行版附帶S3,Azure Storage和OpenStack Swift的替代文件系統插件。還有很多供應商已經創建了自己的文件系統插件。這些替代文件系統是否提供原子重命名語義是這些其他文件系統的實現細節。 S3和Swift插件實現重命名爲複製 - 然後刪除，所以它們絕對不提供原子性保證。 Azure存儲插件通過使用Azure存儲blob租約提供了對原子重命名的一些可選支持，但它不是默認行爲。

而且，這樣做的結果，這是不可能的運行hdfs dfs -mv跨越不同的文件系統。您必須爲此使用複製命令，然後它將涉及完整的數據副本。以下是當您嘗試跨文件系統進行重命名時發生的情況。該示例嘗試爲我的HDFS安裝中的源文件和本地文件系統上的目標運行hdfs dfs -mv。該命令被拒絕。

> hdfs dfs -mv hdfs:///testData file:///tmp/testData

mv: `hdfs:///testData': Does not match target filesystem

問題的最後部分詢問複製時是否可能損壞數據。 Hadoop將在讀取文件時執行校驗和驗證，所以客戶端不會看到損壞的數據。 DistCp也可以執行源和目標之間的校驗和比較作爲後處理步驟。

總結

以上是生活随笔為你收集整理的hdfs mv命令_如何HDFS mv命令工作的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。