私が理解しているように、LTOテープは「ラップ」でデータを書き込みます。最初のラップはテープをドライブにスプール解除し、2番目のラップはテープをカートリッジにスプールします。このプロセスは何度も繰り返されます。テープの終わりに達すると、すべてのテープがカートリッジに戻り、巻き戻しをほとんど行わずに排出できるという考えです。
ただし、テープの最後に到達すると、ドライブは最終ラップの約半分のように聞こえるため、ドライブはテープを排出する前に巻き戻すのに時間がかかりますテープの終わりに達しました。
これは、テープに予約済みの容量があるためです。失敗したブロックを書き換えたり、合計容量を削減せずにテープの不良セクションをスキップしたりすることができますか？それとも、このテープの明らかに早い仕上げに他の理由がありますか？
回答:
ドライブが新しく、テープの品質が良い場合、公式の容量よりも多くのバイトをテープに書き込むことができると期待できます。ある意味では、その空き容量を呼び出すことができますが、使用されていません。
ドライブヘッドの摩耗に伴い、容量は減少します。それをそれほど品質の劣るテープと組み合わせると、容量がさらに減少する可能性があります。
容量はそのように変化するため、容量が不足していることをバックアップアプリケーションに通知する何らかの方法が必要です。バックアップアプリケーションがテープの最後に達し、準備されていない場合、問題が発生する可能性があります。残りのスペースを使用して何をしているのかをラップできるように、事前に警告を表示するアプリケーションの方が適しています。
OSがLinuxである場合、APIは、テープのこの最後の部分に到達writeすると他のすべてのシステムコールが失敗するようなものENOSPCです。バックアップアプリケーションがこの機能を認識していない場合、最初のアプリケーションがENOSPC最後として扱われ、テープに未使用のスペースが残ります。
他のOSでも同様のことが起こると想像できます。
@kasperdのおかげで、さらに調査を行いましたが、これが実際に問題でした。この機能はEWEOM（Early Warning End of Media）と呼ばれ、テープメーカーによってテープに付けられたマーカーを参照するため、スプールされたテープの量を追跡するドライブではありません。
mbufferテープへの書き込みに使用しているプログラムのパッチを作成しました。テープの終わりに達した時点で、呼び出しENOSPCを交互に行うwrite()とエラーが 発生しますが、さらにデータを書き込むことができます。私の場合、非常に多くのデータがあります。圧縮率が非常に低いデータの圧縮に応じて、8〜19 GiBです。
興味深いことに、EWEOMマーカーに到達した後、テープの書き込み速度は劇的に低下します。80MB /秒から約47MB /秒までほぼ半分になります。ドライブはこの時点より数時間前から80MB /秒を維持しているため、これはデータの問題ではないようです。ドライブモーターの速度が遅くなり、このセクションが書き換えられるようにテープ全体を書き換えても速度は上がりません（そのため、最初の書き込みが遅くなることはありません。新品のテープ。）
EWEOMマーカーがテープに表示されるタイミングに関するドキュメントが見つからないため、標準化されているかどうかはわかりません。私が見つけたのは、LTO-6 / 7ドライブへのあいまいな参照だけで、これはテープスペースの5％に増加しました。おそらくこれは、テープの書き込み速度が速いために大きなバッファをフラッシュできるようにするためです。
Linux APIに関する限り、関連する行はst.c SCSIテープドライバーのソースコードにあり、この動作の説明はstドライバーのドキュメントにあります。