いろいろ教えていただいたのですが、要は『bs=1024k はでたらめに大きすぎる』ということらしいので、ブロックサイズを変更してDLTに書き込んだときにどのような挙動になるのか調べてみました。すべて /dev/zeroから作成したファイルを dd を使ってDLTに書き込んでいます。1回しか測定していないのでかなりの誤差があるとおもわれます。
| bs= | 時間(秒) | 速度(bytes/sec) |
|---|---|---|
| 無指定 | 59.91 | 175,039 |
| 512 | 57.23 | 183,205 |
| 1024 | 27.79 | 377,296 |
| 4096 | 4.61 | 2,275,323 |
| 8192 | 2.10 | 4,983,989 |
| 16384 | 1.05 | 9,978,171 |
体感速度どおり、bs=512に関しては『物凄く遅い』という結果になりました。数値はすべてddが表示した数字をそのまま拾ったのですが、bs=16384に至ってはまだテープは動いているのに一瞬で値が表示されてうさんくさいので、もっと大きいファイルサイズでの測定です
| bs= | 時間(秒) | 速度(bytes/sec) |
|---|---|---|
| 16384 | 15.19 | 6,904,525 |
| 32768 | 9.51 | 11,021,241 |
| 65536 | 8.97 | 11,689,345 |
| 128k | 8.97 | 11,695,131 |
| 512k | 8.96 | 11,701,278 |
| 1024k | 8.96 | 11,698,846 |
bs=16384 の値がアヤしいのですが、それ以外はほぼ横並びです(ちなみに、この作業中にはpanicしませんでした)。DLT7000のカタログスペックからすると非圧縮時6MB/s、圧縮時最大12MB/s ということですので、全部ゼロのデータにおいて11MB/s ぐらいというのはそこそこ正しい数値のようです。
これを踏まえて、ssh越しにリモートバックアップしてみました。bs=1024kが大きすぎる事ははっきりしていますが、小さすぎると時間がものすごくかかりますから、とりあえず無難なところで bs=64k と書いてみると
途中でpanic (^^;
う、だめか。ということで、100歩譲ってbs=32kとしてみると、数十ギガバイト分のバックアップを問題なく完了する事が出来ました(パチパチ)。
まぁGENERICカーネルならpanicしないのがちょっとアレなのですが、数値を小さくしてやれば問題はない(であろう)事がわかりました。どうもありがとうございます。