查看積分策略說明發表回覆
Discuz! 代碼
提示插入
直接插入
說明訊息

插入粗體文本 插入斜體文本 插入下劃線 置中對齊 插入超級連結 插入信件位址 插入圖像 插入 flash 插入代碼 插入引言 插入列表
刪除線 直線分隔線 虛線分隔線
    
添加文字底框
內容 [字數檢查]:

表情符號

更多 Smilies
字型大小 |||
溫馨提示:本區開放遊客瀏覽。


文章關鍵字 : [功能說明]
(關鍵字可加強搜索準確性, 如關鍵字多於一組, 請以 , 作分隔, e.g. : 阿笨,shiuh,第一笨)

 關閉 URL 識別 | html 可用
 關閉 表情符號 | 表情符號 可用
 關閉 Discuz! 代碼 | Discuz! 代碼 可用
使用個人簽名
接收新回覆信件通知
推薦放檔網絡空間

檔案(Torent, zip等)
  1. freedl
  2. multiupload
  3. btghost
  4. 便當狗
  5. mediafire
  6. pillowangel
圖片(JPG, GIF等)
  1. hotimg
  2. tinypic
  3. mousems2
  4. imageshack
  5. imm.io
>>>歡迎推薦好用空間


最新10篇文章回顧
hck819

 發表於 2007-9-27 11:42 PM

題外話
現在硬碟那麼便宜了(其實從2.3年前就開始大幅降價)
小弟目前是4顆硬碟在跑
C:作業系統相關應用程式(辦正事用的)
D:pagefile+所有遊戲.有的沒的應用程式(玩樂用)
E:養eMule.跑BT(p2p專用)
F:大容量檔案存放區(音樂.高清影片.DVD ISO,總之還沒燒出來的都放這)

基本上現在一般16M緩衝的HD都很耐操了(事實上從8M開始我覺得都很耐操)
其他有關讀取.寫入效能就不在這邊討論
(養動物就是要用便宜大碗的硬碟,舉凡現在的320G.400G.500G,滿多顆c/p值都滿高的
,而像7200.10新一代單碟250G.密度高.讀取快,用來養eMule實在很浪費
,效能快的硬碟應該要拿去當系統碟會比較適合些,當然經濟狀況許可例外)

總之eMule的Temp跟Incoming放在同一磁碟,個人覺得並無不妥
會分開放除非硬碟太小,否則無此必要


alanzeratul

 發表於 2007-9-27 08:34 PM


引用:
Hygeia寫到:
根據經驗我覺得temp在完檔時並不「只」做移檔的動作...
經測試 Liaokk 大的方法很值得一試~(killer00大所講的好像也是同一件事的樣子~
記得以前看過一篇文章有講到eMule運作原理....但我不太記得細節,所以在這邊我只分享我個人經驗~

我剛剛測試了「主程式+temp」在一部硬碟,「incoming」在另一部硬碟的作法(皆不在系統碟),我覺得效果還不錯~
大家都覺得,temp在完檔時有「移動」(複製+刪除)的動作,把檔案移到Incoming資料夾下面...而這個動作很操硬碟...
但我多年來一直採用「主程式+temp+Incoming」皆在同一硬碟、同一partition的配置.........
事實上,如此的配置當temp在完檔時,硬碟仍然有非常明顯的讀寫動作,而且至少5、6秒...(時間和檔案大小成正比)

那是由於完檔後要再把檔案切細一變,確定檔案ID相同


平凡小任

 發表於 2007-9-26 06:48 PM

其實為什麼要分磁區
甚至搞獨立硬碟
還不是為了分擔風險
因為硬碟什麼時候要掛
沒有人知道
儘管硬碟的buffer越做越大
對資料的存取也越來越有效率
不過從以前到現在的習慣卻是不能改變
而關於作業檔
我記得有軟體是可以把他橋到記憶體上去的
因為現在記憶體便宜
容量又大
而記憶體要壞的機率→很低
總之以上全部看個人使用習性
其實運氣才是王道...


killer00

 發表於 2007-9-26 05:43 PM

其實這是有問題的,分幾個層面來說,首先,你要搞清楚什麼叫【外部碎裂】,弄懂再談檔案是否離散,而不是

引用:
liaokk寫到:
硬碟的性能在連續讀寫時,特別出色。

把電騾的「temp」和「Incoming」兩個檔案夾,設置在不同磁區,可以不靠「硬碟重組」軟體,就讓「Incoming」檔案夾的檔案,全無離散化,保持在最佳狀態。

況且你這講法有兩個限制的前題存在:

1.「Incoming」所在的位置是沒有離散狀況(完全沒資料或者重組過)。

2.「Incoming」內的資料永遠不再更動。

當同時滿足這兩個前題後,【外部碎裂】造成的檔案離散狀態才不會存在。

不過這種作法是所有作法中效能最低的,這點可由MS得證,運作模式我前面也提供了,不再贅述。


引用:
liaokk寫到:
若「temp」和「Incoming」置於同一個磁區,那完檔時的移檔動作,就只是表面功夫。離散化的暫存檔,換個名字移入「Incoming」檔案夾,檔案實體還是離散的原狀。

這也是有前題的:

當檔案在「temp」時已經是離散狀態,當然在「Incoming」時也不會改變狀態,理由很簡單,在同一磁區下,檔案的搬移不過是將指標做變更,檔案本身沒有移動,所以才會一瞬間就完成所謂的【搬移】工作。

反過來說,如果檔案在「temp」時已經是連續的,沒可能在同一磁區下做搬移後,變成不連續。

建議你好好讀讀檔案系統相關的文章,我用Google找了一份給你:檔案系統管理

簡單一句話:檔案搬移與檔案離散無關,檔案的離散是儲存地點的環境造成。


引用:
liaokk寫到:
第二段的作法,適用於(長期)供檔或分流;第三段的作法,適用完檔就燒光碟,燒完就刪檔。

至於「電騾主程式」檔案夾中,Known.met、Clients.met,只要有在下檔案,就無可避免會持續離散化。最好不要和作業系統同一磁區。如果你喜歡第二段的作法,那麼不要和「Incoming」同磁區,是首要考量。

什麼第二段、第三段

什麼【Known.met、Clients.met,只要有在下檔案,就無可避免會持續離散化。最好不要和作業系統同一磁區】?

Known.met、Clients.met這兩個檔案大小都不會超過5MB,就算離散也很有限,就算用重組軟體對單檔重組影響也不大,更別說拖累作業系統,不相信的人用一些可以看單檔狀態的重組軟體看看,就知道我所言屬實。(我知道 O&O Defrag、PerfectDisk 都可以看單檔的離散狀況)

想瞭解什麼是離散的檔案,就去看看我前面提供的【檔案系統管理】PDF檔的P.5-14 圖片,是描述檔案的擺放,我用該圖舉個簡單的例子:

現在系統要從圖中4號的位置放一個名叫 Show 的檔案,檔案長度20,所以結尾會是在36號的位置,因為中間有3個已存在的檔案,所以 Show 會被分成4段,一般說法就是離散的檔案,正確講法是檔案系統中的【外部碎裂】問題。

PS:附帶說明,我前面就有講過,主程式擺那邊都不沒關係,這是因為主程式被讀入記憶體後,除了要寫回硬碟的紀錄檔必須定時寫回之外,其餘的皆存在於記憶體中,運作過程中完全不受硬碟影響,當然也沒有什麼“最好不要和作業系統同一磁區”﹍云云的論點。

如果說連這謬論都成立,那分頁檔(全系統中最離散的檔案)就不應該在同一硬碟的情況下,還與作業系統擺在同一磁區了

[killer00 在  2007-9-26 05:47 PM 作了最後編輯]


Hygeia

 發表於 2007-9-26 01:48 AM

根據經驗我覺得temp在完檔時並不「只」做移檔的動作...
經測試 Liaokk 大的方法很值得一試~(killer00大所講的好像也是同一件事的樣子~
記得以前看過一篇文章有講到eMule運作原理....但我不太記得細節,所以在這邊我只分享我個人經驗~

我剛剛測試了「主程式+temp」在一部硬碟,「incoming」在另一部硬碟的作法(皆不在系統碟),我覺得效果還不錯~
大家都覺得,temp在完檔時有「移動」(複製+刪除)的動作,把檔案移到Incoming資料夾下面...而這個動作很操硬碟...
但我多年來一直採用「主程式+temp+Incoming」皆在同一硬碟、同一partition的配置.........
事實上,如此的配置當temp在完檔時,硬碟仍然有非常明顯的讀寫動作,而且至少5、6秒...(時間和檔案大小成正比)
如果完檔時僅需移動檔案到同一partition的另一個資料夾(Incoming),那麼硬碟沒道理需要跑成這樣,應該是一兩秒就結束了,不是嗎?
所以我認為此時還有別的事在進行,絕不只有「移動」而已。
說這幹嘛呢?
因為如果不只有移動,而是還有其他動作,那「主程式+temp在一個硬碟,Incoming在另一個硬碟」的作法的配置的「壞處」就會減少~
結論是,我發現即使temp和Incoming不在同一partition,而是在『不同硬碟』,完檔時的「動作」所需時間並沒有明顯增加~
換言之,那個我一直提的「其他動作」才是讓硬碟不斷讀寫的主要原因,檔案移動的影響並沒有之前想像的『嚴重』~
這個「其他動作」,我沒記錯的話,很可能是『重新切細檔案』之類的動作。

既然完檔時硬碟無論如何都會有這樣的動作,同時檔案在不同硬碟間的「移動」也沒有想像中激烈和耗時,
那Incoming(目標資料夾)的「連續性」(無離散)就會有好處了~
我個人都是直接開Incoming裡的檔案來用,所以當temp和Incoming在同一顆硬碟時,它必須負責讀(上傳+播放)和寫(下載)~
當我把Incoming放到另一顆硬碟後,不僅上傳速度明顯提升,播放檔案時對上傳下載速率也幾乎沒有影響。
(之前在播放一些大檔案時,上傳、下載速度都會往下掉)
也就是說,除了小部分未完成擋的上傳外,有「主程式+temp」的硬碟幾乎只要負責下載(寫),而主要的上傳和播放(讀)則是由另一顆硬碟在做。
這種上傳下載速率的改善在大量下載時最明顯~
(譬如說在下載對岸的rmvb檔時,只要我一用Incoming裡的東西,下載就會從幾百掉到幾十~)
總而言之,『硬碟分工』在效能上的加分比「檔案移動」的減分來得明顯。
(有些人是不是已經再想之前的舊硬碟要不要拿出來試試~?

小任大大的外接盒故障情況我在半年前也遇過...(Maxtor外接式硬碟,純鋁外殼)
當時突然發生「磁碟空間不足」,我還在想說怎麼可能...結果有主程式+temp+Incoming的硬碟『消失』了...
(到"磁碟管理"裡面才發現我『多』了一顆「未格式化硬碟」......
(當時eMule竟然還在跑(上傳)....
所以後來就不太敢用外接盒了.....

以上供大家參考囉~

[Hygeia 在  2007-9-26 12:28 PM 作了最後編輯]


liaokk

 發表於 2007-9-24 12:40 AM

硬碟的性能在連續讀寫時,特別出色。

把電騾的「temp」和「Incoming」兩個檔案夾,設置在不同磁區,可以不靠「硬碟重組」軟體,就讓「Incoming」檔案夾的檔案,全無離散化,保持在最佳狀態。

若「temp」和「Incoming」置於同一個磁區,那完檔時的移檔動作,就只是表面功夫。離散化的暫存檔,換個名字移入「Incoming」檔案夾,檔案實體還是離散的原狀。

第二段的作法,適用於(長期)供檔或分流;第三段的作法,適用完檔就燒光碟,燒完就刪檔。

至於「電騾主程式」檔案夾中,Known.met、Clients.met,只要有在下檔案,就無可避免會持續離散化。最好不要和作業系統同一磁區。如果你喜歡第二段的作法,那麼不要和「Incoming」同磁區,是首要考量。

最後,提一下電騾的「檔案緩衝區」。在BT上叫「磁碟快取」。只要抓檔不要太貪心(同時下太多檔案),設定得當的「檔案緩衝區」,會讓硬碟工作既不操又有效率。絕大多數的讀寫,都是在操很難操壞的「記憶體」(大陸叫「內存」)。對ADSL上網族來說,每秒讀寫實力幾十MB的硬碟,超出ADSL下載/上傳能力逹數十倍/數百倍。養小動物一顆足矣。


平凡小任

 發表於 2007-9-23 04:53 AM

外接盒有其缺點
那就是外接盒一般適合暫時使用
而不是長期使用
我是傾向買那種類似檔案櫃的case
裡面可以放硬碟
然後介面其實跟桌機一樣
有power不過只單純供應硬碟和風扇
然後透過USB或其他裝置連結你的筆電
當然上面這種是理想
做到這種地步或許你會想說乾脆用桌機算了...XD
不過這是我過來人的經驗
也是我以前使用外接硬碟的經驗
就是使用久了(其實大概一年左右)
整顆硬碟就會突然變成未格式化
然後只好靠r-studio把檔案救出
當然也許是我買硬碟運氣不好(7200轉的IDE,日立製品)
也可能是外接盒太了笑(磬成)
總之自己衡量看看
系統跟ED分開應該會比較好
獨立硬碟比分磁區可能更好
這是在下的感覺
還有外接當然選3.5
第一容量大
第二耐用
2.5會贏在攜帶方便
如果你在學校養BT
你可能會希望像教授一樣帶個2.5硬碟到處跑比較帥
不過他容量沒辦法像3.5那麼大
但是輕巧方便
一點淺見...

[平凡小任 在  2007-9-23 04:55 AM 作了最後編輯]


ATS

 發表於 2007-9-23 01:41 AM

看來是需一準備兩顆硬碟才好
  可是用外接盒難道沒有缺點嗎
  還是安全性的問題
  3.5(要插電)跟2.5(不插電)有差嗎
  謝謝


alanzeratul

 發表於 2007-9-22 09:47 PM

同樓上,temp/incoming放在同一實體硬碟或是磁區就可,當然可以的話錯開系統碟最好
這樣完檔切細後不用再多一個複製完成檔案到incoming的動作
eMule跟Share之類的軟體不同,像後者不管怎樣安排他一定就是複製完成檔案到完成資料夾然後留著暫存檔

[alanzeratul 在  2007-9-22 09:49 PM 作了最後編輯]


kuomika

 發表於 2007-9-22 08:31 PM

已開版的問題來看....其實差異性不大....因為都是同一顆硬碟再存取而已
如果是二顆硬碟的話
以我來說....主程式放在一各磁碟
暫存跟完成檔放同一顆磁碟....
因為下載完畢只是檔案轉移目錄而已.....
如果是不同硬碟...那就會看到HD在狂跑了.....
而且放再同一各磁區...有一各好處是...當空間不足時可以馬上知道...
不會因為完檔後因空間不足而造成還要在那邊刪檔案...


本主題回覆較多,請 點擊這裡 檢閱。



所在時區為 GMT+8, 現在時間是 2024-5-23 01:06 PM
清除 Cookies - 連絡我們 - TWed2k © 2001-2046 - 純文字版 - 說明
Discuz! 0.1 | Processed in 0.022353 second(s), 7 queries , Qzip disabled