VOSのストリームファイルは2GB程度までの成長に制限があります。これは、s$seq_position、s$get_port_status、s$lock_regionなどのインターフェースの定義では、ファイル内の位置を示すために符号付き32ビット変数を使用しており、2**31は表現可能な最大の値であるからです。ストリームファイルでは、他のVOSファイル組織のように、位置はレコード番号ではなくバイトオフセットになります。
64ビットストリームファイルはリリース17.2で利用可能で、VOSファイルシステムによってのみ制限された成長を可能にします（どのファイルも最大サイズは512GBです）。成長の可能性を広げることに加えて、これらのファイルは、特にバイナリデータにアクセスする場合に、他の利点を提供します。通常のストリームファイルとは異なり、すべてのバイナリゼロを含むブロックはディスク上のスペースを占有せず、そのようなデータを読むことはディスクアクセスを必要としません。
17.2+モジュール上で動作するディスク上に作成された新しいファイルは64ビット(ストリーム64と呼ばれることが多い)ファイルになり、17.2以前のモジュール上では通常のストリームファイルになります。VOSのs$インターフェースやVOS言語I/Oを使用するアプリケーションはネイティブアプリケーションと呼ばれ、ストリームファイルを使用するアプリケーションは、バイト位置決め操作を使用しない（BOFやEOFへの位置決めはバイト位置決めとは見なされません）か、またはファイルのサイズを変更しない限り、ストリーム64ファイルにアクセスすることができます。 ただし、ストリーム64ファイルを作成するためには、それらを変更する必要があります。
ここでは、64ビットストリームファイルの利用を計画している場合/計画している場合に役立つ情報をいくつか紹介します。以下のように構成されています。
既存のアプリケーションと互換性
- 既存のPosixアプリケーション
- 既存のネイティブアプリケーション
- 互換性
- オープンソース製品
疎な割り当て
ファイル変換
物理的特性
- エクステント
- エクステントが疎な割り当てに与える影響
- 柔軟な拡張
ツール
- モジュール上の64ビットストリームファイルを探す
- ブロックの比較
- 疎なファイルの比較
既存のアプリケーションと互換性
- 既存のPosixアプリケーション
リリース17.2以降では、ターゲットが17.2以降で動作するディスク上にある場合、64ビットファイルにアクセスしてファイルを作成できるように、ラージファイルを認識するためにPosixアプリケーションを構築することができます。アプリケーションがPosixに準拠している場合（例えば、必要に応じてintの代わりにoff_tのような型を使用するようにコード化されている場合）、ソースの変更は必要ありません。作成されるファイルが17.2以前のモジュール上のディスク上にある場合は、通常のストリームファイルが作成され、ファイルを2GB以上大きくしようとした場合にのみ失敗が発生し、すべてが正常に動作します。したがって、Posixアプリケーションが大きなファイルを使用できるようにすることは、相互運用性の点では何のコストもかかりません。VOSがサポートするほとんどのオープンソース製品は、リリース17.2の時点で、64ビットストリームファイルを生成し、適切に扱うことができます。
17.2+モジュール上で動作するディスク上に作成された新しいファイルは64ビットストリーム(ストリーム64と呼ばれることが多い)ファイルになり、17.2以前のモジュール上では通常のストリームファイルになります。VOSのs$インターフェースやVOS言語I/Oを使用するアプリケーションはネイティブアプリケーションと呼ばれ、ストリームファイルを使用するアプリケーションは、バイト位置決め操作を使用しない(BOFやEOFへの位置決めはバイト位置決めとは見なされません)か、ファイルが2GBより小さい場合に限り、ストリーム64ファイルにアクセスすることができます。
- 既存のネイティブアプリケーション
多くのネイティブ・アプリケーションは、組織がSTREAMではなくSTREAM64であることを示すためにcreate_fileコマンド(またはs$create_file)の使用を変更する必要があります。アプリケーションが位置決め操作を使用して、ファイルが2GBを超えて大きくなった場合、s$seq_positionはエラーを出します: より大きなファイルをサポートするために、s$seq_positionの呼び出しをs$seq_position_xに変更する必要があります。繰り返しになりますが、_xインターフェースを使用することは、位置引数がサポートされている範囲内であれば、_xインターフェースをサポートしていないモジュール上に存在する通常のストリームファイルを参照するアプリケーションの能力を妨げることはありません。したがって、この変更を行うことで、どのようなタイプのストリームファイルにもアクセスできるようになり、相互運用性の面では何のコストもかかりません。
s$seq_read, s$seq_write, s$seq_position BOF/EOF のバイト位置を通信しないインタフェースのみを使用する既存のアプリケーションは、変更なしで 64 ビットのストリームファイルを扱うことができます。多くのアプリケーションは、シーケンシャルであろうとストリームであろうとASCIIファイルを扱うように書かれているので、サイズに関係なく64ビットのストリームファイルを扱うための変更は必要ありません。
64 ビットのストリームファイルはインデックスを持つことができないため、インデックス付きストリームファイルを stream64 に変換することはできません。インデックス付きストリームファイルは、既存のインデックス実装の制限により、2 GB を超えるサイズに成長することはできません。
- 互換性
64ビットストリームファイルには多くの利点があるため、インデックスが必要ない場合は可能な限り採用すべきです。
ファイルが2GBを超えて大きくならない限り、古いバージョンのVOSを実行しているモジュールにコピーしたり、移動したりすることができ、通常のストリームファイルとしてそこに表示されます。ファイルが「制限」されていないことを条件に、stream64 ファイルを含むディスクを古い VOS に移動することもできます。そのようなファイルを含むディスクを 17.2 以前の VOS に移動した場合、そのようなファイルは開くことができません (そのような移動を計画している場合は、制限されたファイルを識別するためのツールが利用可能です)。しかし、古いバージョンの VOS を実行しているアプリケーションは、ネットワーク上であらゆる種類の stream64 ファイルを開いたり、読み込んだり、書き込んだりすることができます。
- オープンソース製品
VOSでサポートされているほとんどのオープンソフトウェアは、FTP、sftp、sambaなどのように、大きなファイルを認識するように変換されています。これには一定の意味合いがあります。リリース 17.2 では、ストリームファイルを VOS に ftp することができるようになりましたが、FTP デーモンが stream64 ファイルを作成するので、ファイルが大きすぎることを気にする必要はありません。転送されたファイルを単にコピーするだけで、そのファイルが占有するディスク容量を大幅に減らすことができます。もし、ftp で転送されたファイルにインデックスを追加するつもりなら、まず普通のストリームファイルに変換しなければなりません（もちろん、長さが 2 GB を超えてはいけません）。
疎な割り当て
すべてのバイナリ 0 を含むブロックは必ずしも stream64 ファイルに割り当てられているわけではないので、ディスク容量を必要としません。gnu の "truncate" コマンド (>system>gnu_library>bin にあります) は、ストリームファイルのサイズを切り詰めることと拡張することの両方に使用できます。18.0では、VOSはreset_eofという同様のコマンドを提供しています。EOFを過ぎたデータは未定義ですが、EOFが拡張されると、現在のEOFの時点からのファイル内容は常にバイナリゼロに設定されます。
通常のストリームファイルとストリーム64ファイルを考えてみましょう。
create_file stm -組織化ストリーム
create_file s64 -organization stream64
とし、それぞれが 'abc' というコンテンツを持つと仮定します。それぞれが20億バイトを占めるようにファイルを拡張したいと思います。
バッシュ
bash-4.2$ truncate -s 2000000000 s64
bash-4.2$ truncate -s 2000000000 stm
最初のリクエストはすぐに終了しますが、2回目は数分かかります。ファイルは論理的な同等性を示しています。
bash-4.2$ ls -l
合計 244382
-rwxrwxrwxrwx 1 nobody nobody 2000000000 2月25日 14:08 s64
-rwxrwxrwxrwx 1 nobody nobody 2000000000 2月25日 14:11 stm
しかし、各ファイルが占有するディスクブロックの数は、VOSのリストコマンドで示されるように、かなり異なっています。
羅列
ファイル数: 22, ブロック488764
Ｗ４Ｓ６４
Ｗ４８８７６０ ＳＴＭ
リリース18.0では、VOSのreset_eofコマンドを使用して同等の操作を行うことができます。
reset_eof s64 2000000000
VOS コマンドは、通常のストリームファイルを数千ブロック以上拡張しようとすると警告します。
reset_eof STM 2000000000
eof を 2000000000 に拡張すると、ファイルに 488281 ブロックが追加されます。stmを1999999996バイト拡張しますか？(はい、いいえ)
これが拡張後の64ビットストリームファイルです。2つのデータブロックだけで構成されています。
ダンプファイルＳ６４
ブロック番号1
000 6162630A 00000000 00000000 00000000 00000000 |abc.........
=
FF0 00000000 00000000 00000000 00000000 00000000
ブロック番号 488282
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 00000000
通常のストリームファイル stm をダンプすると、ほとんどのブロックにバイナリゼロが含まれている、割り当てられた 488282 ブロックがすべて表示されます。
ダンプファイルＳＴＭ
ブロック番号1
000 6162630A 00000000 00000000 00000000 00000000 |abc.........
=
FF0 00000000 00000000 00000000 00000000 00000000
ブロック番号2
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 00000000
ブロック番号3
…
ブロック番号 488282
000 00000000 00000000 00000000 00000000 |…………….|
=
400 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |..........................
=
FF0 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |............................
それにもかかわらず、compare_files と diff はファイルを等価とみなしますが、通常のストリームファイルのすべてのブロックを読み込む必要があり、この場合は数分かかることになります。
ready;compare_files s64 stm
準備完了 14:29:47
準備完了 14:31:24 45.877 46
ファイル変換
convert_stream_file コマンドは、シーケンシャルファイルとストリームファイルタイプのいずれか (ストリーム、64 ビットストリーム、シーケンシャル、拡張シーケンシャル) の間で変換したり、エクステントを変更したりするために使用できます。通常、変換はファイルの内容をコピーすることを含み、この方法では空のターゲットファイルを作成し、-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 ファイルを通常のストリームファイルに変換すると、すべてのブロックがインスタンス化されるため、結果として得られるファイルは元のファイルよりもかなり大きくなる可能性があります。
stream64 ファイルでは、たまたまバイナリのゼロを含むブロックがディスク上に確保されるかどうかは保証されていません。例えば、あるブロックにいくつかのゼロを書き込んだ後にすべてゼロになってしまった場合、そのブロックは確保されたままになってしまいます。書き込まれないブロックだけが未割り当てのままになります。
物理的特性
- エクステント
VOS ファイルの実際の成長限界は、そのエクステントのサイズによって決定されますので、エクステントが何であるかを理解することが重要です。VOS ファイルマップには、ファイル内の各 4k ブロックのディスクアドレスが含まれており、523792 エントリに制限されているため、エクステントのないファイルは 2145452032 (523792 * 4096) バイトに制限されています。これは 2**31 未満であり、これが通常のストリームファイルの成長の実際の限界です。
エクステントとは、ディスク上の連続する N 個のブロックのグループで、N はエクステントのサイズです。エクステントを介して割り当てられたファイルのファイルマップには、エクステント内の最初のブロックのアドレスが含まれているため、ファイルマップはかなり大きなファイルを表すことができます。動的に割り当てられたエクステントでは、エクステントサイズが 256 まで許容され、512 GB のファイルを含むことができます (注意: 256 より大きいエクステントサイズを許容する静的に割り当てられたエクステントは、ページングファイルでの使用を除いて非推奨とされています。)
2 GB を超えて成長するためには、 stream64 ファイルは extents を持つ必要があり、その値が実際の成長限界を決定します。例えば、以下のようになります。
create_file stm64 -organization steam64 -extent_size 32
は64GBまで成長できるファイルを作成します。
リリース17.2では、Posixランタイムによって作成されたファイルのデフォルトのエクステントサイズは8で、最大16GBまでの拡張が可能です。このようなファイルは一度に8ブロック成長するため、どのファイルの最小サイズも8ブロックになります。このデフォルト値は、システム管理者がモジュールごとに変更することができますが、成長の可能性が大きいほど、ファイルの最小サイズは大きくなります。拡張子を大きくすることは、非常に小さなファイルを多く生成するアプリケーションにとって問題になることがあります。
- エクステントが疎な割り当てに与える影響
通常、書き込まれないブロックは Stream64 ファイルには割り当てられません。しかし、あるエクステント内の 1 つのブロックが書き込まれた場合は、そのエクステント内のすべてのブロックが割り当てられます。
文字列 abc (stm1) を含む非エクステントファイルが、エクステントサイズ 8 (stm8) のファイルに変換されたとします。
ダンプファイルＳＴＭ１
ブロック番号1
000 6162630A 00000000 00000000 00000000 00000000 00000000 |abc...........................
010 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 00000000
convert_stream_file stm1 stm8 -extent_size 8
ダンプファイルＳＴＭ８
ブロック番号1
000 6162630A 00000000 00000000 00000000 00000000 00000000 |abc...........................
010 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 00000000
ブロック番号2
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 00000000
ブロック番号3
…
ブロック番号8
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 00000000
briefオプションはリリース18.0でdump_fileに追加され、物理的に存在するブロックを見たくないが、"空の"ブロック（存在しない可能性のある）を表しているブロックを見たい場合に便利です。このオプションをDAE-8ファイルで使用すると、以下のようになります。
dump_file stm8 -brief
ブロック番号1
000 6162630A 00000000 00000000 00000000 00000000 |abc...........................
010 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 00000000
これは、固定ファイルの相対パスの-1′をすべて含む"空の"ブロックを隠すのにも有効です。
- 柔軟な拡張
柔軟なエクステントが Release 18.0 で導入され、小さなファイルを一度に 1 ブロックずつ成長させることができるようになりました。これは、リリース18.0でPosixアプリケーションによって作成されたすべてのファイルのデフォルトであり、特定のエクステントサイズを指定しない場合は、create_fileコマンドで取得されます。
create_file flex -organization stream64 -extent_size
柔軟なエクステントを持つファイルをフレックスファイルと呼び、柔軟なエクステントを持つことができるのは stream64 ファイルのみです。stream64 ファイルだけが柔軟なエクステントを持つことができます。
ディスプレイファイルステータスフレックス
名前: %swsle#Raid4>フレックス
ファイル構成：ストリームファイル（64ビット
最終更新日時：15-02-25 12:0015-02-25 12:06:25 EST
…
動的エクステント: はい
エクステントサイズ: フレックス
display_file_status コマンドを 18.0 以前のモジュールで実行すると、以下のように表示されます。
エクステントサイズ: -1
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
フレックスファイルは、512 GB、具体的には540,142,534,656バイト対549,235,720,192をDAE-256で保持することができますが、小さなファイルが一度に1つのブロックを成長させるという利点があります、その後、8、32、256は、常に256ブロックとは対照的に、一度に。
フレックスファイルを含むディスクを 18.0 以前のモジュールにマウントしてはいけません。誤ってマウントしてしまうと、ファイルは表示されず、アクセスできなくなります。そのようなファイルやそれを含むディレクトリは削除できないので、ディスクを 18.0+ を実行しているモジュールに戻してもそのまま残ります。しかし、18.0 以前のモジュールでサルベージした場合、すべてのフレックスファイルが削除され、スペースが回復します。
ツール
- モジュール上の64ビットストリームファイルを探す
ディスクを古いバージョンの VOS に移動する必要がある場合、古いリリースと互換性のないファイルを探す必要があります。これを支援するコマンドがあります。
locate_stream_files -form
---------- locate_stream_files ---------.
ディレクトリ名を指定します。
-depth.
タイプ: -type.64ビット
-ブリーフ：なし
-ロング：なし
-type には flex、sparse、large (特定の特性を持つ 64 ビットストリームファイルを検索します)、all (すべてのストリームファイルを検索します) を指定することもできます。
深さに応じて、下位のディレクトリが検索され、ファイルが属性のいずれか(タイプで指定されていない)を持っている場合は、その属性とエクステントサイズに関する情報も表示されます。ディレクトリ名が指定されない場合、モジュール上のすべてのディスクがルートから検索されます。例えば、以下のようになります。
locate_stream_files -type 64 ビット
ディスク %swsle#raid0-1... のディレクトリをチェックしています。
swsle#raid0-1。
smb_test.stm64 (FLEX/大型)
smb_test.stmb
64ビットストリームファイル2個の合計。
ディスク %swsle#raid0-2 のディレクトリをチェック中...
swsle#raid0-2。
big_stream (FLEX)
smb_test.stm (FLEX)
smb_test.stm64a (FLEX/大型)
64ビットストリームファイルの合計3つ。
ディスク %swsle#Raid4... のディレクトリをチェックしています。
swsle#Raid4>otto.
b3 (DAE-8)
おおきい(DAE-256/ラージ/スパース)
…
- ブロックの比較
リリース17.2と18.0では、ストリームファイルに便利なcompare_filesコマンドの新しいオプションが利用可能になりました。VOS構造化ファイルタイプのブロックごとの比較は、異なる値を持つ2つのブロックが同じ論理レコードを表すことが多いため、一般的には有用ではありません。例えば、相対ファイルのレコードの現在の長さを過ぎた未使用のデータは予測できません。さらに、シーケンシャルファイルには未定義のフィラーバイトが含まれています。拡張シーケンシャルファイルのブロック内容は、同じ論理レコードを表現しているにもかかわらず、レコードサイズが異なると全く異なります。
しかし、ブロック比較は固定ファイルやストリームファイルの場合に便利なことがあります。問題は compare_files がレコード指向であり、エディタを使って位置を特定できるレコード番号 (または行番号) で差分を表示するように設計されていることです。これは、レコード単位で整理されていないバイナリストリームファイルで問題が発生しています。任意のファイルのレコードサイズは32767バイトに制限されているため、ストリームファイルでs$seq_readを使用すると、NLレコードデリミタが介在しない32kバイト以上のシーケンスが発生した場合、次のバイトがNLであるかどうかを区別せず、次の32767文字を配信してしまいます。このため、NL 文字で区切られた文字列ではなくバイナリ値を保持しているストリームファイルでは、レコード指向比較の結果が曖昧になります。
この問題はリリース17.2で対処されています。 compare_filesでは、以前に誤った成功が発生した可能性がある場合、特に、NLに続く32767文字がNLに続かない32767文字と一致した場合に検出するようになりました。これが発生した場合、ストリームファイルに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 を使用すると、ターゲットにバイナリゼロのブロックが存在する場合、ソースとターゲットがブロック対ブロックで同一にならないことが保証されます。
これは、エクステント・ベースのストリーム・ファイルでも問題となります。エクステント内のすべてのブロックは、たとえすべてのバイナリ・ゼロを含んでいても、常にインスタンス化されるからです。つまり、疎なエクステント・ファイル内のブロックは、全く同じデータを表しているにもかかわらず、同一の非エクステント・ファイル内のブロックとは異なって見える可能性があるということです。copy_file を実行しても、エクステント内のゼロ・ブロックを除去することはできません。
上記の -continue の使用を示す例では、1つは DAE-256 エクステントを持ち、もう1つはフレキシブルエクステントを持つことを除いて、実際には2つの同一のファイルが含まれています。
そのため、コンテンツ"abc"を持つ DAE-8 ファイルは、"abc"を持つ 1 つのブロックの後に、バイナリゼロを含む 7 つのブロックが続きます。非エクステントファイル(またはフレックスファイル)は"abc"を持つブロックが1つだけで、DAE-16ファイルは"abc"ブロックの後に15ブロックのバイナリゼロが続きます。
compare_files コマンドに -compare_blocks を指定して使用すると、これらのファイルはすべて同じファイルデータを表しているにもかかわらず、異なるファイルとして表示されます。リリース 18.0 では、このような状況に対応するために -compare_all_blocks オプションが使用可能になりました。これにより、copy_file は比較対象のファイル内の欠落したブロックを論理的にインスタンス化し、結果として、スパースネスによる差異が除去された真のブロックごとの比較が行われます。stream64 ファイル内の欠落ブロックはすべてのバイナリ 0 とみなされ、固定ファイル (あるいは他のすべてのファイルタイプ) ではバイナリ -1′s (すべて FFFF) とみなされます。
非常に疎なファイルでは、-compare_blocks オプションを使用するよりも比較が遅くなりますが、それでもデフォルトのレコード指向比較を使用するよりはかなり速くなります。これは通常、異なるエクステントを持つファイルのブロックを比較する場合にのみ必要ですが、前述のように疎さが異なる場合もあります。これは、異なるエクステントを持つ固定ファイルを比較する場合にも有用です。