COMPAQの新自宅サーバはハードウェアの準備が済み設置場所も確保したので、現在『まともに動くか』という最終検証に入っているのですが・・・ひとつ問題が。

これまで特に問題らしい問題は発生していなかったのですが、昨日旧サーバのバックアップをDLTに取ろうと

% dump -0uf - / | ssh -c blowfish 新サーバ "dd of=/どっか/あいてるとこ/hoge.dmp ;dd if=/どっか/あいてるとこ/hoge.dmp of=/dev/nsa0 bs=1024k"

を実行してみると、テープに書くときにpanicでリブートしちゃうんですね・・・(T_T)。で、試しにGENERICカーネルで同じ事をするとちゃんと動くのです。

新サーバ ぴんち(笑)

てなことを書いていると、『dd で bs パラメータを 1024k と指定した場合、 DMA バッファが 1M バイト必要』と教えていただきました。う～ん、物理的なSCSIブロックサイズはddからの指定とは関係ないのかと思っていましたが、数値がおっきすぎるのかもしれません。ちなみに、1024kと書いているのは特別に特別な意味は無く デフォルトのbs=512だとテープに書くときに『うぃん、うぃん、うぃん』と小刻みに止まってとても遅いのです。bs=1024kだと『うぃ～～～～～～ん』と動いてくれるので割と短時間で終わります。←根本的に使い方が間違っているようですね(^^;)

いろいろ教えていただいたのですが、要は『bs=1024k はでたらめに大きすぎる』ということらしいので、ブロックサイズを変更してDLTに書き込んだときにどのような挙動になるのか調べてみました。すべて /dev/zeroから作成したファイルを dd を使ってDLTに書き込んでいます。1回しか測定していないのでかなりの誤差があるとおもわれます。

体感速度どおり、bs=512に関しては『物凄く遅い』という結果になりました。数値はすべてddが表示した数字をそのまま拾ったのですが、bs=16384に至ってはまだテープは動いているのに一瞬で値が表示されてうさんくさいので、もっと大きいファイルサイズでの測定です

bs=16384 の値がアヤしいのですが、それ以外はほぼ横並びです(ちなみに、この作業中にはpanicしませんでした)。DLT7000のカタログスペックからすると非圧縮時6MB/s、圧縮時最大12MB/s ということですので、全部ゼロのデータにおいて11MB/s ぐらいというのはそこそこ正しい数値のようです。

これを踏まえて、ssh越しにリモートバックアップしてみました。bs=1024kが大きすぎる事ははっきりしていますが、小さすぎると時間がものすごくかかりますから、とりあえず無難なところで bs=64k と書いてみると

途中でpanic (^^;

う、だめか。ということで、100歩譲ってbs=32kとしてみると、数十ギガバイト分のバックアップを問題なく完了する事が出来ました(パチパチ)。

まぁGENERICカーネルならpanicしないのがちょっとアレなのですが、数値を小さくしてやれば問題はない(であろう)事がわかりました。どうもありがとうございます。