ブログ・ア・ラ・クレーム

技術的なメモとかライフログとか。

Android で、WiFi やBluetooth を有効にしたまま機内モードに移行する

機内モードへ移行する時は、例えば以下のようにするわけだが、機内モードに移行する際、WiFi とBluetooth 通信もOFFになる。

Settings.System.putInt(context.getContentResolver(), Settings.System.AIRPLANE_MODE_ON, 1);
Intent intent = new Intent(Intent.ACTION_AIRPLANE_MODE_CHANGED);
intent.putExtra("state", true);
context.sendBroadcast(intent);

機内モードへ移行する際、WiFi とBluetooth の有効状態を変更させたくない場合、以下の様にAIRPLANE_MODE_RADIOSの設定を書換える。

Settings.System.putString(context.getContentResolver(), Settings.System.AIRPLANE_MODE_RADIOS, "cell");

WiFi とBluetooth の有効状態を変更させるようにする場合、以下の様にAIRPLANE_MODE_RADIOSの設定を書換えれば元に戻せる。

Settings.System.putString(context.getContentResolver(), Settings.System.AIRPLANE_MODE_RADIOS, "cell,wifi,bluetooth");

Auto Network Switcher 0.5 アップデート

ネットワーク接続を自動的にON/OFFするAndroidアプリ「Auto Network Switcher」を0.4.1 へアップデートしました。

https://market.android.com/details?id=jp.syucream.ans&feature=search_result


更新箇所は以下の通り

  • WANに繋がるWiFi 接続が可能になったとき、自動的に機内モードに移行するオプションを追加

WiFi通信を主に使用し、たまに3G通信を行う様な場合に、使えるオプションかも知れません。
機内モードになっている時間が長くなるので、通話を行う様な端末では有効にしない方が良いかもしれません。。。
データ通信用端末で有効にすると、少し有用になるかもしれません。

Perl Packager でスクリプトを集約

久々にPerl でちょっとしたスクリプトを書いたのですが、実際にスクリプトを使ってもらう方がエンジニアでは無い為「cpan でモジュールインストールとかよく分からない」などという事が。
思うところもある場面だったので、pp(Perl Packager)でスクリプトと依存モジュールをまとめて一つのスクリプトに集約してみました。

基本的に以下の手順でOK

$ pp -p source.pl
$ par.pl -b -Opacked.pl a.par # 集約されたpacked.pl が生成される
$ perl packed.pl # 普通にスクリプトを実行可能

pp は基本的にモジュールの依存関係を判別してくれるらしい・・けどどうもお漏らししているっぽい。
そういう時は、-M[モジュール名]の形式で、手動でモジュール名を指定してあげると良い

$ pp -p source.pl
$ par.pl -MJSON::XS -b -Opacked.pl a.par # JSON::XS を組み込む

しかしどうも生成されたスクリプトの実行に失敗する。
サンプルのJSON::XS はCで書かれているためか。pure perl なモジュールじゃないと厳しそうだ。
とりあえず僕の遭遇した例では、特に性能を要求される場面では無かったし、どのような環境で動かすか決定していなかった為下手にバイナリくっ付けられても嬉しくない可能性があった為、pure perl なJSONモジュールで代替した。

$ pp -p source.pl
$ par.pl -MJSON -MJSON::backportPP -b -Opacked.pl a.par

SSD時代のファイルシステム選択について考えてみる

この記事は、カーネル／VM Advent Calendar の、12/28 日目の記事です。

はじめに

ご存知の通り、近年ハードディスクに代わるストレージとして、SSD(Solid-State Drive) が普及してきています。
SSDはフラッシュメモリと高性能なコントローラを搭載した、高速にアクセス可能なストレージです。
僕もこの夏、スペックに限界を感じ始めてきたMacBook Pro (13-inch, Mid 2009) にIntel SSD 320 series 80GB を突っ込んでストレスフルな環境から脱出できたり、なかなか助けられています。


しかしながらこのSSD、掘り下げて見ていきますと、ハードディスクとは構造上の差異などが見られ、なかなかクセモノです。
特にディスクI/Oの性能を左右するファイルシステムは、これまでハードディスクを用いる事を前提に最適化されているものが多くありますが、これほどまでにSSDが普及した今、SSD向けに最適化されて然るべきでしょう。
実際に、SSD向けに最適化されていると謳っているファイルシステムも登場してきています。


そこで本稿ではハードディスクとSSDの差異を確認しつつ、SSD向けに最適化されたファイルシステムとはどんなもので、何をしてくれるのかという点にざっくり触れてみようと思います。
残念ながら僕は意識低いので、面白い実装や実験結果などは無しです。ご了承下さい。

ハードディスクとSSDの特徴


ハードディスクの特徴を列挙すると、以下のような感じになるかなと思われます。

  • 記憶媒体は磁気を帯びたディスク。
  • 読み書きを行う際は、高速回転する磁気ディスク上を、磁気ヘッドを駆動して目的のセクタに移動し、磁気的に読み出し/新しい値の上書きを行う。
  • 読み書きが行われる最小単位はセクタ(512バイト )
  • アクセスを行う際、どうしても磁気ヘッドを駆動するシーク時間が発生する。このため、ランダムアクセスの性能低下が顕著。
  • 容量当りのコストが低い（今年は洪水の影響の為、そうとも言えなかったですが・・・）


対してSSDは、以下のような特徴があります。

  • 記憶媒体はフラッシュメモリ。
  • 読み書きを行う際は、電気的に読み出し/新しい値の注入を行う。
  • 読み書きが行われる最小単位はページ。削除が行われる最小単位はブロック。これらのサイズはモノによって左右される。一般的に ページサイズ ＜ ブロックサイズ。
  • 単純な"上書き処理"ができないという制約が存在（上書きしたい場合、古いデータの削除 → 新しいデータの書込み、が必要）
  • ハードディスクと同様のインタフェースを提供するため、コントローラ内にFTL(Flash Translation Layer ) という抽象化層をもつ。


このように、ハードディスクとSSDではそもそも記憶媒体から違うなど、案外差異があることが分かります。
また、これらのことを踏まえハードディスクとSSDを比較すると、SSDの以下のような利点/欠点が浮かび上がってきます。

  • 利点
    • I/O性能が高い ( 特にランダムアクセス性能 )
    • 省電力
  • 欠点
    • 使い込んでいくと、ランダムライト性能が低下する
    • 寿命が存在 （メモリセル毎に、書込み/削除を行える回数が決まっている）
    • 容量当りのコストが未だ高い（最近は大分ましになってきた）


ランダムライト性能低下については、ページサイズとブロックサイズの違いと、上書き処理が出来ないことに起因しています。
分かり易い解説があるので、そちらをどうぞ。

ファイルシステムレベルの、SSD向け最適化が何をしているか見てみる

Btrfs におけるSSD向けの最適化

これらのSSDの欠点を受け、ファイルシステムでは実際にはどのような対策がされているのでしょうか。
ここでは、ZFSに影響を受けて作られている、SSD向けに最適化をされているというBtrfs が何をやっているのか触れてみます。


Btrfs でSSD向けの最適化を有効にする場合、mount -o マウントオプションで指定してやる必要があります。
指定出来るオプションは2通り存在する模様です。


ssd オプションを指定した場合、Btrfs が持つ自動デフラグを無効にします。またSSD上でなるべく空き領域が分散しないようデータを連続的に書込んでくれる模様です。
ssd_spread オプションを指定した場合は、基本的にssd オプションと同様なのですが、メタデータに関してのみ分散した領域に書込む事を許可します。
これによりSSD上のデータの無い未使用な領域は連続的なものが多くなる傾向になり、使い込んだ時の性能劣化を抑制することが出来ます。

その他のファイルシステムの、SSD向けの対策

Windows で採用されているNTFSでは、trim コマンドのサポートをしています。trim コマンドは、ATA8-ACS で定められているATAコマンドの一種で、SSDに「指定された領域がファイルシステム以上で使用されていない」事を通知する為のコマンドです。これの実行をファイルシステムレベルで判断出来る事により、不要なファイルが削除された際にSSD上からも削除されるので、上書き処理の実行頻度を削減することができ、SSDを使い込んだ時のランダムライト性能の低減を抑えることができます。


LFS（Log-Structured File System) のような、連続的に書込みログを記録していくような仕組みのファイルシステムでは、ランダムライトの発生頻度が低く、書込み性能の低下を抑えることが可能かと思われます。


余談ですが、ioDrive ではボトルネックの一因にもなりうるFTLを取っ払い、ソフトウェアレベルで独自のレイヤを挿入し、FTLでやられているような寿命の延長や性能向上の為の最適化を行ったりしています。
更に独自のファイルシステムと連携し、性能向上を狙う論文があったりします。*1

おわりに

SSDがこれだけ流行ってきているので、やがて従来のファイルシステムでは満足できなくなってくるのかなと思いつつ記事を書きました。
最近ではPCIe SSDが脚光を浴びるようになり、ディスクI/Oが高速化され胸も熱くなりますね〜。
SSDはハードウェア内部でガリガリ最適化されまくっていて、ファイルシステムレベルからは微妙に手を出し難い部分があるかと思われますが、性能向上と延命の為になるべくなら最適なファイルシステムを選択したいですね。


なお、本稿はちょっと内容が薄いので後で加筆修正を加えるかもしれません。
また何か指摘等ございましたら知らせて頂けると幸いです。

*1:http://www.usenix.org/events/fast10/tech/full_papers/josephson.pdf

Auto Network Switcher アップデート

ネットワーク接続を自動的にON/OFFするAndroidアプリ「Auto Network Switcher」を0.4.1 へアップデートしました。

https://market.android.com/details?id=jp.syucream.ans&feature=search_result


更新箇所は以下の通り

  • アプリ起動中の、ステータスバーへの通知を非表示にする設定を追加しました。

OSのブートとサスペンドによる消費電力についての一考

OS起動時は、デバイスやシステムの初期化、各プロセスの立ち上げなど仕事が多く存在し、これが結構な電力消費になります。
そして頻繁に起動/シャットダウンするような場合には、サスペンドを利用した方がトータルで見た消費電力が低くなります。（起動も速くなりグッドですね）
しかしながらサスペンドは通電した状態を維持するので、完全にシャットダウンする場合と比較しある程度の待機の為の電力消費が発生します。
ならばさて、その損益分岐点はどこにあり、どの頻度で起動/シャットダウンを行うならば、サスペンドで代替してしまった方が低消費電力になるのでしょうか。


色々調査してみますと、Windows 向けにはなりますが以下のような分かり易い資料を発見しました。
シャットダウン vs. スリープ
http://technet.microsoft.com/ja-jp/windows/hh146895

この資料の測定環境では、Windows 7 において1時間40分あたりで消費電力量が逆転する格好になるようです。
つまるところ、ユーザがマシンの使用を一旦止め、再び使用を再開するまでの間が1時間40分以下であればサスペンドを、それ以上であればシャットダウンしてしまうのが、電力消費的に視ればお得という事になるのかと。


ちなみにこの資料におけるサスペンドの待機電力ですが、Windows7 において1Wだそうで。
これを参考に、仮に一ヶ月サスペンド状態で放置した場合の電気代を、電気代計算シミュレータ(http://www.ienakama.com/tips/page/?tid=353 )で算出してみたところ、16.5 円になりました。
これなら、無駄に消費電力を高めているという良心の呵責に囚われなければ、サスペンドを常用しても良さそうな気がします。