作者Litfal (Litfal)
看板Storage_Zone
標題Re: [請問] 移動檔案先壓縮比較不會壞?
時間Mon Sep 16 23:53:49 2013
※ 引述《weiwei782188 (hardtoeasy)》之銘言：
: ※ [本文轉錄自 ask 看板 #1ID9zNxL ]
: 作者: weiwei782188 (hardtoeasy) 看板: ask
: 標題: [請問] 移動檔案先壓縮比較不會壞?
: 時間: Sun Sep 15 01:39:32 2013
: 如果要移動檔案 是不是先壓縮 比較能避免檔案損毀呢? 還是只是純粹加快傳輸速率
: 另外只有移動到不同的分割磁區 檔案才會有機會損毀
: 同磁區內 移動是不是不會損毀?
: 還有有時候不小心刪到大檔案 這時我在過程中按取消 在從資源回收還原
: 檔案有可能損毀嗎?
: 其實我只是想問怎樣移動檔案有可能會損毀 還有怎樣避免...
: 3Q
我不同意移動檔案會更容易造成檔案毀損。
就算有，我想也佔不到1%，剩下的是人為疏失。
例如因為要等太久，懶得等了，按下取消後，順手把移動好的檔案砍掉。(這我做過...)
或是移動太久，硬碟負荷大，原本散熱就不好的系統就出事了。
你要說這是OS設計不良...這也算人為疏失啊！XD
當然，因為溫度提升，會造成讀寫錯誤率提升。
但只要在正常的工作溫度範圍，損壞的機率跟你移動大檔是差不多的。
對部分打包方式而言，一次壞整包的機率說不定還比較高...
至於效能問題
移動小檔對硬碟是個高負載低效率的工作，是因為有許多overhead
以下簡單列出移動檔案的工作流程：(不同槽或不同裝置)
1. 訪問檔案表，取得資料實際位置，建立檔案控制代碼src。(還包括確認存取權限等工作)
2. 建立檔案、更新檔案表，建立檔案控制代碼(dest)。* (同上)
3. 由src讀取資料至記憶體。
4. 由記憶體寫入資料至新檔案dest。*
5. flush與更新檔案表。*
6. 關閉檔案控制代碼。
7. 由檔案表中刪除原始檔案。
3~5會循環直到複製結束，算是真正複製資料的主體。
5不一定每次都會發生，但至少會發生一次，這與OS層寫入緩衝排清(flush)策略有關。
部分作業間可以平行重疊，但為了簡化不提太多。
*代表該作業可能會更新檔案系統日誌，細節依不同檔案系統而異，甚至沒有日誌。
移動大檔時，耗用主要在3~5的複製主體上；而移動小檔時則相反。
又由於，檔案表、日誌、來源檔案、目標檔案各自分散在硬碟的不同部分，
步驟切換時類似於隨機存取，對這方面很弱的機械式硬碟、或部分USB裝置負擔就更大了。
所以把小檔包成一包後再複製或移動，或是直接包到目的地，
可以減少步驟12567的次數，達到提升效率(或說減少開銷)的目的。
最後，移動或複製"重要檔案"時請checksum，或是由現有軟體自動處理。
這與是複製還是移動無關。
部分打包/壓縮也有測試或驗證功能。
雖然我覺得checksum只是保心安的SOP......
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.135.179.10
※ 編輯: Litfal 來自: 220.135.179.10 (09/17 06:33)
1F：→ y3k :可以用水庫水閘來理解 每個檔案都要開關一次閘門 09/17 06:57
2F：→ y3k :而硬碟尤其是USB的閘門特別慢 09/17 06:59
3F：→ y3k : ^隨身碟類 09/17 06:59
4F：→ Litfal :這例子不錯，我想到了另外一個例子： 09/17 17:30
複製檔案就像跑高速公路
檔案大小 = 高速公路的長度
開檔案(開始複製) = 上匝道
關檔案(結束複製) = 下匝道
硬碟 = 匝道很小很窄
部分隨身碟 = 匝道非常小非常窄，還會堵車
※ 編輯: Litfal 來自: 1.171.61.14 (09/17 17:36)
5F：推 joulin :推好文 不過 那1% 實在還是有點太高 09/18 12:35
6F：→ joulin :機率應該要更低才對 是說我最近也有一些疑惑 09/18 12:35
7F：→ joulin :找時間寫篇文章問問大家的意見 09/18 12:35
8F：推 joulin :Ｌ大有沒有什麼好的軟體可以專門checksum的？ 09/18 12:37
我之前是用QuickSFV，不過現在很少用。
因為沒有意義阿。
大多情況下，知道檔案損毀沒有意義，除非你的備份剛好能用上。
※ 編輯: Litfal 來自: 220.135.179.10 (09/21 07:34)