ddコマンドの実行時間について試したことを記しておく。
最初にマシンのスペックがどの程度影響するかわからないが
確認しておく。
本稼働機
CPU Intel(R) Core(TM) i3 M 350 @ 2.27GHz
memory 4GB
USB 2.0
実験機
CPU Intel(R) Core(TM) i5-2540M @ 2.60GHz
memory 8GB(4GB×2)
USB 3.0
内蔵HDDはどちらも500GB
いろいろ調べれば速度を測るスマートな方法があるだろうが
現状、自分が納得できる範囲で
dfコマンドでUSB接続のHDDの使用容量を確認し、時間経過から
おおよその見当をつけた。
最初に行った実験機では、そのことに思いがいたらずひちすら待つまみであった。
また、処理終了後の表示も気に留めなかった。エラーがないこと安心しただけで
速度について大切なメッセージが出ていたとは知らなかった。
前回報告の通り、バックアップに半日以上、リストアも最低6時間はかかった
と思われる。(正確な記憶ではないが)
さて、スペック的には劣る本稼働機で実験機で最初に行ったのと同じHDDで
試してみると、異常に遅い。概略計算とはいえ、丸2日もかかる。
これでは試す価値がないので、処理を中断。
遅い原因は何なのか、実行中のHDDのアクセスランプを見ていて気付いた。
常時連続的に動作している様子がない。時々しかアクセスランプが点滅しない。
内部的な処理をしている時間があると思われる。
理由はおそらくHDDのファイルシステムにあるのだろうと推測した。
HDDは一般的な家電量販店で購入したもので、NTFSでフォーマットされいる。
UbuntuServerはext4なので、最適化とか変換とかしながら書き込んでいるのだろう。
従って時間がかかる。であるならば、HDDをext4のファイルシステムにしてみたら
どうなるかを実際に試してみた。
予想通り、アクセスランプは連続的に点滅し、dfコマンドと経過時間から
本稼働機では5時間と予想され、実際にその通り処理は終了した。
-----------------------------
976773168+0 レコード入力
976773168+0 レコード出力
500107862016 bytes (500 GB, 466 GiB) copied, 17816.7 s, 28.1 MB/s
-------------------------------------------------------------------------------
実験機についても再度行ったところ、予測は2時間ほど。これもその通り終了した。
-----------------------------
976773168+0 レコード入力
976773168+0 レコード出力
500107862016 bytes (500 GB, 466 GiB) copied, 7688.49 s, 65.0 MB/s
-------------------------------------------------------------------------------
時間の差は、マシンのスペックなのか、USBの規格なのか、総合的な結果なのか。
一番の要因が何なのかはわからない。
いずれにしても、実験機のスペック(全体として)で2時間弱という値はddコマンド
の結果としては評価してもよいのではなかろうか。と勝手に思い込む。
ddコマンドについては、これで終了とする。
日々変化するデータをどうバックアップするか、迅速な復旧のために何が必要か
改めて検討してみたい。今回の経験を通して少し、linuxのファイルシステムに
ついて理解が深まった。
それを生かし、難関とは思われるがdumpとrestoreについて
検討してみようと思う。
ただ、Ubuntuには標準でdumpコマンドがインストールされていないのでリストアの際に
desktop版のliveセッションは使えないと思われる。
別の環境を用意する必要がありそうだ。
