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

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

由於NameNode會提供有保證的原子實現(xiàn)重命名的，也沒有元數(shù)據(jù)損壞的機率。不可能以「半完成」?fàn)顟B(tài)結(jié)束，文件在這兩個地方都存在，甚至更糟的是完全被刪除。

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

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

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。