
過去我用dd if=/dev/sda1 | gzip -5 > file.gz
.一段時間後,當分區上的可用空間較小時,我使用相同的命令再次製作了一個圖像文件,並且輸出文件稍小一些。
在這兩種情況下,我都使用了相同版本的dd 和gzip、相同的參數、相同的硬體、相同的分區,並且我從dd 獲得了有關輸入/輸出記錄量和複製位元組數的相同輸出(時間和速度除外)。
是什麼導致了這種情況以及如何解釋?假設其中一個圖像檔案無效,如何檢查哪個圖像檔案無效?更有可能的是:HDD 損壞導致未偵測到的資料遺失,或者差異與某些壓縮問題有關?
答案1
這是壓縮的本質。它的有效性取決於輸入資料。由於每次壓縮不同的數據,因此即使未壓縮的大小相同,最終也會得到不同的壓縮大小。
答案2
您似乎認為自由空間壓縮得更好。沒有這樣的規則。
常見的檔案系統僅將可用空間標記為可用,不會用零或其他內容覆蓋它。舊數據仍然存在,直到被新數據覆蓋。 (附註:這就是為什麼有時可以恢復已刪除的檔案的原因)。
dd
讀取所有內容,但它對檔案系統或它們所認為的可用空間一無所知;然後gzip
壓縮所有內容,包括「可用空間」中的舊數據,這些數據可能壓縮得很好,也可能很差。在這種情況下,沒有自由空間;只有一些資料流需要處理。
可能是一些新的“高度可壓縮”檔案替換了標記為可用空間的舊“可壓縮性較差”資料。如果是這樣,新檔案將比舊存檔小,儘管它包含更多您認為有用、實際或現有的資料。這可能是您所經歷的情況的主要原因。
請參見僅從硬碟克隆正在使用的空間, 和我的回答在那裡。 「準備」步驟用零覆蓋空白空間,因此壓縮得非常好。如果您在每次備份之前都執行此操作,則產生的存檔的大小可能會符合您的直覺。
“可能”,因為你問題的另一個答案一般來說是正確的:這完全取決於輸入資料。即使在將可用空間清除後,如果其中的檔案不同,則 60% 已滿的檔案系統可能會比同等大小的 50% 已滿的檔案系統壓縮為更小的存檔。