順便補充一下........
我的經驗.......在 utorrent 做 hash.......
如果是程式回復後自動執行 hash.......看似同時處理很多檔案........
其實應該只是依序一個一個做處理才對.......並沒有真的那麼操.......
在硬碟上會感覺很操........只是因為硬碟做 random access 天生就慢又聲音大......

如果是手動一個一個 hash 的話會怎樣我就忘了........
印象中好像會並行處理........不過實在想不起來是不是真的這樣........

另外 utorrent 本身就已經有 coalesce write 參數...........預設 2MB........
以 SSD 一般 block 大小應該已經夠了........
再加大不一定能降低多少寫入放大........但改太小就肯定沒好處.........

而增加快取設定值這個主要是針對網路速度比較快的話........
檔案下來要有一定記憶體空間整理......做 coalesce write 才好處理.......
另外也減少過於頻繁的讀取........

SSD 可不可以跑 bt.........應該沒什問題.........
軟體設定的好.......自己又會看寫入量評估壽命........那就沒問題.........
不過實在不划算就是.......

ramdisk 多檔下載 隨便測試BT 直接分配空間

5~10GB 大型單檔家常便飯

不是很愛延遲寫入嗎?? 載個檔案好幾GB起跳
我看你硬碟要配多少記憶體容量延遲寫入啊?? :stupefy: :stupefy: :stupefy:

兩位都是一時瑜亮，好比許攸跟田丰，別爭了 :D

繼續秀下限
你真以為延遲寫入只是晚一點寫入而已喔？

utorrent 正常狀況下除了種子是逐個 hash......種子裡的檔案也是一樣........
我覺得這樣子比較不會給傳統硬碟造成太大壓力.......
這樣在 hash 的同時其他正常的檔案都可以繼續上下載......
除了手動以外........我會在檔案在不同硬碟時每個硬碟同時做 hash.......

而你說的意思是 transmission 在 hash 一個包含很多檔案的種子的時候.......
那些檔案是同時做 hash 嗎?.......不太確定你的意思.......
是的話.......在傳統硬碟上效率不會很差嗎........? 讀寫頭很忙.......也未必快........
在 SSD 可能會增加效率吧........不過感覺似乎也不是很有必要.......
畢竟正常來說不應該沒事在 hash.......

應該這樣說吧
就我對bittorrent協定的粗淺了解
我們下載某個種子的時候
假設檔案數>1 ，那這個種子在製作的時候
會被切成很多個小份，例如1/100(實際上比這更多)
然後每一個等份取雜湊值，這個過程就是hashing
並記錄在種子的訊息中
開始下載後，過程中可能發生一些如斷電之類的意外
運氣不好，bt client會提示種子檔案不正確
假設這種子當中的1byte壞掉，位置在53/100這等份
經過hash檢查，我們不用重新下載所有的100/100
只要再下載53/100一次就好

但是檢查的過程可能是所有100/100
同時hash，所以會出現前面提到的那些問題

Bit Torrent切割值不是照當下連線數決定的，而是一開始製作種子就設定好了，假設每一區塊的值是1MB，就必須完成該區塊1MB完整的下載才算完成，也因如此，快取絕對是有效的，可以避免很多未完成的不必要寫入。

intel的540系120G在PC家
居然從之前的1500漲到1千七百多了

記得當時是用μTorrent這套bt軟體
一次大概十個任務同時下載
系統是WIN7 X64 I5 16G RAM
μTorrent內也有設定快取
bt和系統都設在簡單連512G
因為家人常常直接把機器關閉所以一開機就會自動HASH
不過大概這樣玩半年SSD就掛掉了
寫入量我猜每天應該有兩三百G吧

常用還原軟件，也會造成SSD短命！

因為還原一個磁區，都是數以百GB計！