|
||
|
Golden Member
 
加入日期: Aug 2004
文章: 2,892
|
主控太爛 然後大量小檔本來就是一個會卡IO的罩門
__________________
此文章於 2020-05-02 11:07 AM 被 MAXX228 編輯. |
|||||||
2020-05-02, 11:05 AM
#11
|
|
|
Advance Member
  加入日期: Oct 2006
文章: 458
|
剛剛用軟體 Trim 完後
試試刪除 7000個小檔 畫面首先跑出 "準備刪除" 等了將近 30秒 他才說 準備工作完畢 他才開始刪除 @@ |
||
|
2020-05-02, 11:38 AM
#12
|
|
|
Major Member
加入日期: Mar 2013
文章: 112
|
以下是美光的建議,專治反應遲鈍的SSD,實作對
其它廠牌亦有療效. 1. 備份所有檔案出來 2. 刪除所有分割區 (***此步驟會刪除所有資料) 3. 建一新分割區含整顆SSD所有容量 4. 刪除此新分割區 經驗談:至此已完成對整顆SSD的TRIM,SSD恢復活力. 5. 建立最後要使用的分割區,但在結尾端保留10%~20%容量 不用,作為OP. 如120GB保留20%不用,只建96GiB(或102GB 10進位)的分割區. |
|
2020-05-02, 11:42 AM
#13
|
|
|
Advance Member
加入日期: Oct 2006
文章: 458
|
引用:
我發現了一個重大發現 (1) 資料夾A 有 7000個小檔 , 斷斷續續 進行過 50次 集體式 寫入動作 (附加方式寫檔) (2) 資料夾B 有 7000個小檔 , 只進行過1次 集體式 寫入動作 刪除 (1) 要花 30 秒 刪除 (2) 要花 5 秒 看來好像是因為 (1) 反覆附加寫入 導致碎片太多 而 lag ?????? 引用:
如果我的 SSD lag 真的是因為粹片太多 , 那用你的方法肯定有效 !! (等於是在重組硬碟) ..... 此文章於 2020-05-02 11:54 AM 被 quickcccc 編輯. |
||
|
2020-05-02, 11:44 AM
#14
|
|
|
Advance Member
加入日期: Oct 2006
文章: 458
|
引用:
請問你說的 "作為OP" OP 這名詞是什意思 ? |
|
|
2020-05-02, 11:50 AM
#15
|
|
|
Major Member
加入日期: Mar 2013
文章: 112
|
引用:
原文網址： https://kknews.cc/zh-tw/digital/bgmnpb6.html Kingston說法 https://www.kingston.com/tw/ssd/overprovisioning |
|
|
2020-05-02, 12:18 PM
#16
|
|
|
Major Member
加入日期: Mar 2013
文章: 112
|
引用:
還有XP不支援TRIM,WIN7(含)以上才有. |
|
|
2020-05-02, 12:21 PM
#17
|
|
|
Advance Member
加入日期: Oct 2006
文章: 458
|
引用:
OK 感謝解說 !! 目前使用 Win7 x64 引用:
再請問 尾端保留10%~20%容量 後 這塊OP區域是否要進行格式化 還是 不能讓他被格式化 ? 此文章於 2020-05-02 12:33 PM 被 quickcccc 編輯. |
||
|
2020-05-02, 12:27 PM
#18
|
|
|
Major Member
加入日期: Mar 2013
文章: 112
|
引用:
放著就好. 還有,OP務必是在SSD尾部,而不是SSD開頭. 此文章於 2020-05-02 12:49 PM 被 JMPY 編輯. |
|
|
2020-05-02, 12:47 PM
#19
|
|
|
Advance Member
加入日期: Oct 2006
文章: 458
|
引用:
收到! 3Q!! |
|
|
2020-05-02, 01:23 PM
#20
|
|
