|
||
|
Major Member
 
加入日期: Sep 2005
文章: 105
|
有實驗精神一點，買一顆硬碟回家操操看，總不會連自己眼睛也不相信吧XD
__________________
|
|||||||
2007-07-23, 11:25 AM
#11
|
|
|
Major Member
加入日期: Dec 2004
文章: 261
|
散熱做好，開機時不要動到主機，相信硬碟可以活很久的。
|
||
|
2007-07-23, 11:36 AM
#12
|
|
|
Power Member
加入日期: Apr 2007
文章: 506
|
引用:
依照快取緩衝寫入讀取預測功能來看，使用足量快取或緩衝是可大幅減低讀寫次數。 例如10個區塊中，共有5個區塊時常被讀寫、3個區塊偶而更動、2個區塊不作讀寫 依照快取概念會以五個常態性使用區塊為優先快取，若容量足夠時，則另外對三個區 區塊作快取動作。 此時，需讀取區塊上相同資料時，會直接由快取端傳遞資料，而不再重複至磁碟上讀 取，而對其區塊寫入時，仍可以快取原則、當快取到一定容量時再行寫入磁碟中，如 此，皆可大幅降低磁碟讀寫次數。 以BitComet來說，加大與減小緩衝量可在 總合統計 中的資訊看出差異，如： 硬碟讀請求次數總計：8154 (頻率：1.4次每秒), 實際硬碟讀次數：834 (頻率：0.3次每秒), 讀命中率：89.7%硬碟寫請求次數總計：69429 (頻率：11.5次每秒), 實際硬碟寫次數：1864 (頻率：0.5次每秒), 寫命中率：97.3% 以第一列為例，前者8154次的讀取請求為完全無緩衝或快取下應有的磁碟讀取次數，當使用足量緩衝／快取時，則降低到834次。 大多數的P2P軟體（串流除外）都是以微小區塊為單位，且為數眾多的分散在磁碟上（簡單的想法，可以看作數量龐大的小檔案），當有優秀的快取策略與充足的緩衝時，將可大幅減少持續性的 搜尋 定址 讀取 寫入，的確是可大幅減低磁碟運作次數，也藉此降低使用量而達到延伸壽命的可能。 所以這並非錯誤概念。 有興趣的話可去參考快取架構相關書籍，書店不難找。 |
|
|
2007-07-23, 12:02 PM
#13
|
|
|
Major Member
加入日期: Apr 2005 您的住址: 台南
文章: 121
|
易拓 60G 92年開始BT+EMULE到現在
出現共震問題而已~~
__________________
|
|
2007-07-23, 03:16 PM
#14
|
|
|
Junior Member
  
加入日期: Sep 2002 您的住址: 台北 / 高雄
文章: 834
|
?!個人覺得自己有影響啦@@!
個人常下載BT+玩遊戲 剛入手之時 玩遊戲LAG次數少 經過2年多BT折磨 同樣情況下 LAG次數增多 且硬碟讀取聲稍微變大 ------------------------ 可能是學校...水管太大了 載太多...一_一"
__________________
努力，是讓"努力的極限"趨向增加到於"成功"。創意，讓走向極限的路，與眾不同。 2013.11.6 |
|
2007-07-23, 03:22 PM
#15
|
|
|
Major Member
加入日期: Aug 2004
文章: 161
|
怎麼可能不會?
引擎操久了都會壞更何況是硬碟 但是保養維護得好 用個兩年都不是問題 1. 電源供應器足夠 2. cache規劃好 |
|
2007-07-23, 03:26 PM
#16
|
|
|
Golden Member
加入日期: Oct 2002 您的住址: 台北市
文章: 3,940
|
個人是覺得只要散熱做的好,
應該問題就不太大, 而且偶爾也會讓主機關機一晚 應該也還好... 通常會掛的時候是周邊環境的問題(如POWER不穩,硬碟運作時溫度過高,所使用的插座電壓電流不穩定,容易震動到等) 而週邊環境好,硬碟還會掛掉的應該不多吧!  |
|
2007-07-23, 04:44 PM
#17
|
|
|
*停權中*
加入日期: Mar 2007
文章: 122
|
弄一顆專操BT的硬碟
就算操壞了 BT的資料也不是多重要的(AV.Movie.Hgame...) |
|
2007-07-23, 07:11 PM
#18
|
|
|
Major Member
加入日期: Sep 2005
文章: 115
|
小弟直接以c槽來下bt，這會不會很危險，很容意壞，還是另接外接硬碟？
引用:
|
|
|
2007-07-24, 12:38 AM
#19
|
|
|
Senior Member
加入日期: Feb 2005
文章: 1,242
|
引用:
壞再換一顆...現在硬碟都當耗材在用... 保固期內送原廠...  |
|
|
2007-07-24, 02:53 AM
#20
|
|
