FreeBSD 11-STABLE symbol の 'KERNBASE' can not be undef の件2017年10月11日 12時30分08秒

取り合えず、どの変更が原因か調べる。

前回のカーネルバージョンは 324186。 324421 は既に駄目。 324300 も駄目。 324299 は大丈夫。

コンパイルエラーを手っ取り早く見付ける為なので、モジュールは全て無効にする。

% cd /usr/src
% make buildkernel -j 3 MODULES_OVERRIDE=''
もしかしたら、一ファイルだけをコンパイルする方法もあるのかも知れないが、これで十分。

問題を見付けたかと思ったら、rm /usr/obj/usr/src/sys/GENERIC/mpboot.o の後に、324300 を試したら大丈夫。324385 は大丈夫。324400 は大丈夫。324472 も大丈夫。結局 HEAD に戻しても大丈夫。ファイルを消したら何が変わったのだろうか…

FreeBSD の一時スワップデバイスは tmpfs を nfs で export して swapon2017年09月25日 12時52分37秒

mdconfig の swapon はかなりオーバヘッドが多い。と言うか、ほとんどがオーバヘッドだ。

それに引き換え、あまり推奨されていない筈のNFS ファイルの swapon は、swap pager と NFS、そしてディスクの IO の値が一致する。ネットワークの帯域に多少は心配があっての、ファイルやデバイスへのアクセスは優秀で、ほぼ 100% の様だ。

これらを総合すると、swap 領域の圧迫の一時的な対処法は、別機からのサポートのようだ。メモリに余裕のあるシステムから、tmpfs を nfs エクスポートし、そこのファイルを直接 swapon をする。

また、大量のページングが発生している状況だと、スワップ領域も細切れになり、また、仮装メモリと実メモリのマッピングも随分と断片化する。ディスクが主体のスワップよりも、ネットワークと tmpfs のメモリアクセスの方が数倍も早くなる場合が多い。

NFS の export の部分を若干省略するが、大体の作業。

nfs-server $ mount -t swap dummy /mnt/tmp
nfs-server $ dd if=/dev/zero of=/mnt/tmp/swap bs=1M count=1 seek=9999
nfs-server $ vi /etc/export
nfs-server $ sh /etc/rc.d/nfsd onestart
swapping-machine $ mount -t nfs nfs-server:/mnt/tmp /mnt/swap
swapping-machine $ swapon /mnt/swap/swap

FreeBSD の mdconfig のでスワップファイルは非効率2017年09月20日 06時15分21秒

スワップ領域にするのに一番適しているのは、デバイス。一時的な利用などにより、物理メモリが足りなくて、さらにスワップデバイスも容量が逼迫してしまうときもある。そのような時には、ファイルを通してスワップをすることも可能だ。
$ dd if=/dev/zero of=/mnt/scratch/swap bs=1M count=1 seek=10000
$ mdconfig -a -t vnode -f /mnt/scratch/swap
md1
$ swapon /dev/md1

ただ、これは本当に一時凌ぎの様だ。まずは、root に成れなくてはならない。そして、読み書きの様子を観察をしていると、ファイルへのアクセスは多いのだが、swapin や swapon は大して多くならない。mdconfig を通して、ファイルとしてアクセスするオーバーヘッドがかなり大きい様だ。10 MB/s のディスクアクセスでも、実際のページングになるのは 1 MB/s あたり。ディスクのアクセス効率は、十から二十パーセントからぐらいのようだ。

FreeBSD 11-CURRENT で buildworld 用の ccache2015年10月20日 07時30分23秒

[CFT] Buildworld ccache support にて、world-ccache.diff が投稿された。

最近、buildworld をよく行うので、高速化に、distcc と ccache を見ていた。buildworld は三段階以上にわたって、CC を置き換えて行くので、一般的に ccache の設定では出来ないなと結論が出ていたところ。

ccache よりも distcc に興味を持っていたのだが、折角なのでメモ。

FreeBSD 11-CURRENT で .depend を削除して速くなった2015年10月07日 11時42分54秒

buildworld の二回目に全てが作り直される動作は修正された。

しかし、手元での CURRENT-11 の buildworld を眺めていると、legacy と toolchain のターゲットのところで、clang は必ず、それ以外にもいくつかのプログラムもほぼ必ず再構築されていた。svn update を行っていない時でも、clang がこの二つのステージで作り直されるのはおかしい。

/usr/src/Makefile と /usr/src/Makefile.inc。それに /usr/src/share/mk/ のファイルを目を通すが明示的にコンパイルを引き起こす様な記述はない。そうなると、依存関係が怪しいと言うことになる。そこで、/usr/obj/usr/srcc/tmp 以下の .depend の日付を見ると八月中旬の物になっている。

% find /usr/obj/usr/src/tmp -name .depend -ls
% find /usr/obj/usr/src/tmp -name .depend | xargs rm
そこで、一旦削除して buildworld を行った。今回は clang が再構築されない。Makefile を見ていても tmp 以下の ブートストラップの .depend は作り直されないようで、時おり掃除してやる必要がありそうだ。

buildworld の clang 再コンパイル修正が入った2015年09月24日 13時25分16秒

最近は FreeBSD CURRENT をよく追いかけている。どうも buildworld を再度実行した時に clang が不必要に作り直されているのには最近気が付いていた。

最初に見た二、三週間前は、NFS や NULLFS を使っていたせいかと思っていた。しかし、何度か更新を続けていると、UFS でも起きているのを確認したのは、更に最近。

まず、bootstrap 用の clang が一度作られる。その後、toolchain 用に二度目の clang が作られる。そして、toolchain が出来た後に、本格的に buildworld が始まり三度目の clang が作られる。

buildworld をただ単に繰り返しただけで、その第二と第三の clang が必要も無いのに、再コンパイルされているのを突き止めたのが、二、三日前だった。

もう少し詳しく見てみようと思っていたところで、META_MODE: Fix 2nd build causing everything to rebuild due to changed CC. を発見。過度な再コンパイルに気づいていた人はいたみたいで、修正が CURRENT に入ったのを確認した。

これで、余計な clang の時間が大幅に減った。最近は機械が古くなってきているせいで、buildworld に四、五時間掛かることもあるので、かなり楽になる。なお、その大半の時間が clang に消費されていた。

ディレクトリ内のファイル数2014年01月11日 13時28分07秒

あるディレクトリ内にファイルが数万個だか、数十万個だかが作られていたらしい。どうなるかと言うと、ファイル操作が遅くなるのだ。ディレクトリの閲覧はもちろん、更新なども全てが遅くなる。

あまりにも増えてしまうと、シェルのコマンドラインの展開も出来なくなるし、削除をするのも色々と時間がかかり大変になる。今回の件では Solaris だったが、他も似たようなものだと思う。

実際に起こると結構見付けづらい問題だ。読み書きの速度が致命的な程に落ちたりするのだが、fsck などを含めてあれこれの診断も問題ないと出してくる。原因不明のディスクの速度低下があったら、find などで、ファイル構造を見るのは習慣にした方が良さそうだ。

大量メモリ搭載の FreeBSD の起動を早くする2013年11月25日 13時46分49秒

FreeBSD メーリングリストで見掛けた情報。FreeBSD の起動時に簡単なメモリの点検が入るため、起動が遅くなるそうだ。

hw.memtest.tests="0"

を /boot/loader.conf に記述すると、これを省くことが出来る。

32 GB のメモリを搭載している人達は早くなったそうだ。256 GB だと、これに二分程かかるらしい。古い BIOS に起因したものらしく amd64 等の新しいアーキテクチャには意味が無いそうだ。この雰囲気だと、将来的には amd64 では無効にされそうな感じ。

PC をイーサネットで直繋ぎ2013年11月24日 13時47分25秒

ノート型 PC を二台繋げて使うのは何年もやっている。FreeBSD が主なので、FreeBSD 同士がほとんどだが、NFS などを主にファイルの共有に使う。

無線だといちいち繋ぐ必要もなく便利だ。最近はそれなりの速度もでる。しかし、大型ファイルの転送にはやはり時間がかかってしまい、有線には勝てない。そこで、大きめの作業があるときは、いつもハブを取り出して繋いでいた。

ふと最近、わざわざハブの電源を入れて、各々一本ずつ計二本のケーブルを繋ぐのが面倒臭かった時があった。面倒臭いが早さが必要なので、とりあえず実験。PC 同士を普通のイーサネットケーブルでそのまま繋いでみた。いわゆるストレートケーブルである。するとそのまま使えてしまった。

昔々は、ストレートケーブルでは無くてクロスケーブルを使えだとか、ハブにもハブ同士の連結用と PC 用が分かれていた時代もあった。それが自動認識になったのも既に十年以上前。今では、PC 同士でも自動認識されるようだ。簡単に調べてみると GBE から自動認識の規格が入ったらしい。

FreeBSD の Java は openjdk2013年11月18日 13時15分33秒

久しぶりに NetBean で Java を使おうと思ったら、NetBean がインストールされていなかった。長いこと使っていなかったので消してしまっていたらしい。そして、Java もどの実装が現役なのだか。古いものだが四つ入っている。

% ls -d /usr/local/*jdk*
/usr/local/diablo-jdk1.5.0      /usr/local/jdk1.5.0
/usr/local/diablo-jdk1.6.0      /usr/local/jdk1.6.0

さて、make install で引っ張られてくるのは openjdk だった。FreeBSD Java Project: How To Install によると、OpenJDK が現在の公式の Java サポートみたいだ。

OpenJDK は以前の Java の様に自分でダウンロードをしておかなくても良いみたいだ。文句を言われてから取りに行こうと思って、おもむろに make install を叩いたが、そのまま無事に終了してしまった。

もう一つ。8.4 RELEASE 時の ports を使っているが、「Enable Legacy Debugging Support」を使って i386 上ではコンパイルエラーが発生した。これを無効にしてコンパイルを再度始めたところ、今度は問題なく終了できた。メモリが 4GB あると tmpfs を使って、OpenJDK をメモリ上だけでコンパイルとインストールできる。IO が省けて速くなる。

NetBeans 7.3 がデフォルトで、 NetBeans 6.1 の ports もあった。どちらともインストールするだけで動いた。ワークスペースの情報が引き継がれないみたいで、7.3 ではプロジェクトが空っぽだった。

前回次回