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を探すといろいろ出てくるよ。

IBM版LTFSをRHEL5で使ってみた



IBMのLTOチェンジャーを使ってLTFSを構築することになったので、やってみた。

用意するもの
・Linux用LTOドライバ lin_tape
 配布はlin_tape-バージョン.src.rpmという形のsource rpmなので、rpmbuildでコンパイルする
・IBM版LTFS LE(Library Edition)
 IBMページを起点に入手・・・と行きたいところだが、実際には気軽に入手できないので注意。
 IBM LTOチェンジャーを買うと、IBM営業経由でSoftware CDを入手することができる。
 Webで入手できるのはCDに対するアップデータで、ベースがないと動作しない。

手順

1. lin_tapeをインストール
 インストール後、/dev/st0、/dev/nst0という形だったLTOドライブは
 /dev/IBMTape0という名前になる。
2. 現状のデバイス名確認
 # ls -l /dev/IBM*
 「IBMChanger0」はLTOチェンジャー部分のデバイス
 「IBMtape0」はLTOテープドライブ分のデバイス
3. LTFS LEをインストール
 まぁ、普通にRPMをインストール

・LTFS LEの起動
チェンジャーデバイスが「/dev/IBMchanger0」
LTFSのマウントポイントを「/ltfs」とする場合、以下の様に起動する。

[root@ltfs ~]# ltfs /ltfs -o changer_devname=/dev/IBMchanger0
LTFS14000I LTFS starting, LTFS version 2.1.2.0 (2501), log level 2
LTFS14058I LTFS Format Specification version 2.1.0
LTFS14104I Launched by "ltfs /ltfs -o changer_devname=/dev/IBMchanger0"
LTFS14105I This binary is built for Linux (x86_64)
LTFS14106I GCC version is 4.1.2 20080704 (Red Hat 4.1.2-52)
LTFS17087I Kernel version: Linux version 2.6.18-194.el5 (mockbuild@x86-005.build.bos.redhat.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64
LTFS17089I Distribution: Red Hat Enterprise Linux Server release 5.5 (Tikanga)
LTFS14063I Sync type is "time", Sync time is 300 sec
LTFS17085I Plugin: Loading "ibmtape" driver
LTFS17085I Plugin: Loading "unified" iosched
LTFS17085I Plugin: Loading "ibmtape" changer
LTFS17085I Plugin: Loading "ondemand" dcache
LTFS11593I LTFS starts with a product license version (20120712_1200)
LTFS12165I lin_tape version is 1.74.0
LTFS12118I Changer identification is '3572-TL         '
LTFS12162I Vendor ID is IBM
LTFS12159I Firmware revision is 0021
LTFS12160I Changer serial is 00000XXXXXXXXXXX
LTFS12196E IOCTL: INQUIRY PAGE -1056947426 failed -20501 (err 22) 00000XXXXXXXXXXX
LTFS12165I lin_tape version is 1.74.0
LTFS12158I Opening a device through ibmtape driver (/dev/IBMtape0)
LTFS12118I Drive identification is 'ULT3580-HH5     '
LTFS12162I Vendor ID is IBM
LTFS12159I Firmware revision is BBNF
LTFS12160I Drive serial is 1068082305
LTFS17160I Maximum device block size is 1048576
LTFS13500I On-demand dentry cache is initialized
LTFS11545I Rebuilding the cartridge inventory
LTFS14506I LTFS admin server is listening on port 2112
LTFS14111I Initial setup completed successfully
LTFS14112I Invoke 'mount' command to check the result of final setup
LTFS14113I Specified mount point is listed if succeeded
[root@ltfs ~]# 

注意:自動起動してくれないので、サーバを起動するたびに実行する必要がある。

・LTFSでのデバイス認識状況を確認

[root@ltfs ~]# ltfsadmintool -I
1068082305 -> Device: /dev/IBMtape0 [ULT3580-HH5] , Library address: 257, Status: Available
[root@ltfs ~]# 

ドライブが1台であるばあい、こんな風に表示される。

・LTFS上のテープメディア認識状況を確認
「ltfsadmintool -i」で確認します。

[root@ltfs ~]# ltfsadmintool -i
BMV157L5 -> Location: Medium storage element,    Address: 4095, Capacity:   0GB, Remaining:      0GB, Status: Unknown
BMV156L5 -> Location: Medium storage element,   Address: 4097, Capacity:   0GB, Remaining:      0GB, Status: Unknown
BMV158L5 -> Location: Medium storage element,   Address: 4099, Capacity:      0GB, Remaining:      0GB, Status: Unknown
[root@ltfs ~]# 

「Status: Unknown」となっている場合は、まだフォーマットされていないか、一度の読み込まれたことがないテープです。

・LTFSで利用するLTOテープをフォーマットする

[root@ltfs ~]# ltfsadmintool -t BMV157L5 -f 
LTFS15000I Starting mkltfs, LTFS version 2.1.2.0 (2501), log level 2
LTFS15041I Launched by "/opt/IBM/ltfs/bin/mkltfs -d /dev/IBMtape0 -s BMV157"
LTFS15042I This binary is built for Linux (x86_64)
LTFS15043I GCC version is 4.1.2 20080704 (Red Hat 4.1.2-52)
LTFS17087I Kernel version: Linux version 2.6.18-194.el5 (mockbuild@x86-005.build.bos.redhat.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64
LTFS17089I Distribution: Red Hat Enterprise Linux Server release 5.5 (Tikanga)
LTFS15003I Formatting device '/dev/IBMtape0'
LTFS15004I LTFS volume blocksize: 524288
LTFS15005I Index partition placement policy: None
LTFS17085I Plugin: Loading "ibmtape" driver
LTFS12165I lin_tape version is 1.74.0
LTFS12158I Opening a device through ibmtape driver (/dev/IBMtape0)
LTFS12118I Drive identification is 'ULT3580-HH5     '
LTFS12162I Vendor ID is IBM
LTFS12159I Firmware revision is BBNF
LTFS12160I Drive serial is XXXXXXXXXX
LTFS17160I Maximum device block size is 1048576
LTFS17157I Changing the drive setting to write-anywhere mode
LTFS15010I Creating data partition b on SCSI partition 1
LTFS15011I Creating index partition a on SCSI partition 0
LTFS12207I Logical block protection is disabled
LTFS17165I Resetting the medium's capacity proportion
LTFS11097I Partitioning the medium
LTFS11100I Writing label to partition b
LTFS11278I Writing index to partition b
LTFS11100I Writing label to partition a
LTFS11278I Writing index to partition a
LTFS15013I Volume UUID is: ae724b01-e9ce-40b8-8786-573eab051801
LTFS15019I Volume capacity is 1425 GB
LTFS12207I Logical block protection is disabled
LTFS15024I Medium formatted successfully
Tape BMV157L5 successfully formatted or unformatted.
[root@ltfs ~]# 

なお、一度、LTFSでフォーマットしたことがあるメディアは、上記のコマンドではフォーマットできない。
「ltfsadmintool -t BMV157L5 -f — -f」というふうに「– -f」というオプションをつける必要がある。

・LTFSでフォーマットされ、認識されたことを確認
下記は、BMV157L5 とBMV156L5をフォーマットした後の表示です。

[root@ltfs ~]# ltfsadmintool -i
BMV157L5 -> Location: Data transfer element,    Address:  257, Capacity:   1327GB, Remaining:   1296GB, Status: Valid LTFS
BMV156L5 -> Location: Medium storage element,   Address: 4097, Capacity:   1327GB, Remaining:   1296GB, Status: Valid LTFS
BMV158L5 -> Location: Medium storage element,   Address: 4099, Capacity:      0GB, Remaining:      0GB, Status: Unknown
[root@ltfs ~]# 

・テープへの書き込み

/ltfs/の下を覗くと、バーコードラベルのディレクトリが表示されます。
そこにcdコマンドで移動したり、cpのコピー先として指定したりすることで
通常のファイルシステムと、ほぼ同等に使うことができます。