人生という名の酷道で遭難中

たぶん、地味に真面目に同期書込やってるFreeBSD限定かも。
1フォルダ300〜500件くらいあると、ファイルをクリックして選択するだけで数秒待たされていて気になっていた。cnidの管理をしているcnid_metadが遅いらしい。ぐぐると、cnidなんていちいち管理しなくてもいーじゃん！ということでAppleVolumes.defaultでの設定をcnidscheme:lastって設定している例があるけど、いざやってみたら、うちではiTunesからnetatalkのフォルダを指定しているんだけど、ファイルが見つからんとかでデータベースがずたずたに。
よくよく調べるとcnid_metadが遅いというより、cnid_metadが使っているBerkeleyDBがやってる同期書込が時間を食っている。ということで.AppleDBが格納されている場所の同期書込を高速化してやることによって解決。うちはzfsなんでZILをSSDに設定して終わり。念のために recordsize=8k とか logbias=throughputとかにしたけど、ZILの設定が一番効果有り。ufsとかなら、.AppleDBディレクトリだけを別ファイルシステムにしてasyncでマウントするとかすればいいかも。
linuxは昔聞いた話だと同期書込を無視するらしいので、遅くなることはないのかもしれない。

FreeBSDにてsamba3.3から3.5へのアップデートでハマる。
3.3の/var/db/sambaのtdbデータベースが3.5と互換性無いらしく、そのまま立ち上げるとcore吐いて落ちる。で、普通にsambaを停止しても、実は終了出来ないままのsmbdプロセスが残ったまんまになっていて、/var/db/samba以下のファイルを握ったままでゾンビに。それを知らずに、その後、何をやってもsambaがマトモに動かなくなる。/var/db/sambaを消してもダメ。samba3.3に戻してもダメ。ゾンビになったプロセスをKILLするまでsambaが動かない。
普通にやるとハマるわな。