試圖調查 /tmp 已滿的問題，但我們不知道是什么原因造成的。我們最近確實有一個更改，它使用 HDFS 命令執行復制到另一臺主機 ( hdfs dfs -cp /source/file hdfs://other.host:port/target/file，雖然復制操作不直接接觸或參考 /tmp 它可能會將其用作其實作的一部分。
但是我在檔案中找不到任何東西來證實或反駁這個理論——還有其他人知道答案嗎？
uj5u.com熱心網友回復：
你可以看一下代碼：
這是使用 HDFS進行復制的代碼。它使用自己的內部CommandWithDestination類。并使用另一個實際上只是 java.io 的內部類撰寫所有內容。類。（完成實際的寫入。）所以它在記憶體中緩沖位元組并發送位元組。可能不是問題。您可以通過更改 java 使用的 tmp 目錄來檢查這一點。( java.io.tmpdir )
匯出_JAVA_OPTIONS=-Djava.io.tmpdir=/new/tmp/dir
根據 java.io.File Java Docs
默認臨時檔案目錄由系統屬性 java.io.tmpdir 指定。在 UNIX 系統上，該屬性的默認值通常是“/tmp”或“/var/tmp”；在 Microsoft Windows 系統上，它通常是“c:\temp”。呼叫 Java 虛擬機時，可以為該系統屬性賦予不同的值，但不保證對該屬性的編程更改對該方法使用的臨時目錄有任何影響。
HDFS 復制使用的方法：
protected void copyStreamToTarget(InputStream in, PathData target)
throws IOException {
if (target.exists && (target.stat.isDirectory() || !overwrite)) {
throw new PathExistsException(target.toString());
}
TargetFileSystem targetFs = new TargetFileSystem(target.fs);
try {
System.out.flush();
System.out.println("Hello Copy Stream");
PathData tempTarget = direct ? target : target.suffix("._COPYING_");
targetFs.setWriteChecksum(writeChecksum);
targetFs.writeStreamToFile(in, tempTarget, lazyPersist, direct); //here's where it uses Java.io to write the file to hdfs.
if (!direct) {
targetFs.rename(tempTarget, target);
}
} finally {
targetFs.close(); // last ditch effort to ensure temp file is removed
}
}
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/465311.html
上一篇：為什么從databrickssparknotebook（hadoopfileUtils）寫入DBFS掛載位置比寫入DBFS根位置慢13倍？