如果在鏈接（）之前取消鏈接（），fwrite（）會更快截斷它

我想在rhel 6平臺上運行磁盤性能的簡單測試。只是將1G字節寫入磁盤。我發現如果該文件首先被取消鏈接，則它將比截斷文件快得多。這大約是1.5s與15s。如果在鏈接（）之前取消鏈接（），fwrite（）會更快截斷它

爲什麼？我認爲unlink（）最後一個硬鏈接會將文件截斷爲0並刪除inode。爲什麼fwrites與unlink（）比截斷更快？

#include <stdio.h> 
#include <stdlib.h> 
#include <time.h> 

int 
main(int argc, char* argv[]) 
{ 
    if (argc < 2) { 
     return -1; 
    } 

    char buf[1024]; 

    srand(time(0)); 

    int i; 
    for (i = 0; i < 1024; ++i) { 
     buf[i] = rand(); 
    } 

    /* unlink(argv[1]); */ 
    FILE* fp = fopen(argv[1], "wb+"); 
    if (fp == NULL) { 
     perror("fopen"); 
     return -1; 
    } 

    for (i = 0; i < 1024 * 1024; ++i) { 
     if (fwrite(buf, 1024, 1, fp) != 1) { 
      perror("fwrite"); 
      return -1; 
     } 
    } 

    return 0; 
}

來源

2013-04-08 Zhongzhi

刪除文件時，你必須在磁盤和文件系統上有足夠的可用空間可以刪除文件和懶洋洋地收回他們的空間可能比截斷它更快。它可以將inode標記爲正在刪除，並在後臺或稍後刪除該文件，並幾乎立即創建新的inode，爲新寫入做好準備。

來源

2013-04-08 05:29:20

Alexey，謝謝你的回答。儘管我不確定，但我對此有同樣的想法。但我仍然不明白爲什麼truncate沒有這樣實現。如果文件被截斷爲零，爲什麼不將截斷的塊移動到新的inode，並保持當前的inode乾淨以便下次寫入？ – Zhongzhi 2013-04-08 05:47:48

我不確定。真的，你的問題的答案取決於文件系統的實現。您可能需要進一步研究，請參閱文件系統文檔或源代碼，並在網絡上查找性能討論。 – 2013-04-08 05:51:36

@Zhongzhi「爲什麼不把截斷塊移動到新的inode」 - 什麼新的inode？分配一個inode只是爲了讓你的程序更快而犧牲系統的其他部分，這是一個糟糕的想法和FS代碼的無意義複雜化。這與刪除文件的最後一個鏈接時的塊回收不會向刪除程序收費是完全不同的，因爲這些塊是異步回收的。 – 2013-04-08 08:04:38

如果在鏈接（）之前取消鏈接（），fwrite（）會更快截斷它

回答

相關問題