2014年9月27日土曜日

OpenStack?

OpenStackをDevStackで試している。

git clone https://github.com/openstack-dev/devstack.git
 
2014/9/27時点で、特に何も設定せずにstack.shを実行したらPythonのdogpile.cacheパッケージが入らずにエラーで止まった。一応、動いている状態になるようなので、unstack.shで止めて、パッケージを入れて、もう一度stack.shを試す。

もうひとつ、libpcre3-devも必要。

get_or_add_user_role等でエラーが出まくったのだが、unstack.shして再度stack.shするとエラーが消えている。どうもハッシュ値か何かでユーザー名が生成されたためのようだ。メモリー4GBでは厳しいようなので、もう一度Ubuntuのインストールからやり直してみよう。

その後、何度か試していると、libpcre3-devを入れた状態ならつつがなくstack.shが終了する模様。

画面サイズがしんどいので、調べたら、guest additionを入れる必要があるとのことで、まずは以下で準備するらしい。
sudo apt-get install build-essential module-assistant
sudo m-a prepare
VirturalBoxのメニューから以下を選ぶ 
"Devices > Insert guest additions CD image" 
これでUbuntu側にメディアがマウントされるので、
sudo ./VBoxLinuxAdditions.run
でビルドできる。 
 
Cinder => block storage
Swift => object storage

VirtualBoxでVERR_VMX_MSR_LOCKED_OR_DISABLEDエラー

FreeBSDホストのVirtualBoxに64bitのUbuntuを入れようとしたら掲題のVERR_VMX_MSR_LOCKED_OR_DISABLEDエラーが発生した。なにしろマイナーな環境だからダメなのかと思いながら調べてみると、なんとBIOS設定でIntel VTxがDISABLEになっているためだった。

そんなわけで、BIOSでEnableしたらあっさりインストールできたのであった。

2014年9月23日火曜日

HDDは長いことアクセスしないファイルから壊れる

以前からそんな印象はあったのだけれど、今回に調べてみて本当にそうらしいと思えた。
これまでHDDのエラーは長いことアクセスしていないファイルで起きる印象があったのだが、これはHDDが怪しくなってきたブロックに出会うと回復処理をしていたためと思われる。

smartctlでHDDの情報を見ると以下のようなものがある。
 ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       5388
 197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       409
Pending_Sectorの方は、エラーが検出されたが回復できていないセクター数を表している。
上記のようなエラーとして現れるケースでカウントアップされるものと思われる。

それでは頻繁にアクセスしているとなぜエラーにならないか。どうも読みだしアクセスであってもリトライが必要など怪しいセクターに出会うと、読めたデータを書き直してリトライ要不要を見る、改善しないならスペアセクターへ移すなどしているようなのだ。そのため、頻繁にアクセスするファイルはリフレッシュがかかり、そうではないファイルにアクセスするとエラーに出会うことになる。

どうしても読めないセクターは書き込めばスペアに移るので、最悪はそのようにするわけだが、どうも定期的にディスク全域をスキャンして回復処理をさせた方がデータを失わずにすみそうに思える。

英語なのだが、Linuxの場合に不良セクターをどう処理するか、以下に良く説明されている。
Linuxの不良セクター回復方法(英語)
FreeBSDの場合もfsdb(8)でブロック番号をiノード番号に変換できるので、同じようなことはできる。
後日追記予定


ath0が動かなくなって難儀した

HDD交換のついでにメモリーを4GByteに替えたら、Atherosの無線LANカードが動かなくなって難儀した。なんでだろうといろいろ考えていて、ふとカードのアドレスが大幅に変わっているのに気がついた(メモリー増やしたのであたりまえ)。
ath0: <Atheros 5212> mem 0x88000000-0x8800ffff irq 17 at device 0.0 on cardbus1
ath0: [ITHREAD]
ath0: AR2413 mac 7.9 RF2413 phy 4.

上記が正しいのだが、メモリーを替えると以下になる。

cardbus1: Expecting link target, got 0x0
cardbus1: Expecting link target, got 0x0
ath0: <Atheros 5212> mem 0xbf690000-0xbf69ffff irq 17 at device 0.0 on cardbus1
ath0: [ITHREAD]
ath0: unable to attach hardware; HAL status 13
device_attach: ath0 attach returned 6

なぜなんだろう。

2014年9月22日月曜日

3TのHDDが不調になって大変でした

一年ちょっと前からつかっていたWDの3TのHDDが不調になってえらい目にあった。
とりいそぎ新しいのを購入してようやく動き出したが、ほぼ丸2日を要してまだ引っ越し未完。
いろいろ勉強になったこともあったので、ちょこちょこ書き加えていきたい。ところでツクモで安く買えたのだが、WDの箱入りでちょっとうれしかった。バルクよりは当てにできるかも?バルクもあたりをひきれば悪くないのだが。

エラーがたまってくるとドライブが勝手にチェックを始めて異常に遅くなるような気がする。
smartctl -t pending,65535 -t select,0-5860533101 /dev/ada2
などとすると、selectで指定した範囲(3Tの最初から最後)のテストを65535分間は停止するので、スピードが戻る。といっても、まだ遅い気がするので、何か勝手に動いているのかも。

だいぶ前に雑誌記事にも書いたことあるが、fsck(8)もstatusシグナル(^t)を受け付けるようだ。
下記のような進捗状況を表示してくれるので、動いているのか?と心配な時はありがたい。
/dev/ada2p4: phase 1: cyl group 717 of 1058 (67%)