[華語, cmn-Hant-TW]

行善里 (Village) 自願降格成行善鄰 (Neighborhood) 了嗎?
[客家話, hak-Hant-TW]
看到有人講 2008 年的 MacBook Pro 官方講可以加到 4GB,毋過實際上可以加到 6GB – 要用 DDR2-667 就是,講實在的 DDR2-667 又貴又毋好買,不過差這 2G 用起來差當多,就花錢加上去了。

正經可以用,毋過要用 1條 DDR2-667 2GB 加 1條 DDR2-667 4GB,本成想要用 DDR2-800 2GB + DDR2-667 4GB,開毋起來。
加 2G 後,開 vm 毋會再古看到硬碟狂轉了,毋過這隻 kernel 是佇該做麼介,食按多記憶體?!

[華語, cmn-Hant-TW]
之前這篇有提到開 AFP 分享以及用 Model Name 偽裝成某種型號的 Mac 的方法,其實用同樣的機制也可以把 SMB 的伺服器包的漂漂亮亮的,而且多這層之後用戶端的 Finder 找分享的速度也會比較快,不管從美觀或實用的角度來看都是值得打開。和那篇一樣有 avahi 或 howl 兩種選擇,設定上也和那篇類似,只是把 AFP 的設定換 SMB 而已。 (SMB 伺服器當然要另外安裝,這邊假設 SMB 本來就通的,沒有的話去 ports 找 net/samba3x 挑一個來裝,samba 設定就不詳述了)
<?xml version="1.0" standalone='no'?><!--*-nxml-*--> <!DOCTYPE service-group SYSTEM "avahi-service.dtd"> <service-group> <name replace-wildcards="yes">%h</name> <service> <type>_smb._tcp</type> <port>445</port> </service> <service> <type>_device-info._tcp</type><port>0</port> <txt-record>model=Xserve</txt-record> </service> </service-group>
smb.services 檔名一樣是可以自訂的,除了 type 要改成 _smb._tcp 外其他和 afp 的設定都相同,細節請參考 AFP 那篇。
"ServerName" _device-info._tcp local. 1 "TXTVersion=1.0" "model=Xserve" "ServerName" _smb._tcp local. 445
用 howl 的話那所有 service 的設定都會在這個檔案裡面,如果 AFP 已經開了的話就直接加上一行 SMB 的設定即可。
值得注意的是雖然平常 SMB 服務是用 139 這個埠,但是 Mac OS X 10.7 Lion 不吃這個埠的 SMB 分享,所以用 445 比較保險。
[華語, cmn-Hant-TW]
因為沒時間、工作進行中、想順便換硬碟、初版觀望一下、等 iCloud、東西還沒整理好這總總理由,雖然第一時間就買了 Lion 但是一直沒去升級他,只有拿外接盒小玩一下而已,畢竟 10.7 的操作哲學和 10.6 有不小差異,而且 xcode 也得升級,所以得找比較空閒的時候,才能開始升級。
這次趁 MBP 送修的空檔順便換了顆硬碟,然後灌新的 Lion 後直升有 iCloud 的 10.7.2 接著把舊的使用者倒過來,經過幾天的陣痛之後目前大致上使用起來是沒啥問題了,照慣例來隨手亂寫一下心得,沒照順序。

[華語, cmn-Hant-TW]
有蠻長一段時間都是用 MCEBuddy 1.x 在定時把 DVR-MS 轉成比較小的 MP4 檔,不過轉檔的缺點是 meta-data 通通沒有,不過就加減用,後來太懶了乾脆就連轉都不轉了,直接買大硬碟硬存 DVR-MS,後來 MCEBuddy 也暫停開發,也有段時間沒去注意他,某天偶然發現他 2.x 開始重新動作,而且 GUI 的 beta 都跑出來了,就來試看看,試的結果感覺不是很好,只要碰到有漢字的檔案通通轉不動,也只能等看看新的 beta 會不會解掉這問題…
MCEBuddy 2.x http://mcebuddy.com/beta-releases/
偶然發現了這東西,一樣是定時轉檔用,小試了一下發現 meta-data 有進去,多國語系文字似乎也沒問題,而且還可以自動把 MP4 加到 iTunes 裡面去,頗威! 就現階段來講,似乎用這個比較順,不過流量跟畫質還要再喬一下就是,另外 meta-data 補齊也需要人工處理,還要再研究看有沒有自動加特定 tag 的功能。
MC-TVConverter http://www.videohelp.com/tools/MC-TVConverter
[客家話, hak-Hant-TW]
自上上擺 Infinity Blade 更新過後,台灣華語的系統環境下打開他就會用當醜 (楷書) 的簡化字顯示,想要變轉去英文可以按仔做 (需要JB)
是講有較簡單、可以不使用 JB 的方法,請同我講,多謝。
[華語, cmn-Hant-TW]
因為某些原因,要把遠端的 Time Machine 備份映像檔的內容複製到另一個映像檔。原本的映像檔是用這篇提到的方法生出來的,複製的目標則是系統自己產生的映像檔,兩個主要的差別是原來的大小寫沒差,而系統產生的大小寫有別。也因為這樣的差異,不能用系統內建的磁碟工具程式來複製,因為磁碟工具程式對拷時兩邊的大小寫設定要一樣。啊如果是把兩個映像檔分別掛載用 cp 或是 rsync 複製呢?是可以複製啦,但是目標磁碟一下就被灌爆了,因為 Time Machine 裡面有一堆神秘的 hard link,cp 跟 rsync (至少 10.6 內建的不行,不然就是我參數下不對) 都不能正確處理,複製過去後通通被當作不同的檔案,被灌到滿出來也只是剛好。
之前都用 CarbonCopyCloner 在複製硬碟,所以想說這情況 CCC 能不能處理,結果 CCC 完全無視 Time Machine 的備份目錄,所以也是沒辦法。後來試了一下 SuperDuper! 這個備份軟體,整顆複製是沒問題,但這模式會把目標磁碟清掉連大小寫設定都複製來源磁碟,所以要換大小寫的話,就只能掛載後用 Copy different files 的選項來複製,而這個選項是付費版的功能,要用的話也只就能乖乖付錢了,不過他是真的可以正確處理 Time Machine 硬碟,這錢付下去還算是值得。
附帶一提,複製過去的 Time Machine 備份使用上大致上是沒啥問題,也可以進去撈資料,但是一開始有遇到備份到停不了,一直不斷在整理,按取消鍵後又看似有備份成功。查了一下 log 發現跟 fseventsd 有關,而且是備份完之後才跑的所以其實真的是有備份成功,不過也懶得去深究原因了,索性把所有的 .fseventsd (包括根目錄 跟 Time Machine 上的,因為我不知道是哪邊出錯) 通通砍掉,重開機讓系統重新去建立,後來就沒遇到這個問題了。原因還是不明,也不一定是 Time Machine 複製造成的,不過問題解決了就是。
[華語, cmn-Hant-TW]
這版最主要的特色是 dedup,也就是 block level 的 deduplication,傳說中的 virtual machine disk image 備份救星 (誤)。 因為是 block level,所以檔案位置怎麼放,檔案是不是只修改一點點這些通通不用管了,反正 zfs 覺得這兩個 block 是長得一樣的話,就自動會處理,如果硬碟裡面有一堆彼此間差異不大的大檔案,那效果就會非常好,遠比 lzma 或是 gzip 壓縮更有快感 (事實上 dedup 跟壓縮是可以併存的,歡迎挑戰硬體極限) 。
要開 dedup 很簡單,在有 zfsv28 的系統下 zfs set dedup=on filesystem 指令就可以打開,要注意的是 dedup 是從整個 pool 來看的,同一個 pool 下可以有些 filesystem 有開,有些沒有,算是相當有彈性。dedup 的效果可以簡單的用 zpool list 看出,v28 多了一格 DEDUP,那個的倍率就是 dedup 的效果。
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT backup 696G 445G 251G 63% 1.80x ONLINE -
在有開 dedup 的地方,每一個 block 的 checksum 會存在一個叫 DDT 的表裡面,根據 dedup FAQ 的講法,一般 record size 128K 的情況下,20TB 的資料會需要 32 GB 的實體記憶體來放 DDT,如果沒那麼大的記譩體那就會吃到硬碟,那就會非常非常慢。折衷方案就是找一顆 SSD 當 L2ARC,DDT 主要是讀取 (因為要比對),SSD 的讀取效能遠比硬碟來得好,這個工作還算扛得起來。
( 2G 記憶體,640G 的硬碟空間,zfs compression = gzip; atime = off)
測試檔案為 boost_1_45_0.tar.bz2 大小約 38MB,解壓縮後約275MB,用 FreeBSD 內建的 tar 來解壓,然後用 rm 刪掉,同樣用系統的 time 來測時間
tar 19.063u 6.914s 1:03:02.62 0.6% 88+1735k 0+0io 0pf+0w rm 0.171u 8.741s 1:12:41.98 0.2% 26+2530k 0+0io 0pf+0w
tar 19.372u 6.963s 1:05.41 40.2% 74+1464k 0+0io 0pf+0w rm 0.029u 3.826s 0:08.04 47.7% 16+1528k 0+0io 0pf+0w
這是最慘烈的情況 (八成是整個DDT都在硬碟上了),DEDUP on 一般情況其實沒那麼慢,大約數十分鐘吧,如果硬碟裡面已經有相同的資料的話那還會再更快些,不過再快也是被 DEDUP off 時的速度慘電就是。從實際應用來看,解壓縮一個數十MB 的檔案要花數十分鐘到一小時,砍掉解壓縮出來的東西還要再花數十分鐘到一個小時是什麼情況? 只能說硬體不夠力的話,還是不要亂開 DEDUP 吧。 (不過一想到 DEDUP 的快感… 再加上 RAM 現在便宜的跟●●一樣,好像升級一下再來開也是不錯的選擇)
[華語, cmn-Hant-TW]
