SSDかどうかをWMIから判別する

SSDかどうかをC#から判別するではP/Invokeを使ったが、それよりハードルの低いWMIでもSSDかどうかを判別する方法はある（ことを知った）。

1. 説明

具体的には、WMIからWindows Storage Management APIにあるMSFT_PhysicalDiskクラスを利用する。ただし、このWindows Storage Management APIが使えるのはWindows 8（とWindows Server 2012）以降なので、完全にこれに頼れるものでもなく、ケースバイケースで。なお、管理者権限は不要。

初めにWMIでディスクのハードウェア的な情報を取得できるものとして、新しいMSFT_DiskとMSFT_PhysicalDisk、および従来からあるWin32_DiskDriveのプロパティをざっくり比較してみた。

• Comparison of MSFT_Disk, MSFT_PhysicalDisk, Win32_DiskDrive

この中でMSFT_PhysicalDiskのSpindleSpeedとMediaTypeにSSDの情報が含まれている。

• SpindleSpeed
  文字どおりディスクの回転数で、これが0であればSSD。HDDで回転数の情報が取れればその回転数（RPM）、そうでなければUInt32の上限値が返ってくる。
• MediaType
  これが3であればHDD、4であればSSD。情報が取れなければ0が返ってくる。

ここまで分かれば、後は名前空間が従来の\root\CIMV2ではなく、\Root\Microsoft\Windows\Storageなので、それを明示的に指定する必要がある以外は従来のWMIと変わりない。

2. テスト

テスト用に作成したC#のコンソールアプリを、ThinkPad X230上のWindows 8.1で実行した結果。

1番目はUSBポータブルケースに入れたTravelstar 5K1000で、USB接続ではMediaTypeもSpindleSpeedも情報を取れなかった。2番目はUSBメモリで、これも情報を取れず。3番目は内蔵SSDで、これはMediaTypeとSpindleSpeedの両方でSSDという情報が取れた。

次にThinkPad X61s上のWindows 8で実行した結果。

1番目は内蔵HDDのTravelstar 7K1000で、MediaTypeはHDDという情報が取れたが、SpindleSpeedはなぜか情報が取れなかった。2番目と3番目のUSBメモリは両方取れなかった。

以上、とりあえず内蔵であればSSDかどうかの判別に使えると思う。

[追記] PowerShellから実行

WMIということは当然PowerShellからも実行できるわけで、例として以下のような感じ。

Get-WMiObject -namespace Root\Microsoft\Windows\Storage -class msft_physicaldisk | Select-Object FriendlyName,Model,MediaType | Sort-Object FriendlyName

これを実行したもの。MediaTypeが3であればHDD、4であればSSD。

問題なく取得できている。

3. BusType

SSDに限らないが、BusTypeについて、従来のWin32_DiskDriveのInterfaceTypeプロパティでは取れる情報が少なかったので、Win32のDeviceIoControlをIOCTL_STORAGE_QUERY_PROPERTYで実行してSTORAGE_BUS_TYPEを取得するようにしていたが、MSFT_DiskとMSFT_PhysicalDiskにはBusTypeプロパティがあるので、比較してみた。

• BusType of MSFT_Disk, MSFT_PhysicalDisk, STORAGE_BUS_TYPE

一目瞭然だが、情報はほとんど同じで、MSFT_DiskがNVMeを取れるだけ優位にある。したがって、BusTypeに関しては条件が許せばMSFT_Diskで代替できると思う。

コミケ限定特典クラウディアさん

実は昨年末の冬コミでコミケ限定Visual Studio 2013を買いました。

数々の特典に惹かれた、というより、それまでExpress版を使ってきたわけですが、WPFで本格的に開発するとなるとBlendがないと辛いかな、と思っていたのと、特典を別にしてもお買い得価格だという極めて冷静な判断に基づくものですが、クラウディアさんのフィギュアに興味がなくもなかったことは否定しません。

このフィギュアは後日送付ということで、帰ってきて改めて確認すると、「3Dデータ収録USBメモリ」が付くのはチェック済でしたが、「3Dフィギュア（三等身イメージ）」と書いてあって、「おぉ？　三等身だと……？」と驚くと同時に、前のはある意味普通のフィギュアだったので、三等身でどうなるのか俄然興味が沸いてきました。

送付予定は当初は3月末だったようですが、「新しく起こすとなれば時間はかかるよな」とゆっくり構えているうちに3月が過ぎ、「あれー？」と思い始めた4月中旬になって小さな箱が届きました。

その中にごろんと、緩衝材にくるまれていたものを開けてみると、

本当に予想外のことがあると笑ってしまう癖があるのですが、しばし笑い転げました。

額に年輪のように積層した跡があるように、3Dプリンタで出力したもので、最近よく見るフィラメントを重ねていくものではなく、自分は見たことなかったのですが、フルカラー石膏というもののようです。表面はざらざらした粒状なので写真ではぼやけた感じですが、瞳の塗り分け、イヤリング、スカートの模様など、色分けは完璧。

3Dプリントであることは、後から考えれば3Dデータが付くということから予想すべきだったのですが、笑いを倍加したのは頭がでっかいこと。写真で見るとそうでもないですが、実物を手にすると頭の大きさが圧倒的で、全体の容積というか質量の半分はあります。三等身ではなく、二等身ぐらい。

ただ、落ち着いた後にふと思いついて、手許にあったきゅんキャラ『シェリルノーム白うさぎVer.』と並べてみると、

このサイズのディフォルメフィギュアでは、これぐらいの頭と体のバランスは普通でした。

同梱されていたカード型USBメモリにFBX形式のデータが入っていたので、その気になれば自分で3Dプリント業者に持ち込んでプリントもできるようです。

ちなみに、こういう立体物を見ると興味を持つ人はいると思いますが、埋まってません。

スカートの中はちゃんとあります。ここは純粋に3Dプリンタはすごいなと思いました。

以上、サプライズのあるいい特典でした。

[追記] 3Dデータ

ふと3DデータのアイコンがVisual Studioのものぽかったので開いてみたら……。

ぐりぐり動かせます。Visual Studioにこんな機能があるの知らなかった……。つまり、Visual Studioでいじって遊べということだったんですか、Microsoftさん！

ということで、話がVisual Studioに収束しました。

Disk Gazerを拡張

狭い領域の計測に特化していたDisk Gazerを広い領域を計測できるよう拡張しました。

1. アイデア

Disk Gazerは狭い領域の速度を細かく調べるという目的は達しましたが、これをより広い領域、あるいはディスク全体に使いたいという考えは初めからありました。問題は全領域をなめるようにリードしていくとおそろしく時間がかかることで、例えば、平均速度を100MB/sとすると1TBをリードするのに単純計算で2.8時間かかります。現在3.5インチHDDでポピュラーな4TBだと11.1時間にもなります。さすがにこれは実用的ではないです。

したがって、何らかの形で間を飛ばしながら計測する必要がありますが、下手なやり方を取るとHD Tuneの轍を踏むことになるので考え中でしたが、GitHubにリポジトリを置くに際して内部的に大改造したので（計測方法自体は変えず）、同時に広い領域を計測できるよう拡張しました。

基本的なアイデアは前に考えたとおりですが、

• 記録面の波形をなるべく外さない
• 速度の上下動を無理に平均化しない

となると、逆に複雑なことはしない方がいいということで、以下のような形に。

• 実際にリードするblock数の、対象領域の全block数に対する割合を"Area ratio"と呼ぶ。例えばこれが1/16の場合、1/16だけ（累計）リードする。これを使ってリード位置の間隔を決める。
• 速度計算はblockごとのままとする。
• 1つの位置でリードする単位を8blockとする（block sizeを初期設定の1MiBとすると8MiB）。ただし、1番目のblockはシークタイムの影響を避けるため結果には含めない。
• リードするblockを含めた同じ長さのグループを作り、1つのグループの先頭8blockをリードした後は次のグループの先頭に移る。これを順に繰り返す。例えば、Area ratioが1/16の場合、リードする8blockに対して、グループの全block数はその16倍の128とし、残る120blockは無視する。

まあこれ自体は外さない結果を出すための決めごとに過ぎませんが。

ソースコードは最終的にGitHubに置きました。

実行ファイル
レポジトリ

2. 結果

実際にHDDを計測した結果は以下のとおり。ThinkPad X230上のWindows 8.1からUSB3.0接続のポータブルケースに入れたHDDを計測。USB3.0でもHDD程度の速度なら問題ない模様。それぞれの以前のベンチマーク結果は前のエントリから見られる。

Travelstar 7K1000の1TBモデル

Area ratioはLocation (area location)の横に表示。先頭1GiBを先に1/1で全リードしたもの（黄色のライン）に重ねて1/16でリード（黄緑のライン）。

1/16ではリード開始位置は128MiBの間隔で、この記録面の波形なら上に突き出したスパイクを含めて上下動をほぼ捉えている。

次に全領域を1/16で計測したもの。

スパイクがうるさいが（外周では上に、内周では下に出ている）各ゾーンの波形は大体トレースできている。というか、この表示サイズだと計測位置を増やしてもごちゃっと固まるだけなので、あまり違いはないと思う。ちなみにこれで既にリード位置は5万を超えている。

時間は1回のリードに9分かかっているので、5回のリードで45分といったところ。これでもベンチマーク時間としては長いが、試しに1/32のリードをしたら網目が広すぎ、波形を外すようになって良くなかった。

結果とは関係ないが、ポータブルケースはAnkarの2.5" HDD/SSD External Enclosureというものだが、中のHDDの型番を全部返してこないのは少し良くない。

Travelstar 5K1000の1TBモデル

同様に先頭1GiBを1/1で全リードしたもの（黄色のライン）に重ねて1/16でリード（水色のライン）。

波形の上下動は1/16でも捉えられている。

次に全領域を1/16で。

これも問題ないと思う。7K1000は先頭より少し内側の方が速かったが（そういうHDDは時々ある）、5K1000は素直な曲線。

Travelstar 5K1000の500GBモデル

同様に先頭1GiBを1/1で全リードしたもの（黄色のライン）に重ねて1/16でリード（赤紫のライン）。

次に全領域を1/16で。

これも問題ないと思う。外周と内周の速度比が小さいのも以前と同じ。

3. まとめ

以上のように、グラフの表示上、スパイクが実際以上に強調されてしまう傾向はあるものの、ディスク全体を計測する用途にも使えるものになったと思います。思い描いたほどきれいな形にならなかったのは、実際のディスクの姿がそうである以上、仕方ないかな。Block offsetを使えばもう少し上下が収束すると思いますが、時間がおそろしくかかるので。

Snowy

FlashAir用のWindowsデスクトップアプリ、Snowyをリリースしました。

1. 概要

FlashAirはWi-Fiの無線サーバー機能を持ったSDカードで、カメラなどに挿したまま無線でスマートフォンやPCと接続して画像データをダウンロードできます。この分野の走りはEye-Fiですが、東芝はFlashAirのAPIを公開して（FlashAir Developers）自社だけでないアプリ開発を促進しようとしていて、今時の企業戦略という感じです。

で、東芝公式と開発者の関心は、これも今時ですがスマートフォンとPCでもWindowsストアアプリに集中していて、普通のWindowsデスクトップアプリがなかったので（PCメーカーが自社製品用アプリにFlashAir機能を入れたものは存在する）、作ったというものです。普段使いはスマートフォンだけど、PCを含めて全部無線で完結するとうれしいかも、とか、三脚を構えて撮影しながらすぐにPC画面で確認する、とか、使い方次第で便利に使えると思います。

ただ、このアプリの出番となるのはFlashAirがPCと接続した後なので、

• PCとの接続時には少し面倒な点がある。
  特記事項に書いたとおりですが、これ自体はスマートフォンをメインターゲットにする以上、避けられないのかなと思います。といっても、普段のLAN接続が無線の場合はその接続先を変えるだけで、有線の場合は一時期的にLANケーブルを抜けばいいだけなので、たいした手間ではないです。
  
  
• 接続性、転送速度はカメラとPCと距離に大きく左右される。
  これは結構違いが出ます。すいすい快適に使える場合もあれば、「使い物にならん！」という場合も無きにしもあらず。

したがって、このアプリの使い心地は、FlashAir自体の使い心地によるところが大きいですが、そこがクリアされれば快適に使えるのではないかと思います。

2. 裏話

このアプリの開発は、昨年10月のオープンソースカンファレンス東京でFlashAirの説明を聞いたことが始まりです。

そのときに倍率があまり高くなかったこともあってFlashAir Class6 8GBをいただいたので、開発初期はこれを使ってました。その後、Class10でも確認するために、W-02 Class10 16GBを購入しました。

左下の8GBがいただいたものですが、正直「天狗……かな？」と思いました。広がった羽根と小さな帽子と、よく見ると帽子のマークから電波を発していて、超人っぽい何か、というか。

それに対して、上の名刺は今年3月のオープンソースカンファレンス東京でいただいたものですが、閃ソラさんというキャビンアテンダントということが明らかにされました。髪型も変わりました。服装もすっきりしたキャビンアテンダントらしいものになりました。というか、コスプレイヤーさんが来てました。

その頃にはこのアプリは機能面では大体できていて、デザインとネーミングをどうしようか、と考えていたところだったので、直感的にこれで行こう！と思いました。なので、このデザインとネーミングになりました。

ちなみに、Class10は自分が試した範囲ではClass6より接続性（ネットワークの繋がりやすさ）がかなり良くなっているので、Class6で遅いという場合は試す価値はあります。

3. コード

コード的には現在のWPFの第一線の機能を使いたいという目的があって、実はこれが目的の半分だったりします。その甲斐あってか、このアプリはシンプルな外見に比して内部的には結構忙しいのですが、コード量は割と少なく済んでいます。

初めは新しく使う機能はとくに必要なところだけ使えばいいと思ってましたが、結果的に「もっともっと」という感じで使える限り使うことになりました。その方が色々な意味で楽なんですよね。先達の開発者が新しい機能を貪欲に取り入れようとする気持ちがよく分かりました。

開発中は大量の資料を読みましたが、とくに@neuecc、@okazuki、@Grabacr07、@xin9leさんの記事は大変参考にさせていただきました。ただ、ソースコードを見れば丸わかりですが、まだ正直よく分かってないところもあるので、もっと冴えたコードを書きたいですね。