以前 Ubuntu に乗り換え宣言したのだが、マイナーなパッケージが無かったり、古いままだったり(まぁコミュニティーベースだから仕方ない)で、Debian lenny に再度乗り換えた。
一番の難点は、、、言わないのが約束だなぁ。
Debian lenny だと kvm-72 がパッケージングされているので、サクサクインストールして使えるのだが、どうも２個以上のゲストOSを立ち上げると何故だか次のメッセージをだしてゲストOSがフリーズしてしまう。
BUG: soft lockup - CPU#0 stuck for 4096s!
なんすかねぇ？
症状としては、下記のバグ報告と同じっぽい。
で、kvm-84 だと直ってるらしい。。。ぐふぅ。取り敢えずは、適当に sid からkvm/libvirtのソースパッケージを取ってきてビルドして諸々更新したら、複数のゲストOSがフリーズせずに安定した、、、気がする。
またもや debian squeeze 待ちかなぁ
掃除をしたら多量にPATAのHDDも出てきた。
今まで簡単に特殊なドライバでサクサク開封して磁性体に多量の傷を付けて不燃ゴミにしていた。 個人で使っていたもので重要な機密とかが入ってる訳ではないが、少々心もとない。
shred を使って２回の乱数埋めと１回のゼロクリアでHDDの内容を全消去するのが、簡便で良い方法らしい。
# shred -n 3 -z -v /dev/hdb
だが、本当に遅い！
Debian/lenny のバージョンの GNU shred どうも必要な乱数全部を /dev/urandom から読み込むため、乱数生成の帯域で制限されてるっぽい。
『shredのあれこれ』 によれば、coreutils-5 では利用する乱数は内部で生成しており、coreutils-6 から /dev/urandom から利用する形になり、６倍遅くなったよという。。。つまり別の乱数発生器の openssl rand を使えと。
で、使ってみたが、、、途中で終ってしまいます。。。
なんでやぁ！！
暫し、熟考の結果 openssl rand の引数は int32_t だったらしく、100Gとかの HDD の消去とかには使えないですなぁ。。。。次のようにすれば完遂できますなぁ
# mkfifo rnd # while true ; do openssl rand $((2**31-1)) ; done > rnd & # shred --random-source=rnd -n 3 -z -v /dev/hdb
大体、上の方法で 300G で 10時間くらい？
ここまではバットノウハウの話。
coreutils の git レポジトリをつらつら流し見たところ。
要するに、shred を何も考えずに使った奴が勝者！
それよりも、320G HDD が８台もある敗北者の僕は 100MB/secくらいでるハードウェア乱数生成ボードが欲しい。。。
最近、HDDを整理してたら 320G SATA HDD (Seagate製) が 8台も出てきた。
うちで使っている ReadyNAS Duoには ２台の750G SATA HDD を載せているが、ボリュームの使用率が10%未満なので宝の持ち腐れな気がするので、ちょっと入れ替えてみた。
ReadyNAS Duoで実装されているX-RAIDは、HDDの容量を大きくする方向の変更は出来ても、小さくする変更は出来ない。まぁしょうがないので、大人しく別途バックアップを取って入れ替えた。
使っていた 750G HDDがフリーになったので、もの試しに読めるかどうか調べてみた。
普通のPCに繋いでみると、 一台のみにIBM PCベースのパーティションテーブルらしきある。
どうも先頭の２セクタを除いてミラーリングされているっぽく、２台中１台のみにパーティションテーブルが書かれているようだ。まぁ、同じ内容のディスクが変に認識されて混乱するのを避ける為なんだろうなぁ。
パーティションの最後が LVM のボリュームになっており、論理ボリューム上にデータ領域が確保されている。
# sfdisk -l -uS /dev/sdd
Disk /dev/sdd: 91201 cylinders, 255 heads, 63 sectors/track
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
Units = sectors of 512 bytes, counting from 0
Device Boot Start End #sectors Id System
/dev/sdd1 2 4096001 4096000 83 Linux
/dev/sdd2 4096002 4608001 512000 82 Linux swap / Solaris
/dev/sdd3 4608002 1465112305 1460504304 5 Extended
/dev/sdd4 0 - 0 0 Empty
/dev/sdd5 4608003 1465112305 1460504303 8e Linux LVM
個々のパーティションは、シリンダ境界で区切られておらず、パーティションが無いもう一台に再現するのは、先頭２セクタをコピーするか、sfdisk を駆使するか、ちぃと面倒。
X-RAIDで容量の拡張とかしていなければ、dmsetup を使うのも良いかも。
# lvmsize=$((`blockdev --getsz /dev/sdd` - 4608003))
# echo 0 $lvmsize linear /dev/sdd 4608003 | dmsetup create readynas-pv
# pvscan
# lvchange -ay -pr c/c
# lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
c c -ri-a- 696.41G
LVMの論理ボリュームがアクセスできるようになったら、何にも考えずに ext2/ext3 でマウントをしてみると上手く行かない。
# mount -t ext3 -oro /dev/c/c /mnt
mount: wrong fs type, bad option, bad superblock on /dev/mapper/c-c,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
# dmesg | tail -1
[ 3446.561022] EXT3-fs: bad blocksize 16384.
man を見ると、ブロックサイズは1024,2048,4096の３種類しか有効でないが、いつの時点で実装されたか分からないが、ext2/ext3のブロックサイズはCPUアーキテクチャのページサイズまで拡張されている。ReadyNAS で使われていたext2/ext3 ファイルシステムはブロックサイズが 16K なので、普通にはマウントできなかったようである。
ext2/ext3でブロックサイズが大きすぎる場合、読むだけなら２通りの方法がありそうである。
まぁ何も考えずに dump/restore を使えば、ブロックサイズを気にせずにファイルシステム全体をコピーできるので、ファイルを取り出すことが出来る。容量が大きいHDDが用意できるのならば、安定したアクセスが出来る。
# dump 0f - /dev/c/c | ( cd /backup ; restore rf - )
fuse 様にお伺いすると、ext2/ext3 にアクセスできる奴がある。。。コイツもブロックサイズの制限を気にせずにアクセスできる。ただ、、、まぁ、、、枯れきっていない感があるなぁ。
# apt-get install fuseext2
...
# fuseext2 -o ro /dev/c/c /mnt
# mount | grep mnt
fuseext2 on /mnt type fuse.fuseext2 (ro,nosuid,nodev)
取り敢えず、ReadyNAS Duo からサクサクとファイルを抜き出せるようになりましたと。。。まぁ、ファンが五月蝿いから捨てますかねぇ。
かなり期間が空いてしまったが、ブログを再開してみようと思う。 2013年3月が直前の投稿だったが、頻繁に更新していた時期が 2011年11月までなので、8年間ぶりとなる。 8年間なにをしていたのかと言えば、2回転職して未だにIT技術者の職を得ている。 その...