IBM i のウンチクを語ろう
～ その7：IBM i のウンチクを語ろう ～ 単一レベル記憶-2 ～
皆さん、こんにちは。今回のテーマは前回に引き続き単一レベル記憶です。端折らないと前回冒頭に述べた手前、今回もしばらく背景の説明が続きますが、お付き合いいただければと思います。AS/400産みの親と言われるソルティス博士も、テクノロジーを理解するにはその仕組みだけでなく、何故それが採用されたのかという理由を知る事も重要である、と言っています。私のこのコラムでも、できる限り背景を説明することに字数を割くよう心がけています。
前回はハードウェアの観点からディスク・アクセス、ソフトウェアの観点からタスク・スイッチング、のパフォーマンス上の懸念点について述べました。今回はファイル・システムの課題、ファイルをオープンする（開く）作業を行うことによって、その裏では何が行われているのかを探るところから始めたいと思います。
例えばWindows PCのドキュメント・ファイルは、通常ディスクの中、ツリー構造化されたフォルダー（ディレクトリ）、サブ・フォルダーの下に配置されます。PCのエクスプローラの当該ファイルのアイコン上で、マウスをダブル・クリックするとファイル・オープン作業が始まります。ファイルはどのディスク・ドライブの中に配置されているのかは最初に人が特定するわけですが、Windowsはディスクの円盤上のどこにそのファイルが配置されているのかを知りません。フォルダー情報を頼りに、各ディスク円盤固有の「住所録」が格納されている箇所を照会して、ディスク上の位置情報を取得します。住所を知った上で駅前の交番に行き、目指す場所への道順を聞くようなものです。初めて目指す場所にたどり着くためにはこのようなプロセスが必要ですが、二度目以降は道順を忘れないようにしておけば効率良く移動できます。そしてファイルの位置情報はもうアクセスしないと決するまで、すなわちファイル・クローズするまでは、今後のためにすぐに取り出せる場所に確保しておきます。一時にオープンされるファイルは複数あるのが通常ですので、位置情報もそれぞれを識別できるようにして、複数持っておきます。参考までにCやPerl言語では、このファイル・オープンに伴って生成された位置情報を識別するものをファイル・ハンドルと呼んでいます。
ドキュメント・ファイルの在処を特定したら、次はその編集作業を開始できるようにするために、ファイルをメモリにコピーします。メモリはディスクと異なり、アドレスによってアクセス管理されます。しかしながらマシンの搭載メモリ容量が、オープンされる全てのファイルを収容できるほどの十分な大きさを持つことはまずありませんし、いくつかのファイルをオープンしただけでメモリ領域が満杯になってしまうようでは、後から優先度の高い作業に取り掛かる事ができなくなってしまいます。そうならないためにもできる限り、メモリ消費量を最小限に抑えたいものです。そこで、現代のほとんどのマシンにおいては、メモリよりも容量単価が低くて大容量のディスクの一部を間借りして、メモリであるかのように振舞う領域、すなわち仮想メモリを搭載しています。これにより実際の搭載容量よりも大きな、見た目上のメモリ空間を確保します。
前回の当コラムにて、ディスクはシステム全体の中では途方もなく遅いデバイスであることを説明しました。極端な例ですが、プロセッサの1クロックを1秒とすると、遅延時間は半年にもなるような機器でした。フォルダー管理下のディスク上のファイルが、仮想メモリ、すなわちアドレス管理下のディスクにコピーされる、というのは途方もない作業です。
ファイルを仮想メモリ（ディスク）上に置いたままではパフォーマンスがあがりませんので、すぐに作業するべき領域、例えばドキュメントの最初のページを「本物の」メモリに再度コピーします。これでようやくファイル・オープンが完了し、ドキュメントの編集作業を開始できる状態になりました。
ファイルをオープンするという作業は、極めて面倒で時間のかかるプロセスです。特に一台のサーバー上で、複数のユーザー、複数のアプリケーションを同時にサポートするIBM i にとっては、数多くのファイルを同時にオープンする必要があるので何とか工夫したいところです。本来は同じ目的を持っているにも関わらず、二種類の管理方式、二種類のデバイスが存在することが問題です。だからと言って、高速化のためにディスクを廃して巨大メモリを搭載するという考え方もありますが、一般的にはコストが高くなり過ぎます。ディスクとメモリというデバイスは無くならないとしても、両者全体を覆いつくすような、本来はメモリ用のアドレス管理方式に一本化してしまえば、ファイル・オープンのプロセスを著しく単純化でき、パフォーマンス向上に寄与しそうです。もし将来全く新しい記憶デバイスが登場しても、やはりアドレス管理方式を貫きとおすこととします。これが単一レベル記憶の考え方です。
さて単一レベル記憶がカバーできる空間の大きさは、メモリとディスクの全領域を含むものでなくてはなりません。1988年にAS/400が発表された当初は248バイトの大きさを持っていましたが、1995年の64ビットRISCプロセッサの採用に伴って、264バイトに拡張されています。参考までにIBM汎用機のオペレーティング・システムであるz/OSの歴史（https://ibm.biz/BdsSBv）を紐解くと、旧来の24ビット・アーキテクチャーに代わり、31ビットのSystem/370-XAアーキテクチャーが登場したのが1983年、その後64ビットに拡張されたのが2000年とあります。IBM i はその登場時から汎用機に比べて17ビット分大きく、64ビット化も5年早かったというわけです。そしてさらに将来を見据えて、IBM i の単一レベル記憶は2128バイトの大きさまでサポートできる余力を持っています。これは具体的には、アドレスを指し示すポインターは128ビットの長さを持っているということです。
IBM i のアーキテクチャー上の最大記憶容量がどの程度の大きさなのか、ちょっと計算してみました。IBMの最上位ストレージサーバーDS8880の最大物理容量は5222TB（5222×240バイト）とあります（https://ibm.biz/BdsSd4）。このような構成のDS8880が1兆（240）台並んでいるようなデータセンターが320億（235）ヶ所あっても、まだ一台分のIBM i の限界に届かない計算です。（2128 = 213×2115 = 8192×2115 > 5222×240×240×235 = 5222×2115）
ディスク容量が年々増え続けることを心配したあるIBM i ユーザーの方が、2128バイトの記憶域でも足りなくなったら、IBM i はどうなるのかを開発者に質問したことがあります。開発者は即座に回答しました。
「ここにいる皆が存命中にそうなることはあり得ないので心配無用」
今世紀中も大丈夫そうですね。
そろそろ紙面も尽きてきたようです。次回も単一レベル記憶を続ける予定です。
