互換ボリューム
互換ボリュームはOS/2の前のバージョンや他のOSと互換性があります。これは単一の物理ハードディスク上の単一パーティションと同等で、ブート可能です。OS/2
Warp Server for e-busunessをインストールすると互換ボリュームが作成され、インストレーションのターゲットとしてインストーラブルに設定されます。
LVMボリューム
ＬＶＭボリュームは新しいボリュームタイプで前のバージョンのＯＳ/2や他のＯＳからはアクセスできません。
ボリュームタイプの比較
| 互換ボリューム | ＬＶＭボリューム | |
| インストール可能・始動可能・ブート可能 | Ｙｅｓ | Ｎｏ |
| 最大サイズ | ディスク装置のサイズ（実際の使用可能最大サイズはファイルシステムの制限による） | 2ＴＢ |
| 使用可能なファイルシステム | 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) |
動的なボリューム拡張
動的なボリューム拡張によりLVMのボリュームサイズをデータに影響を与えることなくふやすことができます。この動的な拡張はJFSの場合のみ利用することができます。他のファイルシステムで使用している場合には利用できません。LVMボリュームは追加のパーティションをリンクすることにより拡張します。
ドライブ文字の動的な割り当て
この機能によって、LVMボリュームと互換ボリュームのドライブ文字の管理がシステムのリスタートを行うことなくできるようになりました。以前のOS/2ではドライブ数はブート時に決められ、静的にアロケートされていたため、ドライブの追加や削除を行ったときにはリスタートする必要がありました。
継続的なドライブ文字
新しいLVMボリュームまたは互換ボリュームにドライブ文字を割り当てた後は、そのドライブのドライブ文字は明示的に変更したりボリュームの削除をしないかぎり維持されます。この機能によって、パーティションを設定しなおしたり、新しいディスクを追加することによりドライブ文字が変わってしまうという問題を回避することができます。
例えば、新しいハードディスクを追加して新しいボリュームとして定義した場合、CDROMのドライブ文字よりも後の文字をアサインすることができます。
注意
OSや他のコンポーネントが入っているボリュームのドライブ文字は変えないで下さい。オープンされたファイルのあるボリュームのドライブ文字を変更するとＬＶＭを終了したあとでシステムをリスタートできなくなります。また、LIBPATHを必要とするアプリケーションはパスをハードコードしてあるようなアプリケーションでも問題がおきる可能性があります。
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ブロック目に書き込む場合、０から99まではあらかじめ書き込まれていない中間のファイルブロックということになります。もし、ファイルシステムが低密度ファイル用にフォーマットされていれば1ブロックがアロケートされます。
低密度ファイルではファイルサイズは書き込まれたうちの最高位のバイトで報告されますが、実際のファイル内のブロックの割り振りは書き込み操作がそのブロックに対して行われるまでは行われません。
低密度は大きな論理的なスペースを必要とするけれども、そのスペースのわずかなサブセットしか使わないようなアプリケーションで意味があります。
高密度ファイルではリソースはファイルサイズ分だけアロケートされます。上の例では、最初の書き込み（ファイル内の100ブロック目へのデータブロック）によってディスクスペース上に100ブロックがアロケートされます。つまり、ファイルシステムが高密度ファイル用にフォーマットされている場合、100ブロックがアロケートされます。
OS/2アプリケーションはほとんどの場合、高密度ファイルを使用するようになっているため、デフォルトでは新しいボリュームは高密度ファイル用となります。