如同上面的問題，7zip（更具體地說是 Linux 上的 p7zip）在測試檔案時是否使用磁碟空間？由於我只有一個 2TB 硬碟可供使用，而且每個存檔的大小範圍為 800GB-1TB，因此我想同時測試 2 個存檔，而不是只測試一個。
7zip 官方文件沒有提及測試時的磁碟使用情況。
答案1
不應該。 （但有可能）
為了在提取存檔時驗證存檔中的資料是否正確，每個檔案或資料區塊都將具有與其關聯的 CRC 或錯誤檢測代碼。
從效率的角度來看，在解壓縮檔案時進行錯誤檢查非常有意義前將資料寫入磁碟。否則，您將浪費寶貴的資源，從存檔中讀取數據，將其寫入磁碟，然後重新讀取磁碟上的資料以進行錯誤檢查。對於大型存檔或記憶體受限的系統，這可能會使解壓縮檔案所需的時間加倍，這是不可接受的。在這種情況下，我假設磁碟讀取和寫入是該過程中最慢的部分。
如果您在寫入之前進行檢查，則可以透過解壓縮器、透過錯誤檢查演算法有效地將存檔串流傳輸，然後輸出到磁碟並假設磁碟子系統知道它在做什麼。任務完成。
透過這種方式，「測試」存檔就成為一項免費操作。您遵循與解壓縮完全相同的步驟，但您只是丟棄資料而不將其寫入磁碟。
我強烈希望這就是它的工作方式，因為僅僅為了測試存檔而將所有內容寫入磁碟似乎很瘋狂，並且不會比「真正」的資料解壓縮快。 「測試」更快意味著至少跳過一個步驟，很可能將資料寫入磁碟。
答案2
不，它沒有 - 至少 19.00 版本不是。
並行測試多個文件在固態驅動器上效果很好，但通常會降低機械驅動器的性能 - 然後需要進行大量查找來並行讀取多個檔案。因此，可以提出以下建議：
在固態硬碟（NVMe 或 SATA SSD）上測試檔案時，啟動盡可能多的進程（如果可以的話）。
在同一機械磁碟機（或機械 RAID 磁碟區）上測試檔案時，啟動一個或最多兩個進程。
在 USB 隨身碟上測試存檔時，結果會有所不同。
可悲的是，大多數常見的 USB「筆式驅動器」或「棒」即使在讀取時也非常慢 - 即遠未使 USB 接口頻寬飽和。當同時從驅動器的多個不同區域存取資料時，某些此類驅動器會變得更慢。這是由於磁碟控制器中的 RAM 有限造成的。控制器無法一次將訪問整個驅動器所需的所有元數據放入RAM 中，並且當它更改驅動器上的讀取區域時，最終會從閃存介質中重新讀取元數據，通常必須遵循鏈接鏈來讀取取元資料。即使快閃記憶體佈局允許，此類元資料讀取通常也不會被磁碟機並行化，通常也使用速度較慢的專用程式碼路徑來實現。
解決這個問題的唯一可靠方法是進行頻寬測試。假設您必須驗證檔案a、b、c、d和，所有這些都在大小e上f大致以相同的數量級進行。它們需要按大小降序排序。首先，對 的驗證進行計時a，並計算頻寬BW_a = time_a / size_a。然後並行驗證b和c併計算這些頻寬。只要它們的總和sum_BW_bc大於BW_a，您就會獲得效能提升。然後驗證d、e並f並行計算這些頻寬。只要它們的總和sum_BW_def大於sum_BW_bc，您就會獲得效能提升。等等。最終，與先前的測試相比，您將達到總頻寬下降的流量數量。使用先前的較少數量的串流繼續驗證剩餘的檔案。
此方法可以應用於任何驅動器，儘管機械驅動器的性能下降如此之快，以至於可能會過度影響驗證過程的整體性能。因此，當知道並行測試的頻寬小於上一步頻寬的 90% 時，應終止並行測試。您可以透過在測試運行時每秒重新計算頻寬並在頻寬低於截止點時終止測試來實現此目的。