作者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)