Victor’s Blog

今天才發現我弄錯了，昨天那篇提到的只是不會 cache，不會導致 kmem_map too small。

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/opensolaris/uts/common/fs/zfs/arc.c

version 1.4 調了一些參數試圖緩和 memory 用光的情形…

i386 跑 zfs 很容易會遇到 kmem_map too small，然後 panic。（搞錯了，不是這個 patch，請看下一篇）

剛才 rafan 貼了一段 message 給我

Change type of kmem_used() and kmem_size() functions to uint64_t, so it
doesn’t overflow in arc.c in this check:

if (kmem_used() > (kmem_size() * 4) / 5)
return (1);

With this bug ZFS almost doesn’t cache.

Only 32bit machines are affected that have vm.kmem_size set to values >=1GB.

src/sys/compat/opensolaris/kern/opensolaris_kmem.c#rev1.3，還有 diff。

搞笑 XD

這一兩個學期來，實驗室買了幾台 RAID 來裝大家實驗用的資料。幾個禮拜前，file system 爆炸，我們損失了不少資料

重點提要：

1. 同一個 channel 不要接超過三組 RAID
2. 同一個 channel 不要接不同廠牌的 RAID
3. SCSI 線跟 terminator 是消耗品

接 RAID 的機器是跑 FreeBSD 7.0-PRERELEASE。一開始發現異常，是 zfs 說他寫進去的資料跟讀出來的 checksum 不一樣，於是就爆了三個 zfs 的 partition。接在同一個 SCSI channel 的 RAID 共有四台，三台 proware 跟一台 festora(?)，zfs 叫有 error 的是其中兩台 proware，所以我們懷疑是 RAID 本身有問題。

後來找了 proware 的工程師來幫我檢查 RAID，他說我們接四組 RAID 太多了… 小時候學到的 SCSI device 不就是要用串的嗎，可是沒想到四組就算太多 orz 而且最好不要把不同廠牌的 RAID 接在一起… 因為訊號可能會互相干擾 @@ （我以為這應該有標準，可是看起來接在一起的確不太好…）

於是我們把四台 RAID 分到兩張 scsi 卡上（之前因為某些原因沒這麼做），其中一個 channel 是一組 proware + 一組 festora。然後今天下午一直發現 zfs 又開始抱怨了… 一個月前這麼接還沒事的耶 orz 真是 ooxx 現在改成三組 proware 接同一張 scsi card，另一組自己接一張，zfs 就不叫了。

(%&$#@!*(%!#@^!)

今天去故宮看到的 XD

我目前在學校有個 project 需要從 flickr 抓取大量資料，包括照片的 tag、owner 等 meta data。但是我發現我拿到的 data 怪怪的，一些常用的 tag 竟然只有幾百筆。我用的 API 是 flickr.photos.search，它可以接受很多條件，然後傳回符合的照片，其中有兩個條件是最早跟最晚的上傳時間。於是我只好把時間間隔縮小很多。

直到昨天，我收到一封恐嚇^H^H警告信，說明 query return 回來的 offset 不能超過 4000，換句話說頂多拿到 4000 筆左右的結果。API 的文件沒提到這件事，query 傳回來的 status 也都是正常 …

還好我抓得夠暴力(?)，不然如果沒收到這封信，之後學校的實驗就可能是錯的了

Greetings!
We have noticed that the api key 72157602728288126
registered to you is sending very large offset queries to
us.
example (offset=16893165)
Can you please check your usage and reconsider using these
high offsets? They are heavy/costly queries that tax our
backends.

Also to note: the search backend currently will not return
any results greater than offset 4000.

If you could limit the max offset to below 4000, we would
greatly appreciate it (and not have to disable the key -
not because we want to, but because our backends can’t take
very much of it).

Thanks!
- Flickr Team

太帥了，竟然有 .museum 這種 top level domain!

首頁: http://musedoma.museum/
所有 second level 的列表: http://index.museum/

Wikipedia 的 Top level domain list

前幾天發現 iGoogle gadget API 的 _IG_FetchContent, _IG_FetchXmlContent 和 _IG_FetchFeedAsJSON 開始支援 Big5 了! 以前寫 gadget 時，只要遇到要抓取 Big5 的網頁，就沒辦法用。因為之前這三個 function 假設網頁的內容是 UTF-8。不過前幾天我抓了一個 Big5 的網頁，發現內容竟然正常了。看來他現在會幫你猜網頁的 encoding 了! 這樣開發 gadget 就方便多啦。

Mapplet 也是一樣，因為 mapplet 也可以用 gadget 的 API。

也許 Google 正在辦的比賽會有更多的 idea 跑出來。

今天下午去中研院看一個數位典藏的展覽，到下禮拜一之前展的是一些地圖、歷史地圖的東西。展出的單位是中研院 GIS 實驗室。

裡面還有幾張地圖是國民政府來台之後，跟美國合作，偷偷由中華民國飛行員開美國的偵察機 (好像叫 U2?)，飛到大陸那邊去照的數十(百?)萬張地圖。而且解析度還滿高的，不知道有沒有比 google earth 清楚。之前國家不允許這種東西展出，所以現在應該是剛出來見世人吧。

他們用了相當多 google earth 跟 map 來作 demo 平台，加上 multi-touch 的桌椅組 (MITSUBISHI 的 DiamondTouch) 配合 google earth 做簡單的平移、旋轉、跟縮放。

還有 google map 上古今地圖對照，可以看你家幾十年前或一百年前是農田還是什麼的。我們有清楚看到台北市的市民大道以前是鐵路，還有基隆河截彎取直前後的樣子。

其中我覺得最酷的是一個 3D 瑩幕 (他們買來的)。他是一個特殊的瑩幕 “直接”接上顯示卡，畫面上的 3D (OpenGL, DirectX) 就直接變成立體 (當然視角很有限)。身為 CMLab graphics 組的，當然要知道原理啦。我猜他應該是去讀 z-buffer! z-buffer 是顯示卡上記錄瑩幕上每一個 pixel “深度 (離眼睛的距離)” 的記憶體，3D 的程式通常會用到。於是有了景深，這個瑩幕就可以對左右眼射去不一樣的光線 (坐在椅子上)，看起來就有立體的感覺!

另一個也很酷的是 3D 印表機 (只展出影片跟成品 不過印表機本身不是他們做的)。他是在一塊板子上一層一層塗上粉，要留下的地方的粉上膠、不留的不上。一層一層塗完之後把粉倒掉，剩下的就是那些有上膠的部分。3D 的模型就這麼印出來了!

這一個下午真是不虛此行! 下禮拜一之前，如果大家有空，可以去看一看 地點在中研院圖書館。