Logo address

Plan9, 9front, NIX

目次

2012/08/06
2012/09/11 追加
2012/09/14 追加
2012/09/27 訂正
2013/01/17 修正

我が家の現在の PC 環境は、(Mac や Win を除けば)、Plan9 サーバ io と、その他、実験用に多用途に使う at の 2 台である。
at の方は、Plan 9 端末に化けたり、Linux に化けたりしている。筐体はカバーを外してしまっており、OS の切り替えは HDD を交換して行う。現在では SATA になっているので本当に楽だ。

後の議論に必要になるので、io と at のハードウェア構成をまず紹介する。

io (イオ,ギリシャ神話に出てくる妖精の名前)
MB: GIGABYTE GA-G31M-S2L
on-board LAN: Realtek 8111C/8102E
CPU: Intel Core 2 Duo E7300 2.66GHz
memory: 4GB (DDR2 800)
add-on LAN: intel PRO/1000 Desktop Adapter GT (EXPI9301CT)
at
MB: GIGABYTE GA-H61M-USB3-B3
on board LAN: Realtek/Atheros GbE LAN
CPU: Intel Pentium G860 3GHz
memory: 4GB (DDR3 PC3 1066MHz)
add-on LAN: intel PRO/1000 Desktop Adapter CT (EXPI9301CT)

io の on board LAN コントローラは Realtek 8111C であり、Plan9 では一応サポートされている。plan9.ini で

	ether0=type=rtl8169
で指定すればよい。このコントローラは本来は 1Gbps なのだが、Plan 9 では性能が出ない。(現在の Plan9 kernel では、100Mbps しか出ていないようだ)
家で実験的に使うものであるから、性能を重視する必要はないのだが、今回は intel PRO/1000 も試した。

at の on board LAN コントローラを使っていないのは、Plan 9 ではまだサポートされていないからである。intel PRO/1000 を選択したのは、安価で、そして Plan9 のサポートが良いからであったが、使ってみると、add-on でありながら PXE boot が可能である。

さて、夏休みに入って久しぶりに Plan9 システムを弄って、いろいろな事に気づいた。
(a) at が USB を認識していない注1。
(b) io の LAN adapter を intel PRO/1000 GT (pci)に変更したら、PXE boot が出来なくなった。

注1: 9front版では認識している。

boot

PXE boot の問題

at は、僕の寝室に置かれており、通常は Plan9 端末として使われている。
GIGABYTE GA-H61M-USB3-B3 を使ってみると、最近のシステムは本当に静かになったと思う。電源も、CPU ファンも、HDD(hard disk drive) も... 昔はブンブン唸っていたのに...

さて、intel PRO/1000 はとても気に入ったので、io の LAN adapter を intel PRO/1000 GT (pci)に変更したら、PXE boot が出来なくなった。
これまでは、Realtek 8111C/8102E の下で PXE boot できていたのに...

Plan9 の PXE boot は次のファイルに関係している。

ここに、$mac は at の MAC アドレスである。僕の場合は具体的には 6805ca00fc34 である。

at は PXE boot で、/386/9pxeload をダウンロードして、9pxeload は /cfg/pxe/6805ca00fc34 を読み取っている。この内容は plan9.ini そのものである。しかし、plan9.ini で指定されている /386/9pc をダウロードできないでいる。何が悪いのか?

/386/9pc のダウンロードには tftp が使われている。そこで、Mac から io に tftp でアクセスして、/386/9pc がダウンロードできるか否かを確認した。確かに、ダウンロードできる。これで io 側には問題はない事が判明した。従って疑わしいのは 9pxeload である。これは、io 側が Realtek 8111C の時にはちゃんと働いていたものだ。しかし今回は 1Gbps に上がっている。つまり非常にデリケートな問題だと言う事だ。

Plan 9 を開発したベル研のコンピュータ科学部門の主要なスタッフは 2004 年に Google に移っている。ネットの記事を読むと、現在のベル研のコンピュータ科学部門は人手不足で、ほんの僅かのスタッフで細々と Plan 9 のサポートが行われているらしい。そのために、新しいハードウェアに対応できないばかりか、ユーザから寄せられるバグ修正のパッチや新しい成果(この間、ユーザも増えている事もあり、多くの成果が上がっている)も Plan 9 システムに反映できていないとのことである。そうした事情もあって、数年前にユーザサイドで Plan 9 の派生 OS が作られた。9front である。現在では最新の成果は 9front 側に反映されている。9front の web site は

	http://code.google.com/p/plan9front/
である。

9front は Plan 9 のブート問題に関して、よく研究しているらしく、9pxeload の代わりを作っている。そこで、今回はこれを試す事とした。
9front の配布 CD イメージの中の /386/9bootpxe を io の /386 にコピーして、これを使うように、/lib/ndb/local を修正する。結果は? OK!

USB boot

9front では USB boot がサポートされている。ただし、実際に旨く行くには条件を満たさなくてはならない。
(1) BIOS のサポート
(2) Plan9 側での USB の認識

最近のマシンはたいてい (1) の条件はクリアしている。しかし問題なのは (2) である。

USB が認識されない問題

at は USB を認識しない。USB disk だけではなく、USB mouse も認識しない。boot 時のカーネルメッセッジには次のものが含まれる。

	pcirouting: ignoring south bridge PCI.0.31.0 8086/1C5C
このメッセージは、カーネルが Plan 9 の場合も、9front の場合も変わらない。

8086/1C5C は VenderID/DeviceID のはずである。

	http://www.pcidatabase.com/
で調べると、8086 は intel であることが分かる。しかし 1C5C は、登録されていない。

手持ちのいろいろなマシンを調べてみると、USB を認識しないものが意外と多い。cpu サーバは nvram を必要とする。今時 FDD に置くのは気が利かない。USB disk が手軽な選択肢であるが、USB を認識しないようであれば、cpu サーバの選択に困る。

注: この問題は現在ではかなり解決されている。少なくとも 9front に関しては... (2013/06/25)

9front way

9front の工夫の1つは、boot のプロセスの一部を rc に担わせたことにある。

	/sys/src/9/boot/boot.c
を見ると、boot.c によって、最小構成の Plan9 システムが動き、その中で bootrc が実行される。
最小構成の Plan9 システムの中のファイルは、
	/sys/src/9/port/bootfs.proto
で決定されている。また bootrc は
	/sys/src/9/boot/
に置かれている。bootrc の役割は、これを基に、cwfs を立ち上げ、ファイルシステムを切り替える事にある。

一旦、小さな Plan9 システムが動いているので、cwfs に切り替えられるまでに、ユーザーサイドから容易に手を加える事が可能である。

plan9.ini

Plan9 では plan9.ini の中で menu がサポートされていたが、9front ではサポートしていない。
サポートすることもできたであろうが、他の(玄人向けの)方法を採用した。
rc に戻ることができるから... と言うことであるが、環境変数の変更は、現在の bootrc のコードではできない。
できるようにするためには、少し手を加えないといけない。

カーネルに手を加える場合には、動作確認されたカーネルの予備(例えば 9pcf.old)を 9fat に持ちたいのだが、bootfs.proto には cp が含まれていないので、

	cp 9pcf.old 9pcf
とはできず
	cat 9pcf.old >9pcf
としなくてはならない。簡単に bootfs.proto に追加できるので(もちろんカーネルの再構成が必要である)、好きなコマンドを追加すればよいであろう。

もっともカーネルを修正する場合は、ネットワークからブートする体制を整えて行う方が、無難であり、楽である。

cwfs v.s. fossil

今回は at に 9front をインストールしてみた。9front の標準ファイルシステムは cwfs である。9front の cwfs は Geoff の cwfs に factotum とのインターフェースが追加されている。

cwfs が生まれる経緯

9front のファイルシステムは cwfs になっている。Plan 9 がリリースされた時に、端末でも動く kfs と言う簡易ファイルシステムとともに、ファイルサーバー用に、Ken Thompson による本格的なファイルシステム fs が存在した(以下 Ken fs と言う)。Ken fs は魅力的なバックアップシステムを持ち、しかもネットワークサーバーとして性能がでる。しかし Ken fs は1台のマシンを占有する。そして、メンテナンスのために、使い慣れた Plan9 のツールが使えないと言う欠点を持っていた。

2002 年にユーザ空間で動く fossil がリリースされてから、fossil は事実上の Plan9 標準ファイルシステムとなっていた。そうした中で、2007 年にベル研の Geoff が cwfs のリリースをアナウンスした。Geoff は Ken fs をユーザ空間で動くファイルシステムに書き換え、さらに、64bit 化などの改善を行っている。

さて、2つのファイルシステムが手に入ったので、速度を比較してみた。行ったのは、(大きな?)ファイルの読み出し速度の比較である。ファイルとしては

	--rw-r--r-- M 20 glenda glenda 312923158 Aug  5 03:42 mroot.tgz
を選んだ。理由はサイズが実験に手頃だからである。中身は何でもよい。

ファイルの読み出し速度の比較

9front + cwfs

	term% time cat mroot.tgz >/dev/null
	0.03u 0.37s 1.10r 	 cat mroot.tgz
	term%

Plan9 + fossil (dma on)

	term% time cat mroot.tgz >/dev/null
	0.01u 0.41s 1.45r 	 cat mroot.tgz
	term%

実は読み出し速度の測定値は cache と密接な関係がある。1回目は遅く、2回目からは速い。2回目からは cache がファイルサイズよりも大きい場合には、メモリー上のデータを出力していることになる。ここに挙げた数字は、2回目以降の数字である。

ps コマンドで venti と fossil へのメモリーの割当を見ると

	arisawa          28    0:01   0:00   543124K Rendez   venti
	arisawa          30    0:00   0:00   559620K Rendez   fossil
他方 cwfs へは
	glenda          250    0:00   0:00   840028K Rendez   cwfs64x
となっている。

従って、先の数字 1.10 と 1.45 は、CPU+memory の能力を表していると見て良い。

cache メモリーの割当

現在の fossil へのメモリーの割当は、ソースコードを読むと 20% となっている。この数字は plan9.ini で設定できた方が良いのだが、そうはなっていない。

/sys/src/9/boot/local.c in Plan9

	run("/boot/fossil", "-m", "20", "-f", partition,
		"-c", "srv -A fboot", "-c", "srv -p fscons", nil);
他方 9front のマニュアル(CWFS(4))では cwfs の方は default が 25% とされている。
The original file server reserved the rest of the machines
RAM for io buffers. Where cwfs running under the Plan 9 ker-
nel reserves a settable percentage of the remaining user
pages. The percentage is read from the enviroment variable
fsmempercent which when not set is assumed to be 25%
(default).

ただし、この記述は Plan9 の CWFS(4) には存在しない。多分、9front が仕様を拡張したのだろう。

cwfs の使い勝手

僕はまだ言える立場にはなが、気がついた事を書く。

(a) fossil に比べて cwfs の方が手軽であろう。
(b) 9front で配布されている cwfs は認証で問題を抱えている。
(c) dump の時刻に問題がある。特に日本では困る。
(d) 管理コマンドに改善の余地がある。

fossil は venti との組み合わせで使うので システムの設定はかなり複雑である。もっとも history 機能を必要としなければ venti と併用しなくても構わないが、fossil のメリットが発揮されない。venti はネットワークサーバーとして設計されているので、fossil と venti との通信にはネットワークインターフェースが使われる。しかし、この事は fossil を遅くする。実際、大きなファイルの(最初の)読み取り時間はネットワークカードの通信速度で決まっているようだ。

(b),(c),(d) は結局こちらで手を加えて、今は問題はない。
もっと具体的に言えば、
認証関係のライブラリがソースコードの通りに振る舞っていなかった。そのために、再コンパイルが必要であった。さらに、端末に対して arisawa で login しても、ファイルシステムに対しては glenda として認証されるケースがある。login したユーザ名で確実にファイルシステムに対しても認証されるようにするには /sys/src/9/bootrc を修正する必要がある。
dump の時刻は GMT の 5時に固定されている。これは容易に修正できる。2つの方向があろう。

cwfs の実行中の管理は console で

	con -C /srv/cwfs.cmd
を実行すれば行えるが、noauth, noattach のようなセキュリティに敏感な設定がトグルになっているのは理解できない。これも簡単に改善できる。さらに、プログラムのインストール時に必要になる allow コマンド(このコマンドはパーミッションチェックを外す)が大雑把すぎる。
	allow arisawa
のように、特定のユーザに対してのみ allow が働くようにしたいのであるが、この修正も簡単である。

「簡単である」と書いたが、簡単になったのは、このファイルシステムが、カーネル空間からユーザ空間に移されたからである。Geoff に感謝!

cwfs の管理用コマンドは Ken fs 時代のコマンドをそのまま継承している。これは 1990 年頃に、研究所内と言う平和な環境下で考えられた管理コマンドである。
他にセキュリティに絡む問題としては none による attach がある。この問題は cwfs のレベルではなく、他の方法を採る方が良いかも知れない。例えば
http://plan9.aichi-u.ac.jp/admin/control.html

もちろん外部からのアクセスに関しては必ず認証が求められる。Plan9 ではパスワードが設定されていない限り認証はされない注1。従って none は認証されない。しかし認証だけに頼る場合にはどうか? 通常、認証に際してサーバはユーザのパスワードの入力を待たなくてはならない。大量の認証要求が一斉に来た場合に、サーバーが耐えられるか否かを見極める必要があろう。こうした問題は Plan9 に限らず一般的に存在する。

注1: Geoff の cwfs では none に対して認証を要求していない、つまり none としてならファイルシステムに認証なしにアクセスできる。この問題はセキュリティ上の問題をもたらす可能性があるので、cwfs の新しい版(2013年2月)からは nonone を console コマンドで指定できるようになった。

Patches for 9front

2012/09/11
2012/09/14
2013/01/17

bootrc

bootrc (for /sys/src/9/boot/bootrc) # (2012/09/14)

Note: You no longer need this one.
Problems are fixed in 9front version released at 2013/01/17.

cwfs

cwfs.tgz (for /sys/src/cmd/cwfs/) # (2013/02/13)

Exampe:

	dumptime=4
Note that this value means GMT if timezone variable is absent.

New or modified administrating commands:

You can enter the console by the command:

	con -C /srv/cwfs.cmd
Hit ctrl-\ and CR and then 'q' to exit console.

Note: you can find the changes by my signature "Kenar"

change log

他に改善の余地は?

注1: このような言い方は正しくない。cwfs には format の概念は無い。詳しくは
http://plan9.aichi-u.ac.jp/cwfs/
を見よ。(2013/04/12)
注2: 現在のままで良いと思う。最近の HDD の容量は、僕には使い切れない。(2013/04/12)
注3: 要らないと思う。
http://plan9.aichi-u.ac.jp/cwfs/
の "What did I do that day" を見よ。(2013/04/12)

cwfs v.s. fossil

Cinap が 9fans での比較に関する質問で次のように答えている。(9fans: 2010/04/17)

the disadvantage is using cwfs vs fossil is that you cant have
themporary snapshots and here is no temporary flag (chmod -t) per
file. so you have to create your users /tmp in the "other" fs wich
does not get dumped.
...
also, kenfs/cwfs does a copy on write when changing a already dumped
block in your main filesystem, but new dumped blocks are not
dedublicated by content like in fossil/venti. this means that your worm
may fill up faster than your venti arenas would.

filesystem limitations like filename length and maximum file size is
fixed once you created your filesystem. the maximum filename length
is smaller than fossils, so you may want change that in the
configuration and recompile before creating your filesystem.

but on the good side kenfs/cwfs is a lot simpler in its design and
implementation than fossil/venti. its working pretty robust for me
since i switched. no bad surprises yet.


ファイル名の最大長は cwfs64x を使った場合には、143 である。他方 foosil の方は、事実上の制限無し。

fossil+venti は複雑すぎる。Russ Cox 程度の能力がないと維持できないとなれば、それ自体、大きな問題である。cwfs が好まれるのは、そのシンプルさであろう。

文献

VGA

VESA

aux/realemu が追加され、それとともに VESA の使い方も変更されている。

Example:
changing to 1280x1024x16 in VESA mode

term% aux/realemu
term% aux/vga -p >/tmp/x
....
vesa mode           0x17e 1280x1024x16 r5g6b5 direct
....
term% aux/vga -m vesa -l 1280x1024x16
....
term%

Plan9 の弱点の1つは、グラフィックドライバにある。十分な情報が得られないために、グラフィックドライバの作成が困難を極めるのである。最低限の機能は VESA で標準化されるようになって、現在では殆どの VGA コントローラが VESA をサポートしている。しかし、遅い! ここが速くならないと、高度なグラフィックスはサポートできないのである。

pkg (パッケージ管理)

9front のパッケージ管理は hg を使っている。
しかし、どうも僕は hg を好きになれない。

Plan9 のパッケージ管理は、3つの要素からなっていると思う。
(a) 現在のシステムのファイル構成を見せ、任意のファイルをダウンロードできる事
(b) 過去のシステムのファイル構成を見せ、任意のファイルをダウンロードできる事
(c) ファイルの一覧が plan9.db として提供されている事
つまり、自分のシステムとの整合性を確認し、さらに変更履歴を知るための、必要充分な情報が簡単な方法で提供されていたのである。
(もっとも、Plan9 のシステムアップデートの方法 replica/pull は、効率が悪く注1、筆者は他の方法を採っている。)

注: 僕が知っている(昔の) replica/pull は plan9.db ではなく、イベントログに基づいており、無駄なダウンロード作業がいっぱい含まれていた。現在では改善されているかも知れない。

hg 使い方が難しい上に、どうもお任せになってしまう。旨く行けば良いのでしょうが... でも確認したい事ってあるんだよね...

パッケージには以下のファイルが含まれている注1。

term% pkg/list
appleii-2012.03.12
bdf2subf-2012.03.09
breakout-2012.07.08
c64-2012.03.09
cifs-2012.07.30
contrib-2012.01.05
crabs-2012.04.04
cvs-2012.01.05
cvsfs-2012.07.08
dec-2012.03.07
divergefs-2011.05.01
equis-2012.01.11
figlet-2012.07.08
freefont-2011.09.20
gmake-3.81
gnugo-2012.07.07
gopherd-2012.04.15
helvetica-2011.12.08
hjmothra-2012.07.31
hjrio-2012.06.03
inferno-2011.05.17
irc7-2012.06.22
linuxemu-2012.04.09
lynx-2012.04.06
mpm-2011.05.14
mroot-2011.05.10
nfactotum-2012.04.03
nupas-2012.04.03
openssh-2012.03.15
pegasus-2012.01.08
rc-httpd-2012.07.05
rtf2txt-2012.01.05
scpu-2012.03.15
sftpfs-2012.07.07
ssh2-2012.08.01
tandy-2012.03.12
ttf2subf-2012.03.09
werc-2012.07.05
term% pkg/local
equis-2012.01.11
freefont-2011.09.20
go-2011.05.10
linuxemu-2012.04.09
mroot-2011.05.10
term% term%

注1: '/mnt/web/clone' does not exist のメッセージがでたら、webfs を実行する。

linuxemu

インストール

9front の目玉は linuxemu であろう。
Linux のエミュレート環境を備えている。ベースとなっている技術は vx32 と同じである。Linux や Mac(OSX) 上で Plan9 の実行ファイルをそのまま動かす技術が vx32 である。linuxemu はその逆を行う。

次の2つのパッケージをインストールする。

	pkg/install linuxemu-2012.04.09
	pkg/install mroot-2011.05.10
その結果、/sys/lib/linux 以下に linuxemu で使うファイルが置かれる。現在のところ多くはない。デモぐらいの位置づけなのだろう。実用性から言えば、この程度の事なら Plan9 の方が良い。

term% ls /sys/lib/linux
/sys/lib/linux/bin
/sys/lib/linux/boot
/sys/lib/linux/dev
/sys/lib/linux/etc
/sys/lib/linux/home
/sys/lib/linux/lib
/sys/lib/linux/mnt
/sys/lib/linux/opt
/sys/lib/linux/proc
/sys/lib/linux/root
/sys/lib/linux/sbin
/sys/lib/linux/sys
/sys/lib/linux/tmp
/sys/lib/linux/usr
/sys/lib/linux/var
term%

/sys/lib/linux が標準的な linux ファイルの置き場所である。その下では次のようにして、Linux の端末環境に入ることができる。

term% linux /bin/bash -i
root@at:~/src# ps
  PID TTY          TIME CMD
   10 ?        00:00:00 bash
   11 ?        00:00:00 ps
root@at:~/src#

http://plan9.bell-labs.com/wiki/plan9/linux_emulation/index.html

equis

linuxemu は equis と組み合わせて、Opera などの商業ベースのモダンなブラウザを 9front で動かす事を可能にしている。これは Bell-labs の Plan9 では出来なかった事である。そのためには、2つの準備が必要である。
(1) mroot にはサイズが異なる2つの版があるが、大きい方の版
(2) equis

mroot の大きい方は

	http://ph.inri.net/9front/mroot.tgz
で手に入る。

equis は Plan9 用の X11 サーバーであり

	pkg/install equis-2012.01.11
で手に入る。

実行は、1つの rio window で

	X11/equis
他の rio window で
	linux -r mroot /bin/bash -i
	dwm&
	opera&
ここで、-r オブションは mroot が置かれている linux root である。

ただし

最初の問題はグラフィックドライバが改善されない限り、解決されない。

リンクの問題

mroot の構成が手間取るのは UNIX の link に起因しているらしい。
Linux には多数のソフトリンクが使われている。他方、Plan9 にはリンクの概念が無い。
そのために、Linux の標準インストーラ(パッケージ管理ツール)が使えないのである。
問題解決の方向は、Linuxemu の中でリンクをサポートすることではないかと思う。
Linux には Linux のファイルシステムが一番似合っているのであるが、その方向は大げさすぎる。リンクファイルの代わりになるものをPlan9で考えればよいのではと思える。例えば lock 属性のファイルを linuxemu ではリンクファイルとして使うとか...

NIX

まだ書く内容を持たない。

http://lsub.org/