ファイルシステム・サービス


LVM

論理ボリューム
論理ボリュームは1つ以上のパーティションからなり、1つのドライブ文字が割り当てられます。これは1つの連続したパーティションのように扱われます。ボリュームに割り当てられたドライブ文字は継続性があります。論理ボリュームの一部になっていないパーティションにはドライブ文字は割り当てられません野で、アプリケーションからアクセスすることはできません。論理ボリュームのタイプには互換ボリュームとLVMボリュームの2種類あります。LVMによって作成される各ボリュームにはボリューム   があります。

互換ボリューム
互換ボリュームはOS/2の前のバージョンや他のOSと互換性があります。これは単一の物理ハードディスク上の単一パーティションと同等で、ブート可能です。OS/2 Warp Server for e-busunessをインストールすると互換ボリュームが作成され、インストレーションのターゲットとしてインストーラブルに設定されます。

LVMボリューム
LVMボリュームは新しいボリュームタイプで前のバージョンのOS/2や他のOSからはアクセスできません。

ボリュームタイプの比較
 

互換ボリューム LVMボリューム
インストール可能・始動可能・ブート可能 Yes No
最大サイズ ディスク装置のサイズ(実際の使用可能最大サイズはファイルシステムの制限による) 2TB
使用可能なファイルシステム 386HPFS,HPFS,FAT 386HPFS,HPFS,FAT,JFS
マルチパーティション・ディスク No Yes
拡張可能 No Yes(JFSもしくは未フォーマットの場合)
フォールトトレランス Yes(386HPFS) No
パーティションID x'06'(16-bit FAT > 32MB) 
x'07'(Installable File System)
x'35'(OS/2 LVM)
ディスク・スパニング
ディスク・スパニングはディスクリンキングと同じとして考えることができます。複数の物理ディスク上の複数のパーティションを1つのLVMボリュームにリンクすることができます。ディスクスパニングにより複数のリンクしてLVMボリュームを好きなサイズで作成することができます。LVMボリュームは1つのドライブ文字で表現され、現在のすべてのファイルオペレーションは互換性をもっています。

動的なボリューム拡張
動的なボリューム拡張によりLVMのボリュームサイズをデータに影響を与えることなくふやすことができます。この動的な拡張はJFSの場合のみ利用することができます。他のファイルシステムで使用している場合には利用できません。LVMボリュームは追加のパーティションをリンクすることにより拡張します。

ドライブ文字の動的な割り当て
この機能によって、LVMボリュームと互換ボリュームのドライブ文字の管理がシステムのリスタートを行うことなくできるようになりました。以前のOS/2ではドライブ数はブート時に決められ、静的にアロケートされていたため、ドライブの追加や削除を行ったときにはリスタートする必要がありました。

継続的なドライブ文字
新しいLVMボリュームまたは互換ボリュームにドライブ文字を割り当てた後は、そのドライブのドライブ文字は明示的に変更したりボリュームの削除をしないかぎり維持されます。この機能によって、パーティションを設定しなおしたり、新しいディスクを追加することによりドライブ文字が変わってしまうという問題を回避することができます。
例えば、新しいハードディスクを追加して新しいボリュームとして定義した場合、CDROMのドライブ文字よりも後の文字をアサインすることができます。

注意
OSや他のコンポーネントが入っているボリュームのドライブ文字は変えないで下さい。オープンされたファイルのあるボリュームのドライブ文字を変更するとLVMを終了したあとでシステムをリスタートできなくなります。また、LIBPATHを必要とするアプリケーションはパスをハードコードしてあるようなアプリケーションでも問題がおきる可能性があります。
 


JFS

ジャーナル・ファイル・システム(JFS)はデータベース・ジャーナリング技術を使用しているファイルシステムで、ファイルの変更をシーケンシャルに記録してファイルシステムの完全性を維持します。
JFSはOS/2 Warp Server for e-business環境でハイパフォーマンスな32ビットファイルシステムを提供します。JFSは主として、パフォーマンスや信頼性が重要なサーバー環境で高パフォーマンスや高信頼性の要求を満たすことを目的に作られています。JFSはAIXのJFSによってすでに実証された技術を使用しています。また、拡張属性やケースセンシティブネームによる検索などのサポートも取り込まれています。JFSに含まれている重要なフィーチャーにはサイズを基本としたアロケーション、ディレクトリーのソート、動的なスペースアロケーションなどがあります。

JFSのフィーチャーとして他に以下のものがあります。

注意:
ジャーナル・ファイル・システムはLVMボリュームでのみ使用できます。LVMボリュームをブートボリュームとすることはできませんので、JFSをブートボリュームとすることはできません。



可変ブロックサイズ

JFSは512, 1024, 2048, 4096バイトのブロックサイズを各ボリューム単位でサポートします。これによって、アプリケーションの実行環境に合わせてディスクスペースの使用効率を最適化することができます。ブロックサイズを小さくすれば、ファイルやディレクトリーの内部的なフラグメンテーションは減少し、効率的にスペースを利用できます。しかしながら、小さいブロックサイズを指定すると、ブロックをアロケーションするためのアクティビティーがより頻繁に発生するためパスレングスが増大させる可能性があります。デフォルトのブロックサイズはスペースの使用率よりもパフォーマンスを重視して4096バイトになっていますので、サーバーシステムではこの点を主に考慮する必要があります。



オブジェクト名

ユニコード・ファイル名とディレクトリー名:
JFSはNLSイネーブルされており、ファイルやディレクトリー名をユニコードの文字列で保管、操作します。この保管方法はどのコードページが使用されているかに関係なくなくディレクトリーが正しくソートされることを保証しています。

ケースセンシテビティー:
ケースの扱い方についてはHPFSと同じです。名前はファイルシステムがうけとったとおりに保管およびリターンされますが、ディレクトリー検索時には無視されます。

ファイル名とディレクトリー名の最大長
JFSではファイル名とディレクトリー名の最大は254ユニコード文字に制限されます。また、パス名の最大は260文字です。この制限はIFSM(Installable File System Manager)の制限によるものです。


オンライン・ファイルシステム拡張

JFSはボリュームの拡張をアクティブな状態のままで行うことができます。JFSの空き容量がなくなっても、ボリュームサイズを増やすために、バックアップをとって、フォーマットし、リストアするといったようなことはする必要はありません。



オンライン・スペース・デフラグメンテーション

JFSではアクティブなボリュームのフリースペースのでフラグメンテーションをサポートしています。これはDEFRAGユーティリティーを使用して行います。ボリュームのフリースペースにフラグメンテーションが発生すると、ファイルシステムをデフラグメントすることにより、JFSはより効率的なI/Oが行えるようにアロケーションしなおしたり、空き容量不足を回避することができます。



低密度と高密度ファイルサポート

JFSはボリュームベースで低密度ファイルと高密度ファイルをサポートします。低密度ファイルと高密度ファイルの読み取りは同じように行われますが、書き込みのしかたが異なります。

正常な読み取りはデータブロックを返します。もし、読み込まれたデータがまだ書き込まれていなければJFSは0で埋められたブロック(すべてバイナリのゼロまたはNULLのバッファ)を返します。これは低密度の場合も高密度の場合も同じです。

低密度ファイルではファイル内のランダムなロケーションに書き込む場合に、間に何も書き込んでいないファイルブロック(ファイルの中で書き込まれたブロックよりも前に位置するブロックでそれ自身は書き込まれていないブロック)をあらかじめアロケートしておく必要はありません。たとえば、ファイルをクリエイトして、100ブロック目に書き込む場合、0から99まではあらかじめ書き込まれていない中間のファイルブロックということになります。もし、ファイルシステムが低密度ファイル用にフォーマットされていれば1ブロックがアロケートされます。

低密度ファイルではファイルサイズは書き込まれたうちの最高位のバイトで報告されますが、実際のファイル内のブロックの割り振りは書き込み操作がそのブロックに対して行われるまでは行われません。

低密度は大きな論理的なスペースを必要とするけれども、そのスペースのわずかなサブセットしか使わないようなアプリケーションで意味があります。

高密度ファイルではリソースはファイルサイズ分だけアロケートされます。上の例では、最初の書き込み(ファイル内の100ブロック目へのデータブロック)によってディスクスペース上に100ブロックがアロケートされます。つまり、ファイルシステムが高密度ファイル用にフォーマットされている場合、100ブロックがアロケートされます。

OS/2アプリケーションはほとんどの場合、高密度ファイルを使用するようになっているため、デフォルトでは新しいボリュームは高密度ファイル用となります。