VOSストリームファイルのサイズは、約2 GBまでと制限されています。これは、s$seq_position、s$get_port_status、s$lock_region などのインターフェースの定義において、ファイル内の位置を示すために符号付き32ビット変数が使用されており、2**31が表現可能な最大値であるためです。ストリームファイルでは、位置は他のVOSファイル構成におけるレコード番号とは異なり、バイトオフセットで指定されます。
64ビットストリームファイルはリリース17.2から利用可能となり、VOSファイルシステムによってのみサイズの上限が制限されます（ファイルの最大サイズは512 GBです）。これらのファイルは、拡張性の向上に加え、特にバイナリデータへのアクセスにおいて他の利点も提供します。通常のストリームファイルとは異なり、すべてバイナリ0で構成されるブロックはディスク上のスペースを占有せず、そのようなデータの読み取りにはディスクアクセスが不要です。
POSIX準拠のアプリケーションは、ソースコードを変更することなく、大容量ファイルに対応するように簡単に構築できます。17.2以降のモジュールが動作するディスク上に作成される新しいファイルは64ビット（一般にstream64と呼ばれる）ファイルとなり、17.2以前のモジュール上では通常のストリームファイルとなります。 VOS s$ インターフェースまたは VOS Language I/O を使用するアプリケーションはネイティブアプリケーションと呼ばれ、ストリームファイルを使用するアプリケーションは、バイト単位の位置指定操作を使用しない場合（BOF または EOF への位置指定はバイト単位の位置指定とは見なされません）、あるいはファイルが stream64 ファイルである限り、stream64 ファイルにアクセスできます。ただし、stream64 ファイルを作成するには、アプリケーションの修正が必要となります。
64ビットのストリームファイルを利用する場合に役立つ情報を以下にまとめました。内容は以下の通りです：
既存のアプリケーションと互換性
– 既存の POSIX アプリケーション
– 既存のネイティブアプリケーション
– 互換性
– オープンソース製品
スパース割り当て
ファイル変換
物理的特性
– エクステント
– エクステントがスパース割り当てに与える影響
– フレキシブル・エクステント
ツール
– モジュール上の64ビットストリームファイルの検索
– ブロック比較
– スパースファイルの比較
既存のアプリケーションと互換性
– 既存のPOSIXアプリケーション
リリース 17.2 以降、Posix アプリケーションを大容量ファイル対応でビルドできるようになりました。これにより、ターゲットが 17.2 以降が動作するディスク上にある場合、64 ビットのファイルにアクセスしたり、それらを作成したりできるようになります。 アプリケーションが POSIX 準拠である場合（例えば、必要な箇所で int ではなく off_t などの型を使用するようにコーディングされている場合）、ソースコードの変更は不要です。OpenVOS POSIX.1 リファレンスマニュアル R502 の「既存のアプリケーションを 64 ビットストリームファイル環境へ移植する」に記載されている手順に従ってビルドするだけで済みます。 作成されるファイルが 17.2 以前のバージョンが動作するモジュール上のディスクにある場合、通常のストリームファイルが作成されます。ファイルサイズを 2 GB 以上に拡張しようとしない限り、問題なく動作します。したがって、POSIX アプリケーションで大容量ファイルを使用できるようにしても、相互運用性の面で追加のコストは発生しません。リリース 17.2 以降、VOS がサポートするほとんどのオープンソース製品は、64 ビットのストリームファイルを適切に生成および処理します。
POSIX準拠のアプリケーションは、ソースコードを変更することなく、大容量ファイルに対応するように簡単に構築できます。17.2以降のモジュールが動作するディスク上に作成される新しいファイルは64ビットストリーム（通称stream64）ファイルとなり、17.2以前のモジュール上では通常のストリームファイルとなります。 VOS s$ インターフェースまたは VOS Language I/O を使用するアプリケーションはネイティブアプリケーションと呼ばれ、ストリームファイルを使用するアプリケーションは、バイト単位の位置指定操作を使用しない場合（BOF または EOF への位置指定はバイト単位の位置指定とは見なされません）、あるいはファイルサイズが 2 GB 未満である場合に限り、stream64 ファイルにアクセスできます。
– 既存のネイティブアプリケーション
多くのネイティブアプリケーションでは、組織が STREAM ではなく STREAM64 であることを示すために、create_file コマンド（または s$create_file）の使用方法を変更するだけで済みます。アプリケーションが位置指定操作を使用しており、ファイルサイズが 2 GB を超える場合、s$seq_position はエラーを発生させます。より大きなファイルに対応するには、s$seq_position の呼び出しを s$seq_position_x に変更する必要があります。 繰り返しになりますが、_x インターフェースを使用しても、位置指定引数がサポート範囲内にある限り、_x インターフェースをサポートしていないモジュール上に存在する通常のストリームファイルをアプリケーションが参照する機能には影響しません。したがって、この変更を行うことで、あらゆる種類のストリームファイルにアクセスできるようになり、相互運用性に何ら支障をきたすことはありません。
バイト位置（s$seq_read、s$seq_write、s$seq_position BOF/EOF）を通信しないインターフェースのみを使用している既存のアプリケーションは、変更を加えることなくstream64ファイルを処理できます。多くのアプリケーションは、シーケンシャルファイルかストリームファイルかを問わずASCIIファイルを処理するように作成されているため、サイズに関わらず64ビットのストリームファイルを処理するために変更を加える必要はありません。
64ビットのストリームファイルにはインデックスを設定できないため、インデックス付きストリームファイルをstream64形式に変換することはできません。また、既存のインデックス実装の制限により、インデックス付きストリームファイルのサイズは2 GBを超えることはできません。
– 互換性
64ビットのストリームファイルには多くの利点があるため、インデックスが不要な場合は、可能な限り採用すべきです。
ファイルのサイズが 2 GB を超えない限り、そのファイルは古いバージョンの VOS を実行しているモジュールにコピーまたは移動することができ、そこでは通常のストリームファイルとして扱われます。ファイルが「制限付き」でない限り、stream64 ファイルを含むディスクを古い VOS に移動することさえ可能です。 ファイルは、サイズが 2 GB を超えたり、スパースに割り当てられたりすると「制限付き」となります。このようなファイルを含むディスクを 17.2 以前の VOS に移動した場合、そのファイルは開くことができません（このような移動を計画している場合は、制限付きファイルを特定するためのツールが利用可能です）。 ただし、古いバージョンの VOS を実行しているアプリケーションは、ネットワーク経由であらゆる種類の stream64 ファイルを開き、読み書きすることができます。発生するエラーは、アプリケーションが 17.2 以降で実行されている場合と同じです（例えば、ファイルが 2 GB を超える場合のバイト位置指定に s$seq_position を使用する場合など）。
– オープンソース製品
VOS でサポートされているオープンソフトウェアの多くは、ftp、sftp、samba など、大容量ファイルに対応するように変換されています。これにはいくつかの影響があります。 リリース 17.2 以降、ストリームファイルを VOS に FTP で転送する際、ファイルが大きすぎることを心配する必要はありません。FTP デーモンが stream64 ファイルを作成するためです。FTP はすべてのバイトを書き込むため、たとえファイルの大部分がバイナリの 0 で構成されていたとしても、結果として生成されるファイルはスパースファイルにはなりません（次のセクションを参照）。転送されたファイルを単純にコピーするだけで、そのファイルが占有するディスク容量を大幅に削減できる可能性があります。 FTPで転送したファイルにインデックスを追加する予定がある場合は、まずそのファイルを通常のストリームファイルに変換する必要があります（もちろん、その長さは2GBを超えてはなりません）。
疎な割り当て
ストリーム64ファイルの場合、すべてがバイナリ0で構成されるブロックは必ずしも割り当てられるわけではないため、ディスク領域を必要としません。GNUの「truncate」コマンド（>system>gnu_library>bin 内にあります）を使用すると、ストリームファイルのサイズを短縮したり拡張したりすることができます。バージョン18.0では、VOSはreset_eofという同様のコマンドを提供しています。 EOF以降のデータは未定義ですが、EOFが拡張された場合、現在のEOFの位置以降のファイル内容は常にバイナリ0に設定されます。
一般的なストリームファイルとstream64ファイルを例に考えてみましょう：
create_file stm -organization stream
create_file s64 -organization stream64
また、それぞれのファイルの内容が「abc」であると仮定する。各ファイルのサイズを20億バイトになるように拡張したい：
bash
bash-4.2$ truncate -s 2000000000 s64
bash-4.2$ truncate -s 2000000000 stm
最初のリクエストは即座に完了しますが、2番目のリクエストには数分かかります。ファイルは論理的に同等です：
bash-4.2$ ls -l
合計 244382
-rwxrwxrwx 1 nobody nobody 2000000000 2月 25日 14:08 s64
-rwxrwxrwx 1 nobody nobody 2000000000 2月 25日 14:11 stm
しかし、VOSのlistコマンドで示されるように、各ファイルが占有するディスクブロックの数は大きく異なります：
一覧
ファイル数：2、ブロック数：488764
w 4 s64
w 488760 stm
リリース 18.0 では、VOS の reset_eof コマンドを使用して同様の操作を行うことができます：
reset_eof s64 2000000000
通常のストリームファイルを数千ブロック以上拡張しようとすると、VOSコマンドは警告を表示します。これは非常に負荷の高い操作だからです。
reset_eof stm 2000000000
eofを2000000000に拡張すると、ファイルに488281ブロックが追加されます。stmを1999999996バイト拡張しますか？ (はい、いいえ)
以下は、拡張された64ビットのストリームファイルです。これは、2つのデータブロックのみで構成されています：
dump_file s64
ブロック番号 1
000 6162630A 00000000 00000000 00000000 |abc………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
ブロック番号 488282
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
通常のストリームファイル「stm」を出力すると、割り当てられた全488,282個のブロックが表示され、その大半はバイナリ形式のゼロで構成されています。
dump_file stm
ブロック番号 1
000 6162630A 00000000 00000000 00000000 |abc………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
ブロック番号 2
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
ブロック番号3
…
ブロック番号 488282
000 00000000 00000000 00000000 00000000 |…………….|
=
400 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |…………….|
=
FF0 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |…………….|
とはいえ、compare_files や diff はこれらのファイルを同一と見なしますが、通常のストリームファイルのすべてのブロックを読み込む必要があり、この場合、数分かかることがあります：
ready;compare_files s64 stm
ready 14:29:47
ready 14:31:24 45.877 46
ファイル変換
convert_stream_file コマンドは、シーケンシャルファイルとストリームファイルの各タイプ（stream、64-bit stream、sequential、および extended sequential）間の変換や、エクステントの変更を行うために利用できます。 通常、変換にはファイルの内容のコピーが伴い、この点では、空のターゲットファイルを作成し、-truncate オプションを指定して copy_file を使用する場合と似ています。convert_stream_file を使用すると、ファイルをその場で変更することができ、変換を試みる前に、既存の内容が要求された新しい形式で表現可能であることを確認できるという利点があります。
There are cases where a stream file can be reset to stream64 and vice versa without conversion, i.e., without copying contents. This is done by resetting the directory entry and is possible only if the file is not sparse, is less that 2 GB and extent size is not changed. This can be useful when migrating a disk containing stream64 files to a pre-17.2 module and again if the disk is moved back. The set_stream_files command is available for this purpose. It is a privileged command intended for use by a System Administrator: it takes a directory as input and resets files in that directory, and optionally in all sub-directories. It affects only those stream64 files which can be reset without conversion (not sparse and otto>stm
file organization: stream file
last used at: 15-02-25 14:34:45 est
…
extent size: 1
next byte: 2000000000
blocks used: 488760 <<<<<
次に：
convert_stream_file stm -to stream64 -extent_size 8
display_file_status stm
file organization: stream file (64-bit/rstr)
last used at: 15-02-25 14:39:16 est
…
extent size: 8
next byte: 2000000000
blocks used: 18 <<<<
sparse: yes
生成されたファイルは、スパースファイルとなったため、「制限あり (64-bit/rstr)」と表示されます。copy_file コマンドでもスパースファイルが生成されます。stream64 ファイルを通常の stream ファイルに変換すると、すべてのブロックがインスタンス化されるため、生成されるファイルは元のファイルよりもかなり大きくなる可能性があります。
stream64 ファイルでは、たまたまバイナリ上の 0 のみを含むブロックがディスク上に割り当てられるかどうかは保証されません。たとえば、あるブロックに 0 を書き込んで結果としてそのブロック全体が 0 になった場合、そのブロックは割り当てられたままになります。また、プログラムが明示的に 0 データを書き込んでブロックを埋めた場合も同様です。書き込みが行われたことのないブロックのみが未割り当てのままとなります。copy_file および convert_stream_file は、バイナリ上の 0 のみを含むブロックを書き込むことはありません。
物理的特性
– エクステント
VOSファイルの実際の成長限界は、そのエクステントサイズによって決まるため、エクステントとは何かを理解することが重要です。 VOSファイルマップには、ファイル内の各4kブロックに対応するディスクアドレスが格納されています。このマップは523792エントリまでしか保持できないため、エクステントを持たないファイルのサイズは2145452032バイト（523792 × 4096）に制限されます。これは2**31をわずかに下回る値であり、したがって、通常のストリームファイルのサイズ拡大における実際の制限となります。
エクステントとは、ディスク上の N 個の連続したブロックのグループであり、N はエクステントサイズを表します。エクステントを介して割り当てられたファイルのファイルマップには、エクステント内の最初のブロックのアドレスが含まれるため、ファイルマップははるかに大きなファイルを表現することが可能になります。 動的に割り当てられたエクステントでは、最大256のエクステントサイズが許可され、512 GBのファイルを作成することが可能です（注：エクステントサイズを256より大きくできる静的に割り当てられたエクステントは、ページングファイルでの使用を除き非推奨となっています。これらは多くの制限やパフォーマンス上の問題を抱えており、一般的な用途には不向きです）。
2 GBを超えるように拡張するには、stream64ファイルにエクステントが含まれている必要があり、その値によって実際の拡張上限が決まります。例えば、
create_file stm64 -organization steam64 -extent_size 32
最大64 GBまで拡張可能なファイルが作成されます。
リリース 17.2 では、Posix Runtime によって作成されるファイルのデフォルトのエクステントサイズは 8 であり、最大 16 GB まで拡張可能です。このようなファイルは 1 回につき 8 ブロックずつ拡張されるため、ファイルの最小サイズは 8 ブロックとなります。このデフォルト設定はシステム管理者がモジュールごとに変更できますが、拡張可能な容量が大きいほど、ファイルの最小サイズも大きくなります。 エクステントサイズが大きいと、非常に小さなファイルを多数生成するアプリケーションにとって問題となる可能性があります。
– エクステントがスパース割り当てに与える影響
通常、書き込みが行われないブロックは、stream64ファイルでは割り当てられません。ただし、エクステント内の1つのブロックに書き込みが行われた場合、たとえ一部のブロックがすべてバイナリ0で構成されていたとしても、そのエクステント内のすべてのブロックが割り当てられます。
文字列「abc」を含む非エクステントファイル（stm1）が、エクステントサイズ8のファイル（stm8）に変換されると仮定する：
dump_file stm1
ブロック番号 1
000 6162630A 00000000 00000000 00000000 |abc………….|
010 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
convert_stream_file stm1 stm8 -extent_size 8
dump_file stm8
ブロック番号 1
000 6162630A 00000000 00000000 00000000 |abc………….|
010 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
ブロック番号 2
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
ブロック番号3
…
ブロック番号 8
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
-brief オプションはリリース 18.0 で dump_file に追加されたもので、物理的には存在するが「空」（実際には存在しない可能性がある）ブロックとして扱われるブロックを表示したくない場合に役立ちます。DAE-8 ファイルでこのオプションを使用する例を以下に示します：
dump_file stm8 -brief
ブロック番号 1
000 6162630A 00000000 00000000 00000000 |abc………….|
010 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
これは、固定ファイルの相対パスにおいて、すべて「-1」で構成される「空の」ブロックを隠すのにも有効です。
– フレキシブル・エクステント
リリース18.0では、フレキシブルエクステントが導入され、小さなファイルを1ブロックずつ拡張できるようになりました。ファイルが大きくなるにつれて、エクステントの値も変化します。これは、リリース18.0においてPOSIXアプリケーションによって作成されるすべてのファイルのデフォルト設定であり、create_fileコマンドで特定のエクステントサイズを指定しない場合にも適用されます。
create_file flex -organization stream64 -extent_size
フレキシブルエクステントを持つファイルは「flexファイル」と呼ばれます。フレキシブルエクステントを持つことができるのはstream64ファイルのみです。display_file_statusコマンドでは、flexファイルのエクステントサイズは「flex」と表示されます。
display_file_status flex
名前: %swsle#Raid4>flex
ファイル構成: ストリームファイル (64ビット)
最終更新日時: 2015年2月25日 12:06:25 EST
…
動的エクステント: あり
エクステントサイズ: flex
18.0以前のモジュールで display_file_status コマンドを実行すると、次のように表示されます：
エクステントサイズ：-1
Flexファイルを17.2モジュール上のディスクにコピーすると、そのモジュールでデフォルトとなっているエクステントが割り当てられます。17.1以前のモジュールにコピーした場合、結果は通常のストリームファイルとなります。
リリース 17.2 以降では、compare_files はストリームファイル間のエクステントサイズの差異を認識せず、エクステントに関係なくファイルは同一と見なされます。たとえば、%swsle#m109_mas が 17.2 を実行しているモジュール上にあると仮定します：
copy_file flex %swsle#m109_mas>Stratus
compare_files flex %swsle#m109_mas>Stratus>flex
完了 14:42:38 0.001 6
17.2以前のモジュールで `compare_files` を実行すると、次のような差異が表示されます：
compare_files %swsle#Raid>flex %swsle#m109_mas>Stratus>flex
A (%swsle#Raid4>flex) は B (%swsle#m109_mas>Stratus>flex) と一致しません。
– 2つのファイルの一部の属性が一致しません：
エクステントサイズ -1 8
Flexファイルの最大容量は512 GBをわずかに下回り、具体的には540,142,534,656バイトとなります（DAE-256の549,235,720,192バイトに対し）。しかし、小さなファイルは1ブロックずつ、次に8ブロック、32ブロック、そして256ブロックと段階的に拡張されるという利点があり、常に256ブロック単位で拡張されるDAE-256とは異なります。
flexファイルが含まれているディスクを、バージョン18.0以前のモジュールにマウントしないでください。ディスク内にflexファイルが存在するかどうかを簡単に確認できるツールがあります。 誤ってマウントした場合、それらのファイルは表示されず、アクセスすることもできません。このようなファイルや、それらを含むディレクトリは削除できないため、ディスクを 18.0 以降が動作しているモジュールに戻しても、そのまま残ります。ただし、18.0 以前のモジュールでサルベージを行うと、すべての flex ファイルが削除され、その領域が解放されます。
ツール
– モジュール上の64ビットストリームファイルの検索
ディスクを古いバージョンのVOSに移行する必要がある場合、その古いリリースと互換性のないファイルを見つけ出す必要があります。この作業を支援するコマンドが用意されています：
locate_stream_files -form
—————————– locate_stream_files ————————-
directory_names:
-depth:
-type: 64-bit
-brief: no
-long: no
-type には、flex、sparse、large（その特定の特性を持つ 64 ビットのストリームファイルを検索します）のほか、all（すべてのストリームファイルを検索します）も指定できます。
-depth オプションに応じて、サブディレクトリが検索され、ファイルに（type で指定されていない）属性がある場合は、その属性に関する情報とエクステントサイズも表示されます。ディレクトリ名が指定されていない場合は、モジュール上のすべてのディスクがルートから検索されます。例：
locate_stream_files - 64ビット版
ディスク上のディレクトリを確認中 %swsle#raid0-1…
%swsle#raid0-1:
smb_test.stm64 (FLEX/large)
smb_test.stmb
64ビットストリームファイルは合計2個です。
ディスク上のディレクトリを確認中 %swsle#raid0-2…
%swsle#raid0-2:
big_stream (FLEX)
smb_test.stm (FLEX)
smb_test.stm64a (FLEX/large)
64ビットのストリームファイルは合計3つです。
ディスク上のディレクトリを確認中 %swsle#Raid4…
%swsle#Raid4>otto:
b3 (DAE-8)
big (DAE-256/large/sparse)
…
– ブロックの比較
リリース 17.2 および 18.0 では、compare_files コマンドに、ストリームファイルの処理に役立つ新しいオプションが追加されました。VOS 構造化ファイルタイプの場合、ブロックごとの比較は通常、あまり有用ではありません。なぜなら、値が異なる 2 つのブロックが、同じ論理レコードを表していることがよくあるからです。たとえば、相対ファイルのレコードにおいて、現在の長さを超えた部分の未使用データは予測不可能です。 さらに、シーケンシャルファイルには未定義のフィラーバイトが含まれています。拡張シーケンシャルファイルの場合、レコードサイズが異なると、同じ論理レコードを表しているにもかかわらず、ブロックの内容は完全に異なってきます。
しかし、固定ファイルやストリームファイルの場合、ブロック単位の比較が役立つこともあります。問題は、compare_files がレコード単位で動作し、エディタで特定できるレコード番号（または行番号）に基づいて差異を表示するように設計されている点にあります。このため、レコード単位で構成されていないバイナリストリームファイルでは問題が生じていました。 どのファイルでもレコードサイズは32767バイトに制限されているため、ストリームファイルにおいて、NLレコード区切り文字を挟まずに32kバイトを超えるシーケンスが発生した場合、s$seq_readを使用すると次の32767文字が読み込まれ、次のバイトがNLであるかどうかは区別されません。 このため、NL文字で区切られた文字列ではなくバイナリ値を保持するストリームファイルにおいて、レコード指向の比較結果は曖昧なものとなります。
この問題はリリース17.2で対処されました。compare_filesは、以前誤って成功と判定されていた可能性のあるケース、具体的には「32767文字の後に改行（NL）が続く」場合と「32767文字の後に改行（NL）が続かない」場合を検出するようになります。このようなケースが発生した場合、ストリームファイルに32767文字を超えるレコードが含まれていることを示すエラーが報告されます。このようなケースが発生しなければ、レコード指向の結果は有効であり、信頼することができます。 しかし、いずれにせよ、単にファイルが同一であることを確認したいだけの場合、非構造化ファイルのブロック単位での比較は、レコード単位の方法よりもはるかに高速です。ブロック単位の比較の問題点は、目印となるレコードがないため、最初の不一致が見つかった後の比較は、多くの場合、意味をなさなくなることです。
リリース17.2では、この目的のためにcompare_filesコマンドに-compare_blocksオプションが追加されました。これにより、構造化されていないファイルがブロック単位で同一であるかどうかを迅速に検出し、差異が生じているブロックを特定できます。また、ごく稀なケースとして、差異がオーバーレイ（特定のバイトが挿入や削除ではなく上書きされた状態）によって生じているものの、ファイルの残りの部分は同一である場合のために、-continueオプションも利用可能です。 これにより、ファイルの残りの部分で異なるブロックの範囲が表示されます。例えば、バイトが挿入された場合（オーバーレイされた場合とは対照的に）、残りのすべてのブロックが異なることになります。つまり、レコード比較で行われるような再同期は、ブロック比較では不可能です。しかし、前述のようなケースでは、この追加情報によって、違いが数ブロック内のオーバーレイされたバイトのみであり、おそらくタイムスタンプのようなものを表していることが確認できるでしょう。
-compare_blocks と -continue の組み合わせの例として：
compare_files flex dae256 -compare_blocks -continue
A (%swsle#m111_mas>Stratus>Newman>flex) は B (%swsle#m111_mas>Stratus>Newman>dae256) と一致しません。
– データブロック 2 から 24 までが異なります。
– データブロック 33 から 488 までが異なります。
– ファイル B には 272 個の追加ブロックがあります。
– スパースファイルの比較
`compare_files` コマンドは、ファイル内に物理的に存在するすべてのブロックを検査します。これはスパースファイルの場合、問題となる可能性があります。なぜなら、あるファイルではバイナリゼロのブロックが割り当てられたブロックとして表示される一方で、別のファイルには存在しない場合があるからです。ファイルは論理的には同一であっても、ブロック単位では同一ではない場合があります。実際、`copy_file` を使用すると、ターゲット内のバイナリゼロのブロックが削除されるため、そのようなブロックが存在する場合、ソースとターゲットがブロック単位で同一になることは保証されません。
これは、エクステントベースのストリームファイルにおいても問題となります。なぜなら、エクステント内のすべてのブロックは、たとえ内容がすべてバイナリ0であっても、常にインスタンス化されるからです。つまり、スパースなエクステントファイル内のブロックは、まったく同じデータを表しているにもかかわらず、同一の非エクステントファイル内のブロックとは異なって見える可能性があります。copy_fileを実行しても、エクステント内のゼロブロックを削除することはできません。
上記の -continue の使用例では、実際には2つの同一のファイルが使用されていますが、一方はDAE-256エクステントを持ち、もう一方はフレキシブルエクステントを持っている点が異なります。
つまり、内容「abc」のDAE-8ファイルには、「abc」を含む1つのブロックと、それに続く7つのバイナリ0のブロックが含まれます。非エクステントファイル（またはフレックスファイル）には「abc」を含むブロックが1つだけあり、DAE-16ファイルには「abc」を含むブロックと、それに続く15個のバイナリ0のブロックが含まれます。
compare_files コマンドを -compare_blocks オプション付きで使用すると、これらのファイルはすべて同じファイルデータを表しているにもかかわらず、すべて異なるものとして表示されます。リリース 18.0 では、このような状況に対応するために -compare_all_blocks オプションが利用可能です。これにより、copy_file は比較対象のファイル内で欠落しているブロックを論理的に補完し、疎なデータによる差異が排除された、真のブロック単位の比較が行われます。 stream64 ファイル内の欠落ブロックはすべてバイナリ 0 とみなされますが、fixed ファイル（またはその他のすべてのファイルタイプ）ではバイナリ -1（すべて FFFF）とみなされます。
ファイルの疎度が非常に高い場合、この方法では-compare_blocksオプションを使用する場合に比べて比較処理が大幅に遅くなる可能性がありますが、デフォルトのレコード単位の比較に比べれば依然としてかなり高速です。通常、これはエクステントが異なるファイルのブロックを比較する場合にのみ必要となりますが、前述のように疎度の違いが生じる他のケースもあります。また、エクステントが異なる固定長ファイルの比較にも有用です。