LTO-7テープのtarアーカイブからローカルにマウントされたネットワーク共有にファイルを復元しています。共有に直接復元すると、実行速度が非常に遅くなります（90 MB / s）。追加のバッファを使用するときに得られる最大スループットは280 MB / sです。ただし、パイプが破損したという警告が表示されます。
mbuffer -s 1M -m 2G -i /dev/st0 | tar -xf -
mbuffer: warning: error during output to <stdout>: Broken pipe
tarアーカイブは、もともとブロック引数2048（1MBのブロックサイズなど）を使用して作成されました。
私はこれがすべてのデータが受信される前にtarが終了したことを意味すると思います（おそらくバッファが一時的に空であり、tarはデータが終わったと思いましたか？）。
この問題をどのように解決できますか？つまり、tarがバッファからすべてのデータが受信されるのを待つことをどのように保証できますか？
もともとバッファリングが必要なのはなぜですか？接続は10Gで、ターゲットディスクは非常に高速なRAIDです。景気減速の根本原因は何ですか？
2020年2月7日修正
tarコマンドにブロック要素を追加しましたが、警告は表示されませんでした。
mbuffer -s 1M -m 2G -i /dev/st0 | tar -x -b 2048 -f -
しかし、指定されていない場合、パイプ破損警告が表示される理由はまだ疑問です。
ベストアンサー1
エラーメッセージが表示される理由は簡単です。使用中のtar実装が呼び出される前にすべてのデータを読み取るわけではありませんexit()。
これは、実際のテープブロックサイズを知らなかったために発生します（自分が見つけたように）。
一般的なテープ（QICテープを除く）はブロックされ、より高いパフォーマンスを得るためにはより大きなブロックサイズを使用することをお勧めします。 126kBを超えるブロックサイズを他のブロックと交換することはお勧めできませんが、バックアップの場合は1MBをブロックサイズとして使用することをお勧めします。
TAR他方も、デフォルトのブロックサイズが10kBのワークブロック指向として指定されています。
EOFアーカイブの定義は、TAR最後のファイルの直後にある2つのゼロの512ブロックです（ここではtar新しいヘッダーが必要です）。
EOF 表示後にアーカイブ処理が停止し、テープデータの最後の 10kB から 0 に指定された 2 つのブロックが発生しない限り、未読入力があるため、破損したパイプメッセージが表示されます。
を使用する場合、 starFIFOは内部tarなので、テープ読み取りコードそして、tarアーカイブ処理は常にテープブロックサイズについて同じ考えを持っています。より高速に加えて、starすべての入力データがtar archive。
注：最適なストリーミングに推奨されるFIFOバッファサイズは、最大テープレートで10〜30秒のデータを保持できます。より大きな FIFO をサポートするように完全に拡張されるまで、以下をstar呼び出すことをお勧めします。
star fs=2000m ...
注：これは30年以降のデフォルトです-fifo。starまた、-shmこの機能に使用できるメモリ量が制限されているため、Linuxでは同様のオプションを使用しないことをお勧めします。
star確かに他のどの実装よりも高速ですtar。ただしCOW、同様のファイルシステムを使用している場合、またはオペレーティングシステムZFSのカーネルバッファリングの実装が遅い場合は、抽出モードで呼び出しを無効にして速度を上げることをお勧めしますfsync()。ファイルがバックアップストアに安全であるかどうかを知る方法がないため、他の実装よりも「信頼できません」。ただし、-no-fsyncこれにより、バッファリングが悪いレガシーファイルシステムでの抽出速度が4倍になります。ただし、不良バッファリングは実装されておらず、高コストで特定のファイルシステム状態を付与する機能のみが実装されています。startarZFSZFS