分類彙整: P2P

死鬥.Silicon Image 3114

為了完全發揮出A8N-SLI Deluxe的實力,長久以來都企圖想要達成"全SATA化",但是最後總是無法跨越的藩籬-Sil3114晶片的相容性問題,終於找到解答了。

簡單講,Windows是靠inf檔來辨識Driver的。
所以即使晶片相同,裡面也有可能有一些User並不清楚的狀況,造成相容性問題。

3114的Driver就算是頗典型的狀況:
手邊的A8N-SLI Deluxe上面附的3114,ID為SUBSYS_81671043
(請由硬體管理員的[內容]–>[詳細資料]–>[硬體識別碼]來查看),但是ASUS在網頁上讓人下載的Driver(1.1.0.0)則沒有內含這個ID,其他IHV(如Gigabyte等)的產品即使有使用3114,Driver內的ID也大多有些落差。

那麼,不顧ID能不能使用呢?
很可惜地,不行,安裝之後會hang在Loading Windows….

最後,在WindowsUpdate找到了可以使用的Driver(9234973.cab),包含了相當多不同版本的ID….安裝之後也的確可以使用,順利地進入Windows了。
該版Driver的內容請參閱下列連結:
http://www.download.windowsupdate.com/msdownload/update/v3/static/rtf/drivers/9234973.htm

下載則需要前往Windows Catalog:
http://v4.windowsupdate.microsoft.com/catalog/zhtw/

接著,有一個相當值得注意的地方:
3114的特性,是必須在其BIOS內,將各個獨立的HD都設成JBOD(Single),才能夠讓Windows讀到磁碟….

安裝適合的Driver,以及設好JBOD之後,就可以順利使用了。
話說因為單顆做JBOD與原來的讀寫並沒有任何不同,所以也可以與以前相同地任意插拔改變順序,資料並不會流失。

[Share] DB法的價值

昨天Share的Folder崩壞,其實還有一些絃外之音:
崩壞的Folder引發chkdsk,然後usb鍵盤支援問題再度造成來不及阻止,
所以就是該槽大堆圖片的metadata遭到重新連結,成為有檔讀不到圖的狀態;外加數個ISO也遭到摧毀。

我超級想把chkdsk殺掉的啊….. = ="不過我們把這放到一邊,總之題目是指Share的DB法,在此特別提一下DB法的作用。

DB是Share的一個資料結構之一,指的是類似"經手過的目錄列表"之類的東西,下載過的檔案可以透過DB,找尋多個來源來復原之。
而在Trigger頁面,我們可以發現有選項是"可以只下載DB",作用類似"先行把網路上曾經有過跡象的檔案全部收集起來"….所以透過先行增加DB再搜尋的方式,可以大量地增加可能搜尋到檔案的機會。

昨天小光和我各自都認知到了DB法的威力。
比方說上面提到了,我的Share已經整個被摧毀了。
不過在我以重新開始的前提下,DB法維持約半小時後,搜尋一般小說的result達1600個以上。
小光本來覺得"一般小說本來就可以搜尋到很多啊….",他當時的搜尋結果是約五千個;不過當他看到取消DB之後的搜尋結果為16個的時候,他似乎也得承認DB法比他想像的有效多了。

當然,DB本身會佔據空間,Share預設的Key存量為一萬個,所以有需要的話可以增加Key存量設定。

一週硬碟死兩次啊….

首先開宗明義:WD不可信宣告。
上周末才掛,這週末又掛一次。ShareDown恢復之後損失三個檔案,剛下的三個大檔幸好沒事;
不過看來是非得把這個硬碟給送修了,即使先前認為Table Crash並不是硬體問題….