Kenji Arisawa E-mail: arisawa@aichi-u.ac.jp Aichi University Kurozasa 370, Miyoshi-cho Aichi, Japan http://ar.aichi-u.ac.jp 2001/06/01 改訂
時刻合わせ
ここではPlan9システムの時刻とBIOSの時刻との関係、及び日本における調整の問題を解説する。スタンドアロンシステム
スタンドアロンシステムではBIOSの時刻表示はグリニッジ標準時と見なされる。 タイムゾーンは
/adm/timezone/local
で決定され、日本に合わせるには
term% cd /adm/timezone term% cp Japan localを実行すればよい。
しかしながら、スタンドアロンのPCが他のOSと共存している場合には問題が発生する。 例えばWindow95ではMSDOSの時刻はローカルタイムである。このような場合にはPlan9側で工夫をすることができる。
term% cat local JST 32400 JST 32400となっているであろう。これを
JST 0 JST 0に変更すればよい。
分散システム
以下に理解を容易にするためにいくつかの時刻(単位は秒)を定義する。- 時刻 A : システムクロック
これはBIOSの時刻である。 - 時刻 B: 隠れた時刻
この時刻を表示するコマンドは存在しない。 ファイルサーバが立ち上がった時点では A=B になっている。 ファイルサーバでのコマンド date によって B を変更できる。ただし A には影響しない。 - 時刻 C : ファイルサーバの時刻
ファイルサーバのコンソールから date コマンドで表示される時刻
なぜか C = B - 14400 となっている。つまり時刻 B より4時間遅れている。 dumpfs は時刻Cの5時(早朝)にバックアップをとる。 - 時刻 D : CPUサーバあるいは端末の時刻
CPUあるいは端末で dateコマンドで表示される時刻である。
この時刻はCPUあるいは端末のブート時に時刻Bと/adm/timezone/localを基に決定される。日本であれば D = B + 32400 である。つまり時刻 B より 9 時間早い。 "ls -l" コマンドで表示されるファイルの作成/改訂時刻はこれに基づく。 また /sys/log/ のファイルもこの時刻を採用している。
注釈: 筆者は以前にForsyth の ykhttpd は GMT を採用していると書いたがサーバの 設定ミスであった。(環境変数に timezone を入れていなかった)。
認証サーバを独立させている場合には認証サーバのシステムクロックもグリニッジ標準時に設定する。
ファイルサーバの date コマンドは微調整だけを行うべきである。
Plan9 の時刻合わせの問題はファイルサーバの隠れた変数(時刻B)を抜きに理解できない。なぜファイルサーバの時刻が変なのであろうか?
ファイルサーバは/adm/timezone/localを見ていないのである。そのもとで早朝5時にバックアップをとるために極めて安直な「解決法」が採られたと推定できる。即ち特定の地域に合わせてファイルサーバの時刻が決定されるようにパッチが充てられたのだろう。
問題は以下のように解決すべきであろう。
- 解決策1: ファイルサーバの時刻 C を時刻 B と
/adm/timezone/localによって決定する。 - 解決策2:
plan9.iniに環境変数 localtime を追加し、ファイルサーバの時刻 C を時刻 B とこの変数によって決定する。 - 解決策3: ファイルサーバの時刻 C を時刻 B に一致させ、ファイルをダンプする時刻を設定するコマンドを追加する。(あるいはファイルサーバの plan9.ini で環境変数を渡せるなら、その中でダンプ時刻を指定するのもよい)
筆者はとりあえず(安易なやり方で)日本に合わせてファイルサーバの時刻が決定されるようにパッチをあてた。即ち、
/sys/src/fs/port/time.c
を以下のように変更した。
変更前:
static struct
{
short minuteswest; /* minutes west of Greenwich */
short dsttime; /* dst correction */
} timezone =
{
5*60, 1
};
変更後:
static struct
{
short minuteswest; /* minutes west of Greenwich */
short dsttime; /* dst correction */
} timezone =
{
-9*60, 0
};
こうして変更した 9pcfs をファイルシステムのブートフロッピーにコピーする。
さて、これをブートするとびっくりする事が起きた。
ファイルシステムの整合性が取れないと言って異常終了するのだ!!
うーむ、確かに... 時間に関して以前のシステムと整合性がとれなくなっている!
筆者のは pseudo-WORM なのだから...
そこで納得して、config で
recover mainを実行して正常に再出発できた。
さて以上のパッチをあてると以下のようになる。 1. ファイルサーバの時刻 A をグリニッジ標準時に合わせる。即ち日本時間より9時間遅らせる。 2. するとファイルサーバの時刻 C は A より9時間あるいは8時間進んでいる。 日本時間と等しくない事があるが気にしなくてもよい。1時間の違いが発生する事があるのは、アメリカの夏時間が想定されているからである。 3. 以上によって CPU サーバと端末の時刻は A による設定から 9 時間すすみ、日本時間に合っている。
日本でもサマータイム制度を勧める議論があるが、反対しましょう。このような制度を導入すると OS に複雑極まるパッチを当てなくてはならなくなります。誰が得をして誰が損をするかは明らかです。夏になったら早く出社すべきであると考えるのは各社の自由ですが他人に強制せずに単に出勤時間を各社の判断で変更すればよいだけです。
注釈: 分散システムの時刻合わせの問題点に関して、 CPUサーバと端末はファイルサーバの時刻によって決定されていることは iwane@lit.rd.nttdata.co.jp さんの指摘に負う所が大きい。時刻 B の存在は筆者の推定による。