私はLTO-7テープに複数のファイルを保持するためにtarを使用しています。通常、ファイルあたり約1〜2 GBで、各アーカイブには数百のファイルがあります（アーカイブあたり最大約1TB）。
現在、以下を使用して保管しています。
tar -cvf /dev/nst0 --totals --warning=no-file-changed $OLDEST_DIR
ディスク転送速度は約90MBpsで、ディスク転送速度はその速度の3倍です（テープ転送速度はその速度の2〜3倍でなければなりません）。詳しく見ると、tarは1つのCPUを100％消費するため、CPUにバインドされているようです。
これを最初に実行して、アーカイブのサイズが正しいことを確認したいので、特に迷惑です。
tar -cP --warning=no-file-changed $OLDEST_DIR | wc -c
...その後、結果のアーカイブのサイズを比較します。
それでは、より速い方法はありませんか？
答え1
x86-64 CPUのデータスループットは約64GB/sなので、これがあなたの問題ではないと思います。これはx86-64 Linuxですか、それとも別のものですか？最も可能性の高い問題は、各トランザクションがCPU操作を実行しているために使用するチャンクが小さすぎることです。努力する：
strace -fo /tmp/tar.rw.txt -eread,write tar -cvf /dev/nst0 --totals --warning=no-file-changed $OLDEST_DIR
tarがI / Oブロックで実行したいことを確認するには、結果の/tmp/tar.rw.txtファイルを見てください。おそらく10KBのブロックを読み書きすることがわかります。-bデフォルトは20のこのフラグを使用してこの問題を解決できます。ハードウェアはメガバイトのI / Oを処理でき、OSがそれを処理できない場合は再分割するため、-b $[1024*2*32]32 MBのトランザクションを試してみてください。
次に、オペレーティングシステムがトランザクションを介して何をしたいかを確認する必要があります。新しい値でtarを試して-b、インストールされていることを確認し、sysstat実行中にiostat -xm 4カウンタを確認して観察します。注意すべき主な事項は「avgrq-sz」列です。分割しない場合は、約64,000にする必要があります。分割が発生すると、オペレーティングシステムは、1つのトランザクションで多くのバイトを読み書きできないと思います。これはそれ自体のトピックですが、ドライブにラベルを付けることで制限をすばやく増やすことができます（nst0がそこにあるべきだと思います）。
cd /sys/block/nst0/queue
cat max_hw_sectors_kb > max_sectors_kb`
読み取っているディスクのすべてのレイヤー（lvmおよびdmレイヤーを含む）と同じです。それ批判的最低レベル（sda）で最初にmax_sectors_kbを増やし、最上位（たとえばdm23）レベルで最後に増やします。再帰的に確認してください/sys/block/<dm>/holders/*/holders/*/....。
今、これらの新しい設定では、両方に注意を払う必要があります。 1つは、元のファイルをmd5sumし、テープでtarとuntarを実行してからmd5sumをチェックして、ファイルがまだ正しく記録されていることを確認することです。 -bこのような問題は発生してはいけませんが、テープハードウェアなどはテストしていません。 2つ目は、より大きなトランザクションサイズが原因でRAMが不足しないようにすることです。ディスクトランザクション中にsysctl vm.min_free_kbytesが不足すると、非常に悪いことが発生する可能性があるため、sysctl vm.min_free_kbytesが十分に大きいことを確認したい場合があります。