剛剛在很苦命的編譯 ports , 機八鴨提供了一個很有用的方式，就是把編譯過程中會產出的 object file 全都塞到 RAMDISK 中(反正現在 RAM 都很大也不知道拿來做什麼)，加上 FreeBSD 8 的 ports 開始支援多核心的 make jobs 編譯，速度可說真是飛快。
作法很簡單：
先蓋一個 RAMDISK （這裡是開 512M, 可以自己調整）
/sbin/mdmfs -M -S -o async -s 512m md0 /tmp/portsobj
然後讓他能寫入
/bin/chmod 777 /tmp/portsobj
接下來去 /etc/make.conf 把 obj 會產生的目錄指過去
WRKDIRPREFIX=/tmp/portsobj
然後去編看看，就會發現速度差很多。
然後懶人大法當然是要 shell script 一下：
#!/bin/sh
case “$1″ in
create)
/sbin/mdmfs -M -S -o async -s 512m md0 /tmp/portsobj
/bin/chmod 777 /tmp/portsobj
echo “512M ramdisk created on md0 and mounted on /tmp/portsobj”
exit 0
;;
destory)
/sbin/umount /tmp/portsobj
/sbin/mdconfig -d -u 0
echo “ramdisk umounted from /tmp/portsobj and destory from md0″
;;
*)
echo “Usage: `basename $0` {create|destory}” >&2
exit 64
;;
esac
然後機八鴨還好心建議不要直接打 make install clean 而是用先用 pkg_add 把 package 裝完，然後再用 portmaster -bDGtw -m FORCE_PKG_REGISTER=yes 來升級，那他每次在編完每一個 ports 後都會自動清掉 obj 而不是像原本的 ports system 會全部裝完成功後才 clean。
如果遇到 PF + PPPOE 一起混著用的時候，又有 Lan connection ，有時候會開起來後 pf rule 完全沒被載入。這問題的起因就是，當 pf 先載入的時候 PPPOE client 還沒有把 daemon 跑起來，除了不知道 gateway 的 IP 外有可能連 Interface 都還沒出現。如果是 Interface 還沒出現的話，只要把該 interface (通常 pppoe 會是 tun0) 用括號包起來，像是：
ext_if_fttb=”tun0″
nat on $ext_if_fttb inet from $internal_net to {!$internal_net,!$sparq_net} -> ($ext_if_fttb)
這樣 pf 就不會檢查 $ext_if_fttb 是不是存在，而如果有用到 PPPOE 的 gateway 的話則可以換成：
gw_if_fttb=”(tun0:peer)”
這樣就不用每次重開完之後還要手動進去 pfctl -f /etc/pf.conf 了。
在 FreeBSD 7.1 PRELEASE 底下做比較複雜的網路環境，結果要讓 rsync + ssh 從其他網路跑進來撈備份的時候遇見很奇怪的問題：
明明就是通的，但是卻是慢到非常的誇張，比原先的線路還離譜。本來以為是 pf 擋到不該擋的，叫出 tcpdump 來看半天發現沒錯；又想說是不是走錯路，交叉測了很久也看不出啥端倪。最後比對正常跟有問題的 tcpdump 也看不出啥鬼。結果在對照［正常］組時發現：
02:52:39.274108 IP bad-len 0
02:52:39.304782 IP bad-len 0
02:52:39.334036 IP bad-len 0
02:52:39.335331 IP bad-len 0
這種東西，好奇 google 一下發現這篇，結果發現我也中大獎 -_-||
sysctl net.inet.tcp.tso=0
從此過著幸福快樂的日子……!@#$%^& …….
剛剛看到大神這篇「升級到 6.1-RELEASE」裡面喊說因為腳踏車鎖(Giant lock)太多，所以就把 root server 衝到 6.1 了，真的是勇敢的長輩 XD。不過我是看到 GIANT LOCK 才想到我忘了說我遇到的狀況，所以才趕快來紀錄一下。
話說我家美人機到了之後總是會亂 panic 及亂七八糟的事情，在這一篇有稍微提到我後來換 ipnat 之後改善很多，不過偶爾還是會從網路上消失。後來大概在五月中的時候， 看到 mailing list 有人疑似有類似的情形，環境也是 smp ，後來過了不久某篇裡面談到：
This is very similar to the UID/GID filtering problem. What appears to
be happening is on the inbound path, we pickup the pfil lock and attempt
to pickup the inp info lock, while on the outbound path, we hold the inp
info lock across ip_output which will try to pickup the pfil lock.
This problem is the result of a layering violation, in reality the
firewall should not be picking up layer 4 related locks. Myself and a
few others have been discussing this problem for quite some time now,
and hopefully it won't be long before we can come up with a solution
that will make everyone happy.
For now, you should be able to set debug.mpsafenet to 0 which will
re-enable Giant in the network stack, in theory preventing the deadlock.
debug.mpsafenet=0
in your loader.conf
Let me know if this helps
於是乎，測試了一下，把腳踏車鎖關掉，開機會看到：「WARNING: MPSAFE network stack disabled, expect reduced performance.」
Copyright (c) 1992-2006 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 6.1-STABLE #3: Wed May 17 22:41:10 CST 2006
cookys@ddbeauty.iecs.us:/usr/obj/usr/src/sys/DDBEAUTY
WARNING: MPSAFE network stack disabled, expect reduced performance.
ACPI APIC Table: <GBT AWRDACPI>
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Pentium(R) D CPU 2.66GHz (3340.93-MHz K8-class CPU)
Origin = "GenuineIntel" Id = 0xf47 Stepping = 7
然後「感覺上」pf 好像反應比 ipnat 好，不過可能是錯覺 XD。雖然說腳踏車鎖一次就會綁一大堆，不過在會亂 dead lock 的狀況下也只能先打開撐著，看什麼時候他們解決 XD。至少跑到現在，兩個禮拜多都沒消失了，除了前一個禮拜被學校裝笑為把她 halt 等停電以外 :p
這時候該高呼，"捷安特鎖"我愛你嗎？(我沒有打廣告喔 @_@)
Recent Comments