VM 領域は、VOS アプリケーションで共有可能なアドレス空間としてよく使用されます。これは、複数のプロセスが同じアドレスにアクセスできるようにするための非常に効率的な方法です。主な欠点は、VOS の仮想メモリの制限により、スペースが 2 GB 以下に制限されていることと、他の目的のために利用可能な VM をカットしてしまうことです。
アドレス空間は、バイナリファイルにアドレスをマッピングし、ファイル I/O 操作でアクセスすることで、ファイルシステムを介して共有することもできます。これにより、VM のリージョンサイズの制限がなくなり、専用の VM を解放することができます。また、リージョンロックによる調整も可能ですが、共有された VM に直接アクセスするよりもはるかに高価です。
Posixアプリケーションでは、この目的のためにバイナリモードのストリームファイルを使用することがあります。このようにして、ファイルはアドレス空間のバッキングストアとして機能し、プロセスはfseek/fread/fwriteのようなファイル指向のインターフェースを使用して空間を共有します。
64ビットストリームファイル(Release 17.2で導入)以前のVOSでは、通常のストリームファイルは疎にできず、EOFを拡張するにはバイナリゼロのブロックを明示的に割り当てて書き込む必要があるため、これは非常に高価になります。例えば、必要なアドレス空間が2GBの場合、VOSは524,288ブロックのディスクストレージを必要としますが、その中にバイナリゼロ以外の値が含まれていることはごくわずかです。64ビットストリームファイルを使用すると、これらのタイプのアプリケーションをVOS上で効率的に実行することができ、実際に必要とされるだけのディスク容量を必要とします。Posixアプリケーションは、大容量のファイルを認識するために構築された場合、自動的に64ビットストリームファイルの恩恵を受けます。(詳細については、OpenVOS POSIX.1 リファレンス マニュアル、R502「既存のアプリケーションを 64 ビット ストリーム ファイル環境に移植する」を参照してください)。
ファイルバックアップされた共有アドレス空間の同様の使用は、ネイティブのVOSアプリケーション、すなわちs$インターフェイスを使用しているアプリケーションでも可能です。VOS は、この技術を使用する際にディスク I/O を大幅に削減できる特長 をいくつか提供しており、基本的には CPU の使用量が主なコストとなります。リリース17.2では、疎な64ビットストリームファイルが導入されたことで、共有アドレス空間へのこのアプローチがさらに魅力的になりました。
メモリ常駐とRAMファイル
メモリ常駐ファイルは set_open_options コマンドを使用して識別します。ディスクキャッシュの設定可能な部分は、メモリ常駐ファイル用に予約されています。利用可能な物理メモリやキャッシュの他の用途にもよりますが、最大で 9～10 GB になります。一度キャッシュに入ったメモリ常駐ファイルのブロックは、合計数がキャッシュのその部分を超えない限り、後続のディスクリードが発生することはありません。その場合、最も最近参照されたブロックがこの利点を保持します。
RAM ファイルは永続的ではないデータを含むファイルで、アプリケーションが使用を終了したときにディスクにコミットする必要のないデータが含まれている場合に便利です。set_ram_file コマンドを使用することができますが、s$delete_file_on_close が呼び出されたファイルは、その時点から自動的に RAM ファイルとして扱われます。
メモリ常駐ファイルはその後のディスクリードが発生しませんが、ブロックは一定の間隔で書き込まれ、キャッシュで許可される変更ブロックの数は他のファイルと同様に制限されています。変更されたブロック数の制限は、ファイルが閉じられたりフラッシュされたりしたときに何百万ものブロックを書き込まなければならないような状況を防ぎます。4 GB のファイルは 100 万ブロックを占有します。この制限は、データを書き込める速度よりも速く変更するアプリケーションの速度を低下させる可能性があります。RAM ファイルは、ファイルが非アクティブ化された場合でも、データをディスクに書き込む必要がないため、このタイプのスロットリングを回避することができます。
メモリ常駐型 RAM ファイルを使用することで、ほとんどのディスク I/O を回避したキャッシュメモリ内のアドレス空間を提供します。このアドレス空間はキャッシュサイズによってのみ制限され、仮想メモリではなく利用可能な物理メモリに基づいています（キャッシュマネージャは物理メモリにアクセスするために VM アドレスを共有しています）。注意：単一のファイルベースのアドレス空間は最大512GBまで拡張できますが、キャッシュのメモリ常駐部分より大きくなると、少なくとも最近参照されていないブロックについてはI/Oの利点を失います。
例
ストリームファイルの内容は、s$seq_position を使用してバイト指向のオペコードでアクセスし、s$read_raw/s$write_raw を使用して調べたり変更したりすることができます。64 ビットのストリームファイルは、ファイル内の使用される領域、すなわちゼロ以外の値に設定された領域を除いて、大きなディスク容量を必要とせずに最大 512 GB までのストリームファイルを作成することができます。
例えば
create_file scratch -organization stream64 -extent_size 256
これにより、"スクラッチ"というDAE-256ファイルが作成されます。
セットラムファイルスクラッチ
これにより、このファイルが無制限にキャッシュにアクセスできるようになり、変更されたブロックの数に関連したスロットリングを回避し、バックグラウンドやキャッシュが枯渇して他の目的のために必要になった場合を除いて、ディスクへの書き込みを完全に回避することができるようになります。これはプログラムでも s$set_ram_file で行うことができます。最後のオープナーがファイルを閉じると、キャッシュ内のデータは破棄され、決してディスク書き込みを必要としません。このコマンドを使用する際には、ファイルは空でなければなりません。
set_open_options scratch -cache_mode memory_resident
これにより、このファイルのブロックのうち可能な限り多くのブロックがキャッシュに無期限に保持されるようになります。実際の数は、 set_tuning_parameters コマンドで設定されたキャッシュサイズとメモリ滞留率の係数である。
以下のシーケンスは、プログラムでの使用例を示しています（test_system_callsを使用して図示しています）。
tsc: s$attach_port p スクラッチ
tsc: s$open p -io_type update
では、512GB程度のアドレス空間を提供してください。
tsc: extend_stream_file p 549235720192 (s$control EXTEND_STREAM_FILE)
を使用してデータを保存します。
tsc: s$seq_position_x p bwd_by_by_bytes 3 (拡張後の現在位置はEOF)
tsc: s$write_raw p END
tsc: s$seq_position_x p bof
tsc: s$write_raw p START
tsc: s$seq_position_x p fwd_by_by_bytes 2000
tsc: s$write_raw p 2000
注意: s$seq_position は、絶対バイトオフセットへの位置合わせのためのオペコードもサポートしています。
結果はこのようになり、ファイルはディスク上の2つのデータブロックを占有しています。
.dump_file scratch -brief
%swsle#Raid4>otto>d-3>new>スクラッチ 15-02-25 16:04:17 EST
ブロック番号1
010 00000000 00000000 00000000 00000000 |…………….|
=
7D0 00000000 00323030 30000000 00000000 |…..2000…….|
7E0 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 00000000
ブロック番号 131870736
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00454E44 |......END|........
注意: ブロック 1 と 131870736 はキャッシュされており、通常はディスクに書き込まれることはありません。上の dump_file コマンドはキャッシュされたブロックを見ているのであって、ディスクを読んでいるわけではありません。
RAM ファイルが非アクティブ化されると（どのプロセスでも開かなくなると）、VOS はファイルを切り捨て（変更されたブロックをディスクに書き込まないように）、すべてのディスク領域を解放します。典型的な状況では、上記のシーケンスは、2つのファイルマップブロックの書き込みを除いて、ディスクI/Oを全く行わず、最終的には破棄されます。
tsc: s$close p
これでファイルは空になり、ディスクスペースを占有しなくなりました。
tsc: ...dump_file スクラッチ
%swsle#Raid4>otto>d-3>new>スクラッチ 15-02-25 16:07:12 est