munin向けのpcsensorプラグインを作った

上海問屋のDNSB-35137など、いくつかの販路で取り扱われているUSB接続の温度計 RDing TEMPerV1.2。

その温度をmuninで計測するためにpluginを作った。

今回考慮が必要だった点
・USB温度計を2つつなぐ
・つなぐUSB BUSが同じであるため、CentOS5上で見分けがつかない
 (TEMPerV1.2ではシリアルを含めデバイス内のパラメータが全部一緒で見分ける方法がない)
・2つの温度計の設置位置は違うので、温度差が5度ぐらいある
・pcsensorコマンド実行時、デバイスがオフラインになることが良くある
 (参考→USB温度計 TEMPerV1.2は計測ミスが多い)

あまり複雑なことをするのも嫌だったので、単純な実装としました。

・温度が2つ取得できるまで、再試行する
・温度が低い方から順にソートして「usbtemper0」「usbtemper1」としていく

また、内部で使うコマンドは、うちで作成した「pcsensor-1.0.2 for TEMPerV1.2 with multi device support」を使います。

USB温度計を1個しか繋がない人は「my $maxdevice=1;」に書き換えてください。

#!/usr/bin/perl -w

my $options="-d";
my $maxdevice=2;

my $arg=$ARGV[0];
if(!$arg){ $arg=""; }

if("$arg" eq "config"){
    print "graph_title USB Temperature Sensor\n";
    print "graph_vtitle Celsius\n";
    print "graph_category sensors\n";
    print "graph_args --base 1000 -l 0\n";
}

my @devlist;
my $count=0;
while($count<$maxdevice){
    open(FILE,"/usr/local/bin/pcsensor $options|");
    while(my $line=<FILE>){
        $line =~ s/\n//ig;

        if($line =~ /Temperature/){
            my @strs=split(/ /,$line);

            my $devnumber=$strs[3] ."-". $strs[5];
            my $value=$strs[8];
            $value=~ s/C//ig;
            #$value=int($value);

            $devlist[$count]=$value;
            $count++;
        }
    }
    close(FILE);
}

my $counttmp=0;
foreach $value (sort @devlist){
    if("$arg" eq "config"){
        print "usbtemper".$counttmp.".label USB temper".$counttmp."\n";
    }else{
        print "usbtemper".$counttmp.".value ".$value."\n";
    }
    $counttmp++;
}

これ、仕掛けて3時間ぐらいしたら、kernel panic起こしやがった・・・

FleaPhone用CWM Recoveryを修正

先日来から「FleaPhone CP-D02用のClockwork Mod RecoveryとGoogle Play」にて公開しているcwm-recovery-20130423.imgですが、プログラム内での機種設定に誤りがありました。
このため、FleaPhone CP-D02用に設定されているupdate.zipを適用しようとすると、該当機種ではない、として適用できませんでした。

このため、CWM Recoveryからであっても純正のupdate.zipがきちんと適用できるよう、機種設定を正しいものにしたものを作成しました。

cwm-recovery-20130527.zip

なお、このCWM Recoveryを使って、純正update.zipを適用することができますが、純正update.zip内には、標準recoveryに戻すプログラムが組み込まれていますので、注意してください。
再起動する前に、superuser.zipを適用しておけば、あとでも何とかなるとは思いますけど。

レトロ風ゲーム専用携帯機 the nDは終了したのかな?

だいぶ前に紹介したthe nDという携帯ゲームハードウェア。
(2011年8月8日「the nD」および2011年11月7日「the nDのその後・・・?」)

どうやら、逃げたみたいです。

半年ぐらい前はまだ、サイトが残っていたんですが、2013年5月現在、トップページ(http://the-nd.com/)とかフォーラム(http://the-nd.com/forum/)だったURLにアクセスしても、首謀者Bobのメインサイト http://game.bobsgame.com/ に飛ばされます。

アクセスしてみると、Javaのローディングが始まります。
page

で、ライセンスとかについての確認があって・・・
page1

しばらく読み込まれた後、なにかゲームっぽいのが始まります。
page4

えぇ、↑の画面、ゲームが始まっているんですよ。
カーソルキーを動かすと、なにかキャラみたいなのが動くんですが、状況説明とかが何もないし、よく見えないので、何がなんだかさっぱりわかりません。

レトロゲーム風のアドベンチャーっぽい雰囲気だけは感じられます。

なんか、ハードウェアについては、まるでMorphy Oneみたくなっちゃいましたね。

ちなみに↓は秘蔵のモルフィーワンの写真
IMG_0623
IMG_0625
2002年6月に秋葉原であった初お披露目の時に撮影したものです。


2013/05/23追記

海外のゲーム系blog PolygonsandPixelsで、the nD関連の記事を発見しました。

2013/03/01:The strange tale of “bob’s game”
2013/05/11:A new phase of Bob’s Game

ゲームを進めていくと何かでてくるらしいが・・・


2020/01/23 追記

久しぶりにどうなったのか確認してみると、首謀者Bobのページは「Bob Corporation」に移動していた。

Steamで「Bob’s game」という名称でテトリスとぷよぷよを組み合わせたような感じでネットワーク対戦もサポートした落ちものゲームを2016年~2017年にかけてリリースしていた。

githubの「 https://github.com/bobsgame 」でゲームサーバとアプリのソースを公開している。ただし、下記のようにソースを公開しているだけで、オープンソースではない、と言っている。

bob’s game is “source available” and “free as in beer” but not “Open Source” and “free as in speech” (yet).

That means no forks except to create pull requests!

FleaPhone CP-D02にシステムアップデート 0502G032_20130428が出てた

coviaのFleaPhone CP-D02にシステムアップデート 0502G032_20130428が出ていました。

「システム更新」アプリで確認すると、以下の様な表示になりました。
device-2013-05-22-004431

ダウンロードが終わると、以下の様な画面で適用確認されます。
device-2013-05-22-004704

CWM Recovery状態でも、適用できそうな雰囲気ではあったのですが、駄目でした。
IMG_5165
駄目な理由はCWM Recoveryでのデバイス認識符が適切でないことで、update.zip内の機種チェックが引っかかっていたためです。

そのうちCWM Recovery側を修正しますが、とりあえず、アップデートを適用する方法はあります。
/sdcard/googleota/update.zip を取り出して、update-scriptを編集するのです。

assert(getprop("ro.product.device") == "htt77_ics2" ||
       getprop("ro.build.product") == "htt77_ics2");
show_progress(0.500000, 0);
format("ext4", "EMMC", "/system", "0");
mount("ext4", "EMMC", "/dev/block/mmcblk0p3", "/system");
package_extract_dir("recovery", "/system");
<略>

というところの、最初の2行を下記の様にコメントにしてから、ファイルをupdate.zipに戻します。

#assert(getprop("ro.product.device") == "htt77_ics2" ||
#       getprop("ro.build.product") == "htt77_ics2");
show_progress(0.500000, 0);
format("ext4", "EMMC", "/system", "0");
mount("ext4", "EMMC", "/dev/block/mmcblk0p3", "/system");
package_extract_dir("recovery", "/system");
<略>

戻したファイルをCWM Recoveryから指定すれば、アップデートができます。
IMG_5170

再起動をすると、更新が始まって・・・
IMG_5172

そして、システム更新アプリでチェックすると・・・
device-2013-05-22-010231

ほらね。

なお、アップデート後は、CWM Recoveryが消えます。
また、/system/xbin/suも消えます。
でも、他のアプリやデータはそのまま残っていました。

アップデート後のbuild.propは以下の通りです。

# begin build properties
# autogenerated by buildinfo.sh
ro.build.id=IMM76D
ro.build.display.id=ALPS.ICS2.MP.V1.19
ro.build.version.incremental=eng.wangzijian.1367136287
ro.custom.build.version=1367136287
ro.build.version.sdk=15
ro.build.version.codename=REL
ro.build.version.release=4.0
ro.build.date=Sun Apr 28 16:06:09 CST 2013
ro.build.date.utc=1367136369
ro.build.type=user
ro.build.user=wangzijian
ro.build.host=wangzijian-desktop
ro.build.tags=test-keys
ro.product.model=covia_CP-D02
ro.product.brand=VOTO
ro.product.name=htt77_ics2
ro.product.device=htt77_ics2
ro.product.chivinproduct=covia_CP-D02
ro.product.chivinversion=0502G032_MH011S-T8100PM15E
ro.product.customversion=0502G032_20130428
ro.product.board=htt77_ics2
ro.product.cpu.abi=armeabi-v7a
ro.product.cpu.abi2=armeabi
ro.product.manufacturer=alps
ro.product.locale.language=ja
ro.product.locale.region=JP
ro.wifi.channels=
ro.board.platform=
# ro.build.product is obsolete; use ro.product.device
ro.build.product=htt77_ics2
# Do not try to parse ro.build.description or .fingerprint
ro.build.description=htt77_ics2-user 4.0 IMM76D eng.wangzijian.1367136287 test-keys
ro.build.fingerprint=HTT:4.0/IMM76D/1367136287:user/test-keys
ro.build.flavor=
ro.build.characteristics=default
# end build properties

# begin mediatek build properties
ro.mediatek.version.release=ALPS.ICS2.MP.V1.19
ro.mediatek.platform=MT6577
ro.mediatek.chip_ver=S01
ro.mediatek.version.branch=ALPS.ICS2.MP
# end mediatek build properties
#
# system.prop for generic sdk
#

rild.libpath=/system/lib/mtk-ril.so
rild.libargs=-d /dev/ttyC0


# MTK, Infinity, 20090720 {
wifi.interface=wlan0
# MTK, Infinity, 20090720 }

# MTK, mtk03034, 20101210 {
ro.mediatek.wlan.wsc=1
# MTK, mtk03034 20101210}
# MTK, mtk03034, 20110318 {
ro.mediatek.wlan.p2p=1
# MTK, mtk03034 20110318}

# MTK, mtk03034, 20101213 {
mediatek.wlan.ctia=0
# MTK, mtk03034 20101213}


# MTK, TeChien {
ro.media.enc.hprof.file.format=3gp
ro.media.enc.hprof.codec.vid=m4v
ro.media.enc.hprof.vid.width=720
ro.media.enc.hprof.vid.height=480
ro.media.enc.hprof.vid.fps=30
ro.media.enc.hprof.vid.bps=3400000
ro.media.enc.hprof.codec.aud=amrnb
ro.media.enc.hprof.aud.bps=12200
ro.media.enc.hprof.aud.ch=1
ro.media.enc.hprof.aud.hz=8000

ro.media.enc.mprof.file.format=3gp
ro.media.enc.mprof.codec.vid=m4v
ro.media.enc.mprof.vid.width=352
ro.media.enc.mprof.vid.height=288
ro.media.enc.mprof.vid.fps=30
ro.media.enc.mprof.vid.bps=990000
ro.media.enc.mprof.codec.aud=amrnb
ro.media.enc.mprof.aud.bps=12200
ro.media.enc.mprof.aud.ch=1
ro.media.enc.mprof.aud.hz=8000

ro.media.enc.lprof.file.format=3gp
ro.media.enc.lprof.codec.vid=h263
ro.media.enc.lprof.vid.width=176
ro.media.enc.lprof.vid.height=144
ro.media.enc.lprof.vid.fps=30
ro.media.enc.lprof.vid.bps=384000
ro.media.enc.lprof.codec.aud=amrnb
ro.media.enc.lprof.aud.bps=12200
ro.media.enc.lprof.aud.ch=1
ro.media.enc.lprof.aud.hz=8000
# MTK, TeChien }

#
wifi.tethering.interface=ap0
#

ro.opengles.version=131072

wifi.direct.interface=p2p0
dalvik.vm.heapgrowthlimit=64m
dalvik.vm.heapsize=128m


# Encrypt phone function
ro.crypto.tmpfs_options=mode=0771,uid=1000,gid=1000
ro.crypto.fs_type=ext4
ro.crypto.fs_real_blkdev=/emmc@usrdata
ro.crypto.fs_mnt_point=/data
ro.crypto.fs_options=noauto_da_alloc
ro.crypto.fs_flags=0x00000406

# USB MTP WHQL
ro.sys.usb.mtp.whql.enable=0

# Power off opt in IPO
sys.ipo.pwrdncap=2

ro.camera.sound.forced=1

ro.sys.usb.storage.type=mtp,mass_storage
#HTT liujihui {
ro.setupwizard.mode=DISABLED
ro.com.google.locationfeatures=1
ro.com.google.networklocation=1
persist.sys.timezone=Asia/Shanghai
#HTT liujihui }

#
# ADDITIONAL_BUILD_PROPERTIES
#
fmradio.driver.chip=1
ril.external.md=1
ro.sf.hwrotation=180
ril.current.share_modem=1
launcherplus.allappsgrid=2d
launcher2.allappsgrid=3d_20
curlockscreen=2
ro.mediatek.gemini_support=false
persist.radio.fd.counter=20
persist.radio.fd.off.counter=20
drm.service.enabled=true
fmradio.driver.enable=0
mediatek.wlan.chip=MT6620
mediatek.wlan.module.postfix=
dalvik.vm.mtk-stack-trace-file=/data/anr/mtk_traces.txt
ro.config.notification_sound=Tinkerbell.ogg
ro.config.alarm_alert=ring4.mp3
ro.config.ringtone=CaribbeanIce.ogg
ro.config.sound_fx_volume=-10
net.bt.name=Android
dalvik.vm.stack-trace-file=/data/anr/traces.txt

SSD+SATAのハイブリッドストレージ Nimble Storageについて調べてみた

Nimble Storageというストレージプロダクトがあるらしい。
それについて調べたことを書いてみる。
うたい文句をみるとTintri VMstoreと似てる感じがするなぁ・・・と思いつつ内容を調査した。

なお、これは以前書いた「Nimble Storage」という記事についてのアップデートです。
簡単に言えば、書いた記事には誤りがあったための更新ついでに、競合との比較です。

Tintri VMstoreと大きく違う点

・Nimble StorageはiSCSIストレージ
 汎用的に使えるiSCSIストレージ
 VMware/Hyper-V/通常のWindows/Citrixで使える
 TintriはNFSストレージで、さらにVMware以外は公式にサポートしない

・SSDはRead Cacheとして使用
 実体は全てSATA HDD上に置かれている
 Tintriは、SSDとSATA HDDのどちらかに置かれており、必要に応じて自動的に移動する

・Web GUI以外の管理手法が完備されている
 SNMP MIB、CLI操作が使える
 Tintriは、Web GUI以外に無い

・vSphere関連のプラグインが一通り揃っている
 VAAI, vSphere Client plugin, SRM pluginがある。
 2013年5月現在TintriはVAAIのみ

・VSS連携も可
 WindowsのVolume Shadowcopy Serviceとの連携も可能

・レプリケーション機能を初期リリースからサポート
 Tintriは、最新のver2.0でサポートのはずだが、2013年5月現在入手できず。

・容量拡張手法がいくつかある
 容量が足らない→Shelf増加(パフォーマンス低下は無い)
 パフォーマンスが足らない1→SSDの容量アップ(オンラインで実施可能)
 パフォーマンスが足らない2→システム追加+クラスタ化
 Tintriの場合、「システム追加」しかない

・複数システムをクラスタ化できる
 複数のNimble Storageを1システムの様に取り扱うことができる
 ユーザはNimbleを使い分ける、ということを意識する必要は無い
 Tintriの場合、明示的に使い分ける必要がある。

・Web GUIからシステムアップデートができる
 Web GUIからシステムアップデートができる、というのは良くあるが
 アップデートするバージョンを複数から選択できる、というのは珍しい。
 最新は嫌、とか、導入済みのものと合わせたい、という場合に便利。
 Tintriは、本体にキーボードとUSBメモリを取り付けて、コンソール操作でのアップデート。

細かな話

・実データをHDDに書くけど遅いんじゃないの?
もちろん、まともに書くと遅いので、うまくごまかしています。

書き込まれたデータはある一定サイズになるまで、メモリ(NVRAM)上にため込まれます。
既定サイズを超えたら、データ圧縮をおこない、HDDに書き込みます。
ここで既定されているサイズは、SATA HDD 11本で構成されたRAID6に書き込む際に、最速シーケンシャルwriteになるように設定されている。(以降「writing block」と呼びます。なおこの表記はオフィシャルではありません)
つまり、速度が落ちるランダムwriteを排除している、ということになる。

・データ書き換え時ってどうしてるの?
データが書き換えられた時は、書き換え後のデータは通常のwriteデータと共にメモリ上にため込まれます。
そして、通常の書き込みプロセスと同様にwriting block単位で圧縮書き込みされます。
書き換え前のデータは不要になりますが、これはひとまず、メタデータ上のみで無効化されます。
その後、システム負荷を見計らいつつ、データ再配置処理がおこなわれ、空き領域が回収されます。

・え?データは圧縮されてるのに、再配置ってどうやるの?
はい、データが圧縮書き込みされているので、単純な再配置処理ではありません。
再配置は、不要になったデータが含まれているwriting block単位でおこなわれます。
まず、writing block内にある有効なデータをメモリ上に読み込みます。
この読み込んだデータと、通常のwriteデータを合わせて、新規のwriting blockとして、ディスクに書き込みをおこないます。
その後に、元々のwriting blockを無効化し、再利用可能状態にします。

・SSDを冗長化してないけどいいの?
キャッシュでしかないので問題ない。
壊れたらそのSSDを使わなくなるだけで、他のSSDを使って改めてキャッシュされる。
SSDを交換したら、改めて使用される。

・いろいろモデルがあるけどどういう違い?
CS2xxとCS4xxは、CPUの違い
CS220/240/260およびCS420/440/460は、それぞれSATA HDDの容量の違い。
Baseモデルとx2 Flashモデル、x4 Flashモデルの違いは、4本入っているSSDの容量の違い。
例えば、CS220のBaseモデルだったら80GB SSDが4本で320GB、という感じ。

・複数Shelfとかクラスタを組んだ時とかってデータ配置どうなるの?
初期配置としては、均等になるようばらばらに割り振る。
使っていくうちにデータ使用量の偏りが出てくる。
そのような場合は、Re-balance処理が実施され、均等になるように再配置される。
Re-balance処理は低プライオリティで実行されるためパフォーマンス影響は少ない。

・いい資料が見付からないんだけど
Nimble storage Communityを探すといろいろ出てくるよ。