在使用 備份一些資料（200 GB 主目錄）時rsync，我遇到了特定檔案的 I/0 錯誤，之後同步繼續“正常”使用其備份。問題來源檔案顯示檔案大小為 72 位元組。
我取消了 同步，並再次運行相同的命令。這次，同一個檔案顯示正在傳輸資料。很多數據....還有更多數據，還有更多...我檢查了目標檔案的大小，最大為 13 GB！所以我用 Ctrl-c 取消同步。
60.0 PB在 Nautilus 中再次檢查來源檔案大小時，它在 500 GB 磁碟機上 顯示大小（Peta 位元組！）。
現在，這一切的要點是：刪除該檔案是否會導致其他檔案中的資料遺失，因為檔案系統可以認為它比實際大小大得多......檔案系統是ext4..
我可以跳過它同步例外，但我特別感興趣的是如果刪除它會發生什麼。
更新：目標和來源都是ext4
關於它是稀疏文件的建議：如果它是稀疏文件，為什麼它會從一分鐘到下一分鐘顯示不同的大小？該文件當時肯定（？）沒有被使用。它是一個~/.macromedia/Flash_Player/#SharedObjects/someting-or-other.sol文件，其中有許多更多這樣的.sol該目錄中的檔案..而且它確實在第一次通過時顯示了 I/0 錯誤。
另外，根據man rsync，建議的-S選項是處理稀疏文件有效率的， 不是適當地，所以這對我來說，即使我沒有使用-S它，在任何一種情況下都應該準確地複製稀疏文件：它沒有，即使它是一個稀疏文件，60.0 Peta 字節似乎肯定是（？）是文件系統中某處的錯誤......這是我主要關心的問題：如果檔案系統中存在故障，刪除該檔案是否會對其他檔案產生影響？
更具體地說：它寫入了 13 GB 的數據，並且正在攀升！當我取消它時，刪除時是否會同時刪除 13 GB - 60 PB 的資料？
答案1
看起來來源檔案系統已損壞，通常是由於核心錯誤或 RAM 損壞（損壞的磁碟更有可能導致無法讀取的檔案而不是損壞的資料）。至此，所有的賭注都落空了。但是，如果損壞非常局部，則只有一個檔案的 inode 損壞，其他檔案未損壞，因此您可以安全地刪除該檔案。請注意，無法檢驗此假設。
我的建議是：
- 進行 RAM 測試，或將磁碟插入另一台機器。
- 確保您已備份所有資料。
- 如果可能的話，使用 SMART 檢查磁碟的運作狀況。
- 跑步
fsck。 - 如果磁碟仍然完好，請繼續使用它。
答案2
它是稀疏文件。您應該考慮使用-S，以便盡可能正確地處理文件。