不想BT動到其他硬碟，現在都是在這個硬碟下載完，自動停止後才手動抄去其他硬碟，而也不是上傳影響下載
現在的SSD同時讀寫時，不會變慢嗎？
BT 分塊下載中是很散亂的(每個 peer 用戶要的地方不同) sdd 強項不就是 4k 存取檔強過傳統碟, 循序更不用說, 拿來算哈希嚇嚇叫…
試一下 nas <-> ssd 互傳… 結果是 nas 傳統硬碟是餵不飽
ssd 的速度… ssd (sata 3 可跑 500Mbytes, 同時讀寫好像也有 200Mbytes )
試著花園找一個熱門種子, 下載到本機 ssd 系統碟, 感覺也是喝涼水… 一整個順…
你看我貼圖瓶頸都在弱弱 cpu (省電)… 其他I/O都還好…
你也可以路徑指到其他硬碟小測看看, 看是用到硬碟王, 還是其他問題…
嘿嘿… 最近才入手 1TB 也差不多這價便宜一點… 用來取代虛擬機的底層, 舊的 ssd 128G (用五年,健康率 90%) 換去當路由器的 swap, 跟一些外掛服務…
姑且換個舊SSD來下載，算是workaround
寫入同時不斷讀取又不是上傳這點，真的沒有辦法檢查一下是讀取什麼，避免讀寫同時進行？
猜測背景當時可能在算3份哈希表會用到大量讀取…
但不是應該整個任務下載完後才計算？
完成後會check
实际上每下载完成一个分片都会立即计算哈希值，如果错误就立即丢弃。其它 BT 软件基本是这样，比特彗星应该也差不多
猜测很可能与计算哈希有关。utorrent 有个功能 diskio.smart_hash，即下载完成的分片会在写入硬盘前，在内存中计算哈希，避免重复读取硬盘，不知 BitComet 有没有类似功能。 @wxhere15
如果没有这个功能，硬盘负载相当于加倍了？…
实际使用中发现 BitComet 下载时总会产生相近速度的磁盘读取，而 utorrent 2.2.1 和 qBittorrent 4.1.9.1 都没有这个行为。
用 Windows perfmon 监视硬盘读写速度，可见 Bitcomet 的读取曲线和写入曲线几乎重合，而 utorrent 和 qBittorrent 只有写入曲线，读取曲线几乎为零。（测试期间关闭上传）
改天再测试一遍截个图上来看看
換 ssd 讀寫效率多一倍… 先前網路還會因 io 忙碌停頓下來嗎?
沒有戰車電腦, 建議選預設… 取消表示要當場算(不確定算3份還是1份)… 下載過程中, 加重cpu&io使用資源…
都下載完就直接上傳做種, 沒必要這嚴謹, 重算哈希…
而且彗星預設也是 false
实际使用中发现 BitComet 下载时总会产生相近速度的磁盘读取
寫什麼讀什麼，感覺應該就是這個問題了
換 ssd 讀寫效率多一倍… 先前網路還會因 io 忙碌停頓下來嗎?
這沒有了，硬碟使用還不到50%
沒有戰車電腦, 建議選預設… 取消表示要當場算(不確定算3份還是1份)… 下載過程中, 加重cpu&io使用資源…
hash check if file changed, 雖然不確定file changed是不是指寫入硬碟，但true是check，false才是不check吧？
所以網速已沒有被IO拖慢? 另外你的設定與 Bitcomet 預設顛倒…
if file changed 預設是 true (建議下載前先算哈希,如果檔案內容有異動)
check on finished 預設是 false (感覺沒必要 true)
bitcomet_options [BitComet Wiki]
bittorrent.hash_check_if_file_changed (Since v1.26) :
This value is set to “true” by default. When BitComet finds any change in downloaded files at start-up, it will do a hash-check automatically, ensuring the download to proceed normally.
file changed 應該不是指寫入硬碟吧，不管true false都有讀取
估計是是指改變下載文件列表吧：
另外，這個forum是官方的？維護的師兄/大佬有沒有在看？
可能是指文件元数据等参数改变，如修改时间变动，或文件大小不符
例如某些媒体文件索引程序会自动扫描硬盘，导致影音文件元数据变化。这种情况下可以将彗星下载目录加入它的排除列表，或禁用彗星的 bittorrent.hash_check_if_file_changed
wxhere15 是官方维护人员，经常查看论坛并回复大家的建议，不过新年以来似乎放假了 
耐心等几天等大佬回复
这个论坛是中国地区官方，中国地区唯一的一名开发员 wxhere15
这个是非中国地区官方 http://www.cometforums.com/
开发员有以下这些 Staff Directory - Comet Forums
这里有论坛管理员 Top Members - Comet Forums
感谢反馈，观察得很细致。彗星磁盘写操作其实设置了一个等待队列大小上限，如果下载速度超过磁盘写入速度太多，导致内存消耗太大，就会暂缓向其他peer的下载请求，避免内存不足。等数据写得差不多了再继续请求下载。这个过程反复发生就很容易导致出现流量上下起伏的现象。
呵呵大神放假回來了… 這網站還是有你在比較熱鬧… 不然感覺一攤死水… 不好玩!
感谢反馈。经查，BT下载磁盘写入时会有等量的读取操作，是由于开启了一个磁盘数据校验的功能造成的。新版会改为默认关闭，就不会有这个现象了。
1個讚
感激！…还想问一下，这里说的“磁盘数据校验的功能” 和刚下载完成的分片校验是一回事吗？
不是一回事。分块数据下载完后会先进行hash检查，没有错误再写盘。