我が家の現在の PC 環境は、(Mac や Win を除けば)、Plan9 サーバ io と、その他、実験用に多用途に使う at の 2 台である。
at の方は、Plan 9 端末に化けたり、Linux に化けたりしている。筐体はカバーを外してしまっており、OS の切り替えは HDD を交換して行う。現在では SATA になっているので本当に楽だ。
後の議論に必要になるので、io と at のハードウェア構成をまず紹介する。
io の on board LAN コントローラは Realtek 8111C であり、Plan9 では一応サポートされている。plan9.ini で
ether0=type=rtl8169で指定すればよい。このコントローラは本来は 1Gbps なのだが、Plan 9 では性能が出ない。(現在の Plan9 kernel では、100Mbps しか出ていないようだ)
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 が出来なくなった。
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 は次のファイルに関係している。
/386/9pxeload/cfg/pxe/$mac/lib/ndb/local$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!
9front では USB boot がサポートされている。ただし、実際に旨く行くには条件を満たさなくてはならない。
(1) BIOS のサポート
(2) Plan9 側での USB の認識
最近のマシンはたいてい (1) の条件はクリアしている。しかし問題なのは (2) である。
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 の工夫の1つは、boot のプロセスの一部を rc に担わせたことにある。
/sys/src/9/boot/boot.cを見ると、
boot.c によって、最小構成の Plan9 システムが動き、その中で bootrc が実行される。/sys/src/9/port/bootfs.protoで決定されている。また
bootrc は/sys/src/9/boot/に置かれている。
bootrc の役割は、これを基に、cwfs を立ち上げ、ファイルシステムを切り替える事にある。
一旦、小さな Plan9 システムが動いているので、cwfs に切り替えられるまでに、ユーザーサイドから容易に手を加える事が可能である。
rc に戻ることができるから... と言うことであるが、環境変数の変更は、現在の bootrc のコードではできない。
カーネルに手を加える場合には、動作確認されたカーネルの予備(例えば 9pcf.old)を 9fat に持ちたいのだが、bootfs.proto には cp が含まれていないので、
cp 9pcf.old 9pcfとはできず
cat 9pcf.old >9pcfとしなくてはならない。簡単に
bootfs.proto に追加できるので(もちろんカーネルの再構成が必要である)、好きなコマンドを追加すればよいであろう。
もっともカーネルを修正する場合は、ネットワークからブートする体制を整えて行う方が、無難であり、楽である。
今回は at に 9front をインストールしてみた。9front の標準ファイルシステムは cwfs である。9front の cwfs は Geoff の cwfs に factotum とのインターフェースが追加されている。
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 の能力を表していると見て良い。
現在の 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).
CWFS(4) には存在しない。多分、9front が仕様を拡張したのだろう。
僕はまだ言える立場にはなが、気がついた事を書く。
(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つの方向があろう。
plan9.ini で、この 5 を変更できるようにする。plan9.ini で timezone を指定できるようにする。
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 に限らず一般的に存在する。
bootrc (for /sys/src/9/boot/bootrc) # (2012/09/14)
cwfs.tgz (for /sys/src/cmd/cwfs/) # (2013/02/13)
Exampe:
dumptime=4Note that this value means GMT if timezone variable is absent.
New or modified administrating commands:
allow [user]auth [option] # option is either enable or disableattach [option] # option is either enable or disablenone [option] # option is either enable or disablecwcmd autodump [option] # option is 0 or 1noauth, noattach and nonone are left untouched for compatibility
You can enter the console by the command:
con -C /srv/cwfs.cmdHit ctrl-\ and CR and then 'q' to exit console.
Note: you can find the changes by my signature "Kenar"
cachefmt と wormfmt のようなコマンドで、フォーマットした方が良いのではと思える。fossil でも外付けになっているように。その方が cwfs のコードをシンプルにする注1。
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 が好まれるのは、そのシンプルさであろう。
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 をサポートしている。しかし、遅い! ここが速くならないと、高度なグラフィックスはサポートできないのである。
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%
'/mnt/web/clone' does not exist のメッセージがでたら、webfs を実行する。
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
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 ではリンクファイルとして使うとか...
まだ書く内容を持たない。