2011/12/01

ThinkVantageボタン

ThinkPadのThinkVantageボタンは、現在はThinkVantage Toolboxの起動ボタンになっているが、これを他のプログラムの起動に利用する方法について。

この話は既にThinkVantageボタンに出ていて、ThinkVantage Toolboxをインストールした状態でレジストリがどうなっているかを確認すると、以下のようになっていた。

これを見れば方法は簡単で、以下のようにすればいい。
  1. HKEY_LOCAL_MACHINE\SOFTWARE\IBM\TPHOTKEYの直下に「8001」という名前のキーを作成する。
  2. その直下に「File」という名前の文字列値を作成する。
  3. この値のデータに起動するプログラムのパスを入れる。
ただ、試したところ、プログラムは起動できるがアクティブにはならず（最前面に来ない）、他のプログラムをデスクトップに広げていると前面に出すのに一手間かかるという問題があった。まあランチャー的なプログラムを挟めば解決できると思うが。
投稿者: EMO 0 コメント
ラベル:

2011/10/31

DiskMarkStream alpha

ふと思い付いて、hiyohiyoさん作のCrystalDiskMark（3.0.1）を自動実行するマクロツールである、DiskMarkStreamを作りました。

CrystalDiskMarkで計測する場合、様々な条件でのテストを（確認の意味を含めて）行うことがありますが、そういうときにとくに役に立ちます。マクロファイルで一遍に設定しておいて、計測を開始した後は放置、というのが基本的な使い方です。
  • 新しいデバイスを買ってきたときに、まず速度を計っておこう……ついでに環境も少し変わってるから前のデバイスも一緒に計っておくか……とやっていると、ついつい睡眠不足になったりしますが、それが楽になります。

  • SSDの場合、計測前にどういう状態だったかの影響が結構あり、計測に難しさがありますが（CrystalDiskMarkも3.0でその点が考慮されています）、各テストの前に任意の休み時間を挟むなどのパターンを組むことができます。
使う人の工夫次第で色々便利に使えるのではないかと思います。試してみて何か気づいた点などあれば、ぜひ報告をお願いします。

プロジェクトサイト: DiskMarkStream 英語 / 日本語 at SourceForge.net
実行ファイル from SourceForge.net

[追記]

CrystalDiskMarkのページで紹介いただきました。ありがとうございます。
投稿者: EMO 2 コメント
ラベル: ,

2011/10/08

画像ガジェット

Microsoft公式のサイドバーガジェット（デスクトップガジェット）のダウンロードサイトであるWindows Live Galleryが終了したのに伴い、ガジェットの多くがダウンロードできなくなりましたが、その中で自分が愛用してきた『画像』について、作者の中山智仁さんの許可が得られたので、オリジナル版の再頒布および表示サイズを調整できるようにした改造版の頒布をすることにしました。
（改造版では、原画像に対する比率を10-100%の範囲で直接指定することが可能）

プロジェクトサイト: Picture-gadget at SourceForge.JP
ガジェットファイル（オリジナル版と改造版の同梱）from SourceForge.JP

自分の使ってきたソフトウェアがいきなり入手不能になるというのは（保存してあればいいとしても）うれしくはないもので、再頒布を快く許可してくださった中山さんに感謝します。

[修正]

改造版がWindowsの地域の形式によって正常に機能しない問題を修正。
投稿者: EMO 0 コメント
ラベル:

2011/09/23

Windows To GoなUSBメモリ

Windows 8 pre-betaであるところのWindows Developer Preview（以下、略してWDP）には、完全に独立したOSをUSBメモリから起動できるWindows To Goがある。これがあればPCにインストールしたままにしなくてもWDPが使えるので、このUSBメモリを作成してみた。

1. 作成方法


BUILD2011の資料を見ると、作成方法がさらっと書いてある。
（Channel9 BUILD2011 Running Windows from an external USB drive with Windows To Goのスライド資料より）

環境依存のドライブレターがそのまま入っているので分かりにくいが、大体以下の手順で作成できることが分かる。
  1. imagex.exeで（予め作成しておいた）OS環境のイメージファイル（.wim）をUSBメモリに展開する。
  2. Bcdboot.exeでOSを起動可能にする。
ただ、これを試すには幾つか問題があって、
  • imagex.exeか他の方法でイメージファイルを作成するときに必要なオプション、その有無が不明。
  • WDPのバージョン（Build 8102）に対応したimagex.exeはWindows ADK（Windows 7までのWindows AIKに相当）に入っているようだが、これをダウンロードするにはMSDNサブスクリプションが必要。
何とかできなくもなさそうだが骨が折れそうなので二の足を踏んでいたところ、先人によれば（How to Create a Windows To Go USB Drive）割と簡単にできるらしい。すなわち、imagex.exeはWindows 7のWindows AIKにあるもので可で、イメージファイルはWDPのインストールDVD中のものを使えばいいらしい。

これに従えば、手順は以下のようになる。
  1. Windows 7のWindows AIKをインストールし、imagex.exe（64bitは\Program Files\Windows AIK\Tools\amd64に、32bitは\Program Files\Windows AIK\Tools\x86にある）を適当な場所にコピーしておく。

  2. 32GB以上のUSBメモリをDiskPartでブート可能にしておく。詳しい方法は従来と同じ（diskpartを使ってWindows Vista/7のインストールUSBメモリを作る）。ただし、ファイルシステムはNTFSで。

  3. WDPのインストールDVDのISOファイルをマウントして（Windows 8では標準でこれが可能）、install.wim（\sourcesにある）をimagex.exeと同じ場所にコピーしておく。

  4. USBメモリを挿し、管理者としてコマンドプロンプトを開いて、imagex.exeのある場所から以下を実行（かなり時間がかかる）。ここまではWindows 7でも可。

    imagex.exe /apply install.wim 1 d:\
    （USBメモリのドライブレターがD:の場合）

  5. 続いて以下を実行。ここはWDPでなければ不可（Windows 7ではBcdboot.exeに/fオプションがないので）。

    bcdboot.exe d:\windows /s d: /f ALL
    （同上）
なお、このイメージファイル（install.wim）はインストール途中の状態を保存したものなので、これでブートすると残りのインストールが行われた後に起動する。

2. 実際


実際に試した条件は以下のとおり。
  • PC: ThinkPad X61s（CPU: Core2Duo 1.8GHz、メモリ: 4GB、USB2.0）
  • ISOファイル: 開発ツール付きの64bit版（WindowsDeveloperPreview-64bit-English-Developer.iso）
  • USBストレージ:
    • Buffalo RUF3-S32GS-BK (32GB、USB3.0、ファームウェアアップデート済み、TurboPCなど付属ツールは使用しない)
    • GreenHouse GH-UFD3-32GF (32GB、USB3.0)
    • Mtron MSD6000（MSD-SATA6025-032-N-A、32GB、SATAのSSD）
      ＋SilverStone SST-TS02B（USB2.0、2.5インチ用のUSBケース）
このPCではUSB3.0のUSBメモリも必然的にUSB2.0接続になる。Windows To GoはUSB3.0推奨らしいので力不足ではあるが、WDPを内蔵SSD（X25-M G2 80GB）にインストールした状態ではさくさく普通に動作する。

先に、それぞれの速度をCrystalDiskMarkで確認しておく。なお、X61sはストレージ速度が遅いPCなので（前世代のX60sと比べても遅い）、他のPCならもっと速いと思われる。

まずRUF3-S32GS-BK。

テストサイズが1000MBのときの4Kランダムライトが極端に遅いのが分かる。

次にGH-UFD3-32GF。

これは1000MBでも4Kランダムライトがそれなりの値を維持している。なお、他の人のベンチマーク結果を見ると、このUSBメモリの値はこれよりかなり高い。

さらに比較用として、手持ちのUSB2.0のUSBメモリの中で最速のPicoBoost 8GB（以前の計測結果）。

1000MBでもそれほど遅くなっていない。これに比べるとRUF3-S32GS-BKの4Kランダムライトの遅さが際立つ。

最後にMSD6000によるUSB SSD。このMSD6000は最初期のSSDで、引退させていたのを探し出してきた。

当然といえば当然だが、ランダムライトはUSBメモリとは段違いに速い。

RUF3-S32GS-BKの場合


まず用意したのがRUF3-S32GS-BKで、これが順調に行っていればそこで終わりだったのだが。

作成は手順どおりにできたが、imagex.exeの実行には209分もかかった。

作成したUSBメモリからブートすると、インストールに長い時間がかかった後、WDPが起動した。起動後は、見た目は内蔵SSDから起動したときと変わらない。ページファイルを無効にした状態でUSBメモリの使用容量は約14GB。
（C:がWindows To GoのUSBメモリ）

ただし……起動と終了を何度か繰り返すうちにはっきりしたが、動作が極めて、極めて遅い。

起動時間（電源ボタンを押してからStart画面が出るまで）を内蔵SSDと比べると、
  • 内蔵SSD: 18秒
  • RUF3-S32GS-BKによるWindows To Go（初回ではない）: 8分25秒
起動時だけならまだしも、起動後も何か操作する度にしばらく待たされる。上のスクリーンショットも、このために起動し、デスクトップを開き、エクスプローラを開き、スクリーンをコピーし、ペイントに貼り付け、それを保存し、終了するまでに30分近くかかっている。とても実用にはならない。

GH-UFD3-32GFの場合


ここは実際の順番とは前後する。

Windows To Goが極めて遅いのはRUF3-S32GS-BKのランダムライトの遅さが原因という可能性があるので、改めてBUILD2011で配布されたUSBメモリを見ると、外観からKingstonのData Traveler Ultimate 3.0シリーズということが分かった。

このシリーズには第1世代（G1）と第2世代（G2）とがあって、G2の方がシーケンシャルリードでは速くなっているが、ランダムライトではG1の方が他のUSBメモリの中でも飛び抜けた速さを誇っている。これはG1が中身的にはUSB SSDに近いということがあると思う。

[参考]
AnandTech: Kingston DataTraveler Ultimate 3.0 & OCZ Enyo, Quick Look at Two USB 3.0 SSDs
DecryptedTech: Kingstons' Data Traveler Ultimate G2 hits 100+MB/s

Microsoftが配布したのがG1かG2かは分からないが、ランダムライトの速さからいえばG1の方が理想的ではある。が、生産終了品でうまく入手できなかったのと、G2もランダムライトは速い方なので、G2とほぼ同じコントローラを持ち、入手性も高いGH-UFD3-32GFに方向転換した次第。

GH-UFD3-32GFでWindows To Goを作成したところ、imagex.exeの所要時間は50分と、かなり短縮された。

作成したUSBメモリからブートしてのインストールもそれほど待たされることなく、WDPが起動した。動作は内蔵SSDに比べればややぎこちないが、普通に操作できる。起動時間も十分に許容範囲。
  • 内蔵SSD: 18秒
  • GH-UFD3-32GFによるWindows To Go: 46秒
が……なぜかIEがインターネットに接続できない（10秒ぐらいで自動終了する）。Firefoxでは接続できるので、OSは繋がっているのだが。IEだけでなく、IEの機能を内部的に利用しているであろう標準アプリ（Metroアプリを含めて）も接続不可。Windows Updateもかけられないので、打つ手なし。原因は不明だが、これも実質的に使えない。

なお、RUF3-S32GS-BKでは遅すぎてこの問題を確認するには至らなかった。

MSD6000（USB SSD）の場合


RUF3-S32GS-BKでは遅すぎて使い物にならないと判明した後、USB接続のストレージでランダムライトが速く、手持ちで試せるものとして浮かんだのがMSD6000をUSB接続にすること。

このUSB SSDでWindows To Goを作成すると、まずimagex.exeの所要時間が段違い。20分で終了した。

このUSB SSDからブートするとインストールもさくっと進み、WDPが起動。操作した感じも内蔵SSDと変わらない。起動時間もリーズナブル。
  • 内蔵SSD: 18秒
  • MSD6000によるWindows To Go: 32秒
ページファイルを無効にした状態でUSB SSDの使用容量は約14GBで、これは変わらない。種類はHDDになる。
（C:がWindows To GoのUSB SSD）

エクスペリエンスインデックスはこんなもの（上が内蔵SSD、下がUSB SSD）。

Primary hard diskは、内蔵SSDの7.2に対してUSB SSDは5.2なので、そんなに低くはない。

以上、USB SSDで作成したらさくさく動作するWindows To Goができた。

3. まとめ


Windows To Goの動作には、USBメモリのランダムライトの速度が重要。これはOSがその上で動作することを考えれば当然ではある。接続がUSB2.0かUSB3.0かは直接関係ないし、PCの性能もあまり関係ないが、USBメモリの速度はPC本体にかなり左右されるところがあるので、無関係とも言えない。

これはReadyBoostの条件と似ているが、最近の、とくに32GB超のUSBメモリではReadyBoost対応は重視されてないようなので、盲点ではある。高速なシーケンシャルアクセスを謳う製品でも、ランダムライトが遅ければWindows To Goには不適格。この点は、Windows 8がリリースされるときにはReadyBoostのような基準を作る必要があると思う。

とりあえず容量と速度を考えれば自分のようにSSDを再利用するのが手っ取り早いが、ランダムライトが遅くないUSBメモリを慎重に選ぶか、先々は、教えていただいたSuper TalentのUSB 3.0 Express RC8のような中身的にUSB SSDに近いものを使うのがいいと思う。ただし、IEの問題は残るかもしれない。

4. 注意点


Windows To Goの場合に限らないが、WDPの起動時に自動chkdskがかかった後、Windows 7で作成したパーティション（ファイルシステムはNTFS）がアクセス不能になったことが複数回あった。逆に、Windows 7で自動chkdskがかかった後、WDPのシステムパーティションがアクセス不能になったこともあった。

バックアップしておけばいいことだが、一応注意を要する。

[追記1]

Windows To Goの作成例。
並みのUSBメモリでは使い物にならないという点で一致。清水さんが「実用は厳しい」と評しているUSBメモリと、ぱすわさんが「一応使えるレベル」としたGreen HouseのPicoDrive Dual Xの速度は同程度のように見えるので、その辺が境界線になるのだろうと思う。

また、ぱすわさんの場合もIEが起動できないということなので、これは普遍的な問題らしい。

さらに、清水さんの記事を読んで、改めてBUILD2011での動画を見ると、デモで使われていたのはSuper TalentのRAIDDrive USB3.0だった模様（市場で入手できる現在最速の、8chでSuper Talentのドライブと言っている）。確かにこれなら速度的には別格だから、道理でという感じ。資料を見直しても「USB Drive」と書いていても「USB Stick」とは書いてないので、これを（並みの）USBメモリと捉えたのが、ある意味ミスリーディングだったようにも思う。

[追記2]

USB SSDでWindows To Goを使っていたところ、サスペンド、ハイバネーションともできないことが判明した。内蔵SSDから起動した場合には可能なので、Windows To Goの場合特有の問題だと思う。

なお、内蔵SSDから起動した場合も「Power」に「Sleep」の選択肢は出ないが、ThinkPad式のショートカットキー（Fn + F12）でハイバネーションに入り、電源キーでレジュームする。ただし、サスペンド（Fn ＋ F4）したときもハイバネーションに入る模様（非常に速いので実害はないが）。

[追記3]

Windows To Goの最終的な姿が明らかになったので、まとめを書いた。
投稿者: EMO 0 コメント
ラベル: , ,

2011/09/03

NAS Herder beta

Beta版ということで公開しました。外見的な変化はFan回転数の横にグラフを付けたぐらいです。

プロジェクトサイト: NAS Herder 英語 at SourceForge.net
実行ファイル from SourceForge.net

関連スレッド: Beta Tester Wanted (new Windows app for ReadyNAS)

[更新]

ボリューム使用率とUPS充電率のバー表示を変更しました。ボリューム使用率が90%を超えると赤に変わります。このvisual styleで色を自由に変えられるプログレスバーのサンプルコード。

標準のプログレスバーをこれに使っていたところ、Windows Developer Previewでは自動的にマーキーになってしまってましたが（本来のプログレスバーとしては間違ってはいない）、自分で作成したことで解決となりました。
投稿者: EMO 2 コメント
ラベル: , , ,

2011/08/24

NAS Herder 開発中

ReadyNAS用のWindowsアプリとしてNAS Herder（仮）を開発中です。

見て想像できるとおり、ReadyNASの起動・監視・終了をタスクトレイから行えるソフトです。監視にはNetGear純正のRAIDarと同じプロトコルを利用することができます（追記2にサンプルコードあり）。

起動・終了には基本的にこれ（遠隔から電源オン/オフ）と同じことをしていますが、この機能とWindowsの起動・終了・サスペンド・レジュームを絡めて電源同期ができるのが特徴かなと。

大体完成していますが、電源同期関係はまだテストが必要という状態です。VB.NETで開発するのも3本目なので、慣れてはきましたが、通信機能を4種類実装したり、それをマルチスレッド化したりで、内情的には色々あって……。前と違って季節ものではないので、急いではないのですが。

想定している使用環境は日本に限らないので、全部英語です。多言語化も難しくはないのですが、正直そこにあまり手間をかけたくないということもあり。まあ需要次第ということで。

[追記1] 参考

必ずしも直接参考にしたわけではないですが、先人への敬意を込めて。

[追記2] RAIDarプロトコルのサンプルコード

移動しました（RAIDar Protocol Sample）。

[追記3]

関連スレッド: ReadyNAS Remote Monitoring Tool?

[追記4]

Beta版を公開しました。
投稿者: EMO 4 コメント
ラベル: , , ,

2011/08/02

電気アラート（続）

電気アラートに関する続きです。

[追記] 新しい情報はSourceForge.jpのプロジェクトサイトにまとめています。

1. 電力会社の更新タイミング


電力会社（東京電力、東北電力、関西電力、九州電力）は5分ごとの使用量データを5分に1回更新していますが、タイムラグを短くしようとすると、この更新をどう追いかけるかが問題になります。

単純に力技でいいなら、より短い間隔でアクセスし続ければ更新を引っ掛けやすくなるわけですが、それはあまりうまくないと思うので、アクセスも5分に1回とすると、そのタイミングが重要になります。

ということで、電気アラートの動作検証と平行して、また自作ソフトで電力会社の更新タイミングを調べた結果が以下です。7/28～8/2の5日間、3秒間隔で更新をチェックしたものですが、ソフトの開発で中断していた時間も長いので、網羅的なものではありません（更新回数は1000回強）。

見てのとおり、東北電力と関西電力は鋭い山が1つだけで、更新タイミングはほぼ固定されています。

九州電力は3つの山ができていて、3つのタイミングがあることが分かります。ただ、どの順番でどのタイミングになるかという法則性は、元の更新時刻を見てもよく分かりませんでした。

で、東京電力は前半に低い山並みができてますが、これには理由があります。例として、7/31の19:00～21:00の更新時刻を挙げます。
東京電力の更新時刻（7/31 19:00～21:00）
CSVファイルが
更新された時刻
(日付 時:分:秒)		5分刻みの
時刻との差
(秒)		UPDATEに
記載された時刻
(日付 時:分)		新しく追加された
データの時刻
(日付 時:分)
2011/7/31 19:01:00602011/7/31 18:552011/7/31,18:55
2011/7/31 19:06:35952011/7/31 19:002011/7/31,19:00
2011/7/31 19:12:061262011/7/31 19:052011/7/31,19:05
2011/7/31 19:17:011212011/7/31 19:102011/7/31,19:10
2011/7/31 19:22:201402011/7/31 19:152011/7/31,19:15
2011/7/31 19:25:21212011/7/31 19:202011/7/31,19:20
2011/7/31 19:30:37372011/7/31 19:252011/7/31,19:25
2011/7/31 19:36:26862011/7/31 19:302011/7/31,19:30
2011/7/31 19:41:36962011/7/31 19:352011/7/31,19:35
2011/7/31 19:47:131332011/7/31 19:402011/7/31,19:40
2011/7/31 19:52:301502011/7/31 19:452011/7/31,19:45
2011/7/31 19:55:18182011/7/31 19:502011/7/31,19:45
2011/7/31 20:00:40402011/7/31 19:552011/7/31,19:55
2011/7/31 20:06:05652011/7/31 20:002011/7/31,20:00
2011/7/31 20:11:37972011/7/31 20:052011/7/31,20:05
2011/7/31 20:17:051252011/7/31 20:102011/7/31,20:10
2011/7/31 20:22:301502011/7/31 20:152011/7/31,20:15
2011/7/31 20:25:19192011/7/31 20:202011/7/31,20:20
2011/7/31 20:30:32322011/7/31 20:252011/7/31,20:25
2011/7/31 20:36:18782011/7/31 20:302011/7/31,20:30
2011/7/31 20:41:37972011/7/31 20:352011/7/31,20:35
2011/7/31 20:46:531132011/7/31 20:402011/7/31,20:40
2011/7/31 20:52:211412011/7/31 20:452011/7/31,20:45
2011/7/31 20:55:13132011/7/31 20:502011/7/31,20:50

更新タイミングは早い時刻から始まって、1回の更新ごとに20～30秒遅れていき、これを5～6回繰り返した後に元に戻るというパターンになっています。かつ、それぞればらつきが大きいので、集計してみると低い山の連続になるというわけです。

また、東北電力、関西電力、九州電力のそれぞれの山の中に谷がありますが、これも理由があって、大まかに休日と平日の差によるものです。

以下は電気アラートのコマンドラインオプションを使って「内部時刻」と「更新状況」を表示させたものです。この「更新状況」は上で使ったソフトのサブセットで、30分間、3秒間隔で更新をチェックします。

これは7/31のものですが、更新タイミング（表中の「差」の列）は大体124秒です。これが8/2になると、

更新タイミングは大体140秒になります。つまり平日は休日より遅くなるわけで、同じ傾向は関西電力、九州電力にも見られ、平日は10～20秒遅くなります。

2. 電気アラートでの対応


以上を考慮して、電気アラートではアップデートのためにアクセスするタイミングを、電力会社ごとのプリセット値として持っています（Ver.0.8.0）。

東北電力の例では、上の7/31の時点では140秒＝2分20秒としていて、これは「内部時刻」の「アップデート」の「次回」時刻に反映されています。が、平日は遅くなることが分かったので、下の8/2の時点では150秒＝2分30秒に変更しています。

この場合、23:07:17に更新されたデータを23:07:30にアクセスして見に行こうとしている直前で、データの時刻から電気アラートに反映されるまでのタイムラグは2分30秒ということになります。まあ、これほどタイムラグを短くできるのは、データが出てくるのが速く、更新タイミングが安定している東北電力ならではですが。

一方、この更新タイミングがずっと同じかは不明なので、タイムラグがどうも長い……というときは、「更新状況」で更新タイミングを確かめた上で（その間のアクセスが増えるのは目を瞑ってもらうとして）、コマンドラインオプションでアップデートのタイミングを指定することで調整できます。
投稿者: EMO 0 コメント
ラベル: ,

2011/07/19

Intel SSDのE2/E3/E4

Intelの天野氏の置き土産について、自分でもよく分かってないが、とりあえず書き留めておく。

1. Endurance Monitoring #2


6/4に天野氏が最後のイベント出演をしたとき、Intel SSDの寿命予測に関してE9、あるいはHost Writesとはまた別の方法を説明していた。これが詳しく出ている記事（インテル天野氏が最後のイベント出演、Z68とSSDを語る）を見ると、これまで明らかでなかったSMARTのE2、E3、E4の意味が出てくる。

天野氏の資料によれば、
#2: Intel Timed Media Wear metric
- Allows user or system designer to evaluate the endurance wear rate for a proposed application through following SMART attributes
E2h/226 (Timed Workload Media Wear Indicator)
E3h/227 (Timed Workload Host Reads Percentage)
E4h/228 (Timed Workload Timer)

これは現在あるSSDの残り寿命がどれだけあるかを見るというより、ある負荷を与えたときにどれぐらい消耗するかを見るもののようで、
SMARTMON* tool can be used to report all SMART attributes using the following steps
- At command prompt, enter the following to list attributes:
smartctl -a /dev/hdx
- Before using a workload, enter the following to reset the E2, E3 and E4 attributes:
smartctl -t vendor,0x40 -a /dev/hdx
This issues a SMART EXECUTE OFFLINE IMMEDIATE SUBCOMMAND 0x40
- Run your workload for at least 60 minutes（できれば2時間）
- Power-cycle the system（電源を入れなおし）
- Re-enter this command to get the new values for E2, E3, and E4:
smartctl -a /dev/hdx
（注）丸括弧内は、元はIntel内部の資料だったものに天野氏が書き加えたものっぽい。

この「smartctl -a /dev/hdx」はドライブの情報を見るコマンドなので、まずこれでチェックした後で、「smartctl -t vendor,0x40 -a /dev/hdx」でE2、E3、E4をリセットし（たぶん0になる）、負荷を与えて再起動した後、再度「smartctl -a /dev/hdx」で変化を見ろ、という話（注）らしい。

（注）記事のキャプションでは少し違うことが書いてあるが、どうも分かってない感じがするので、資料の記述だけを信じる。

例として、E2が22、E3が99、E4が981のときは以下のようになる。
% Media Wearout during this run = 22(E2) /1024 = 0.021%
Work Ratio = 99(E3) % Read/Write
Workload Timer = 981(E4) mins
Lifetime using this specific workload 100% of the time 24/7 = 8.9 Years

981分間の消耗率が0.021%ということから計算して（この負荷だけをかけ続けた場合の）寿命は8.9年になるとのこと。一応計算してみると、

{100 ÷ [22/1024 ÷ 981](分当たりの消耗率(%))}(全消耗にかかる分数) ÷ {60 × 24 × 365}(年間の分数) ≒ 8.687422167(全消耗にかかる年数)

……。数字が合わないが、22/1024 ≒ 0.021484375を0.021に切り下げてから計算すると、

{100 ÷ [0.021 ÷ 981](分当たりの消耗率(%))}(全消耗にかかる分数) ÷ {60 × 24 × 365}(年間の分数) ≒ 8.887801696(全消耗にかかる年数)

合った。

いずれにせよ、E3はこの計算には入ってこない。「書き込みの割合が増えると耐久性は一気に下がる」というのは、E3が下がる＝書き込みの割合が上がる負荷のときは、逆にE2は上がるという逆相関関係の意味だろうか。

2. 実験


さて、手元のX25-M G2 80GBで試してみる。コマンドプロンプトを管理者として開き、smartmontoolsで「smartctl -t vendor,0x40 -a /dev/sda」を実行（「smartctl -a /dev/sda」で表示されるものも全て入っている）。

このSMARTの部分は、226(E2)、227(E3)、228(E4)とも65535になっている。ATTRIBUTE_NAMEは、天野氏の資料ではHDDと同じだったが、この最新版（5.41-1）ではIntel SSDに対応しているようで、資料とほぼ同じ名前が短縮されたものになっている。

これはsmartmontoolsのデータベースであるdrivedb.hにあるもので、この中を見るとIntelの情報は伝わっていることが分かる。
"-v 226,raw48,Workld_Media_Wear_Indic " // Timed Workload Media Wear Indicator (percent*1024)
"-v 227,raw48,Workld_Host_Reads_Perc "  // Timed Workload Host Reads Percentage
"-v 228,raw48,Workload_Minutes " // 226,227,228 can be reset by 'smartctl -t vendor,0x40'

最後の部分では、「SMART EXECUTE OFF-LINE IMMEDIATE subcommand 0x40」に成功しているように見える。

が、この後再起動しようと何をしようと65535の数字は全く変わらなかった。このThinkPad X61s上のWindows 7 64bitのSATAのドライバをMicrosoftの標準ドライバ（6.1.7601.17514）とIntelのドライバ（10.1.0.1008）の間で変えたり、PATA（Compatibilityモード）に設定したりしても、効果なし。

念のため、CrystalDiskInfo（4.0.2a）で見た場合はこうなる。

E2、E3、E4はともにFFFFで、この16進数を10進数にすれば65535になるので、smartmontoolsと同じ（見ているデータが同じなのだから当然だが）。

あえて推測すれば、この4桁の16進数はどれも既に上限に達しているので、もう変わりようがない、ということではないかと……。これをリセットできない以上、先に進みようがない。

ということで、よく分からないまま終わる。

[追記1]

320シリーズのProduct Specificationの追補（Intel Solid-State Drive 320 Series Enterprise Server/Storage Application Product Specification Addendum）にはE2、E3、E4の説明があったので、320シリーズだけで有効なのかもしれない。

また、その説明によれば、値がFFFFなのは標準値（normalized value）ではそうなっているというだけらしい。

[追記2]

CrystalDiskInfo（4.1.0）からE2、E3、E4の名前に対応されているので補完。

日本語表記もばっちり。それぞれの詳細な意味は320シリーズの追補を読んでもらうということで。
投稿者: EMO 0 コメント
ラベル: ,

2011/07/17

マウス三台

クリックボタンがおかしくなったVX-Nanoの交換機としてM905が来たので、Logicoolマウスを比較してみる。右がM905、左がVX-Nano、奥がM555b。

1. 重量


M905を空の状態で持ち上げると、VX-Nanoに慣れた手には重さを感じた。重量を電池を入れた状態で比較すると、以下のようになる。
本体
(レシーバー、
電池抜き)(g)		本体＋
単4×1
(g)		本体＋
単4×2
(g)		本体＋
単3×1
(g)		本体＋
単3×2
(g)
M9058499114111136
VX-Nano73-95--
V550 Nano69-97-117
M555b68-96-116
（注）単4はアダプターを含む（VX-Nanoを除く）。計測したときの電池のブランドが違うので、電池の重量にズレがある。

M905はマウス単体で他より11～18g重いので、単3×2のフル状態だと結構ずっしり来る。ただ、他と違って1本でも動作するので、最軽量の単4×1の状態であれば99gと、他の最軽量状態とさほど変わらない。その分、電池寿命は短くなるわけだが、自分はeneloopを使っているので、そこは問題ではなかった。

1本だけではバランスがどうなるか気になったが、単4であれば左右どちらでもさほど違いは感じない。自分は右手で使うので親指に近い左側に1本入れた状態にすると、ほとんど違和感はなかった。

[追記]

単4×1（eneloopの750mAhのほぼ新品を満充電状態から）で使っていたところ、5日目で電池切れとなった。さすがにこれは早い。充電池だからまあいいが、乾電池では奨められない方法ではある。

2. スイッチ


裏側にはスイッチ兼用のシャッターがあるが、これが小気味よく動くので、バッテリーの蓋を外して裏返してみると、

くるくる平たく巻いたバネが入っていた。このバネがシャッターのスライドで動く。

バネの一方の端が蓋側のピンに、もう一方がシャッター側のピンに固定され、開閉それぞれの位置で止めるようになっている。もっと安上がりに済ませる方法もあるだろうに、この薄いスペースにこういう細かい機構を組み込んであるのが面白い。
投稿者: EMO 0 コメント
ラベル:

2011/07/16

電気アラート

自作ソフトの紹介です。機能としてはとくに目新しいものではありませんが、シンプルにまとめました。

[追記] 新しい情報はSourceForge.jpのプロジェクトサイトにまとめています。

1. 概要


電力の使用状況データを公開している電力会社（東京電力、東北電力、中部電力、関西電力、九州電力）から一定間隔でデータをダウンロードし、その日のピーク時供給量、最新の使用量を見て、最新の使用率とその動きをタスクトレイから色と数字で知らせます。使用率が高くなっている場合はアラートを出します。

タスクトレイにアイコンが出ます。この数字が使用率で、どれぐらい高いかをこの色で直感的に示します。マウスオーバーすると最新の数字と上下動をチェックできます。

色は以下のカラーチャートに従っています。赤くなってきたら使用率が高くなっています。

アップデートしたときに使用率の閾値を超えている場合は、設定に従って音とバルーンメッセージによるアラートを出します。

アラート音として任意のWAVファイルを再生できます。説明を兼ねてフリーのWAVファイルを同梱していますが、これには、Free音素材「音楽室」（http://www.otosozai.com）のva01.wavを使わせていただいてます。

2. 動作環境


Windows XP、Windows 7で動作します。.NET Framework 4.0がインストールされていることが必要です。

3. ダウンロード


以下からダウンロードできます。
4. その他
  • このソフトはオープンソースです。使用条件については同梱のlicense.txtをご覧ください。

  • Visual Basic 2010 Expressで開発しています。単体で動作するWindowsアプリとしては初なもので、ソースは推して知るべしです。「動けば正義」的な。だからこそ、ソースを公開することにためらいがないということもありますが……。

  • 電力会社が公開しているデータファイル（CSVファイル）は、どこも最初に出した東京電力のものがベースになっているので、共通の部分が多いです。TPTPコネクトでは、ピークタイムを取得するアルゴリズムは全部同じで済んでいます。

    ただ、似たような形式でも意味が微妙に違っていたり、データが更新される速さに差があったりします。東京電力を基準とすると、東北電力は同じぐらい。九州電力は公開を開始したのは一番遅かったですが、かなり頑張っています。関西電力も頑張っていますが、更新が少し遅いです。残る中部電力はまだ1時間ごとのデータしか出していない分、遅れていると言わざるを得ません。
[追記1] 電力会社の更新タイミング

関西電力は3分ごとのデータを公開していますが、更新間隔はこれと少しずれていて、かつ遅れ気味ということを見つけたので、自作ソフトを使ってデータを取得してみました。
関西電力の更新時刻
CSVファイルが
更新された時刻
(日付 時:分:秒)		UPDATEに
記載された時刻
(日付 時:分)		新しく追加された
データの時刻
(日付 時:分)		更新された
時刻との差
(分:秒)
2011/7/18 3:00:152011/7/18 2:552011/7/18 2:4218:15
2011/7/18 2:4515:15
2011/7/18 3:05:052011/7/18 3:00--
2011/7/18 3:10:072011/7/18 3:052011/7/18 2:4822:07
2011/7/18 2:5119:07
2011/7/18 3:15:072011/7/18 3:102011/7/18 2:5421:07
2011/7/18 2:5718:07
2011/7/18 3:20:042011/7/18 3:152011/7/18 3:0020:04
2011/7/18 3:0317:04
2011/7/18 3:25:082011/7/18 3:202011/7/18 3:0619:08
2011/7/18 3:0916:08
2011/7/18 3:30:142011/7/18 3:252011/7/18 3:1218:14
2011/7/18 3:1515:14
2011/7/18 3:35:062011/7/18 3:30--
2011/7/18 3:40:062011/7/18 3:352011/7/18 3:1822:06
2011/7/18 3:2119:06
2011/7/18 3:45:082011/7/18 3:402011/7/18 3:2421:08
2011/7/18 3:2718:08
2011/7/18 3:50:062011/7/18 3:452011/7/18 3:3020:06
2011/7/18 3:3317:06
2011/7/18 3:55:052011/7/18 3:502011/7/18 3:3619:05
2011/7/18 3:3916:05
2011/7/18 4:00:092011/7/18 3:552011/7/18 3:4218:09
2011/7/18 3:4515:09
2011/7/18 4:05:052011/7/18 4:00--
2011/7/18 4:10:052011/7/18 4:052011/7/18 3:4822:05
2011/7/18 3:5119:05
2011/7/18 4:15:052011/7/18 4:102011/7/18 3:5421:05
2011/7/18 3:5718:05
2011/7/18 4:20:052011/7/18 4:15--
2011/7/18 4:25:052011/7/18 4:202011/7/18 4:0025:05
2011/7/18 4:0322:05
2011/7/18 4:30:142011/7/18 4:252011/7/18 4:0624:14
2011/7/18 4:0921:14
2011/7/18 4:1218:14
2011/7/18 4:1515:14
（注）2秒間隔で更新をチェックし、更新があればデータを記録していく方式。「CSVファイルが更新された時刻」は自作ソフトを実行中のPCのものなので、誤差があり得る（以下同じ）。

見てのとおり更新時刻の間隔は5分で、UPDATEに記載された時刻の5分後になっています。データは3分ごとなので当然ずれていくわけですが、5分の更新で3分×2のデータを追加するのを基本として、詰まってくるとスキップするようです。

ただ、法則性があまりはっきりしないのと、データが細かい割に更新時刻とのタイムラグがおよそ15～24分と、結構あるのがちぐはぐで、謎仕様です。

他の東京電力、東北電力、九州電力はというと、データもUPDATEに記載された時刻、更新時刻も5分ごとなので、ずれることはありません。東京電力の場合は、
東京電力の更新時刻
CSVファイルが
更新された時刻
(日付 時:分:秒)		5分刻みの
時刻との差
(分:秒)		UPDATEに
記載された時刻
(日付 時:分)		新しく追加された
データの時刻
(日付 時:分)		更新された
時刻との差
(分:秒)
2011/7/18 10:45:550:552011/7/18 10:402011/7/18 10:405:55
2011/7/18 10:51:251:252011/7/18 10:452011/7/18 10:456:25
2011/7/18 10:56:471:472011/7/18 10:502011/7/18 10:506:47
2011/7/18 11:02:132:132011/7/18 10:552011/7/18 10:557:13
2011/7/18 11:08:073:072011/7/18 11:002011/7/18 11:008:07
2011/7/18 11:10:500:502011/7/18 11:052011/7/18 11:055:50

データと更新時刻のタイムラグは5～8分です。

これは東北電力と九州電力と照らし合わせると、データの時刻の表記方法がこれらとは違っていて、5分ずれているかもしれません。例えば10:45のデータは10:40～10:45の5分間ではなく、10:45～10:50の5分間を示すというように。ただ、それにしては早すぎる場合もあるので（差が1桁のときもある）、不明です……。

また、「5分刻みの時刻との差」というのは5分、10分、15分…という5の倍数の時刻との差で、自動アップデートのタイミングを決める参考になります。これは大体2分以内に収まっています。

東北電力の場合は、
東北電力の更新時刻
CSVファイルが
更新された時刻
(日付 時:分:秒)		5分刻みの
時刻との差
(分:秒)		UPDATEに
記載された時刻
(日付 時:分)		新しく追加された
データの時刻
(日付 時:分)		更新された
時刻との差
(分:秒)
2011/7/18 11:12:142:142011/7/18 11:122011/7/18 11:102:14
2011/7/18 11:17:142:142011/7/18 11:172011/7/18 11:152:14
2011/7/18 11:22:132:132011/7/18 11:222011/7/18 11:202:13
2011/7/18 11:27:152:152011/7/18 11:272011/7/18 11:252:15
2011/7/18 11:32:132:132011/7/18 11:322011/7/18 11:302:13
2011/7/18 11:37:152:152011/7/18 11:372011/7/18 11:352:15

規則正しく2分14秒ごとに更新しています。タイムラグも同じく2分14秒です。とても優秀です。

九州電力の場合は、
九州電力の更新時刻
CSVファイルが
更新された時刻
(日付 時:分:秒)		5分刻みの
時刻との差
(分:秒)		UPDATEに
記載された時刻
(日付 時:分)		新しく追加された
データの時刻
(日付 時:分)		更新された
時刻との差
(分:秒)
2011/7/18 11:38:203:202011/7/18 11:352011/7/18 11:353:20
2011/7/18 11:43:203:202011/7/18 11:402011/7/18 11:403:20
2011/7/18 11:47:202:202011/7/18 11:452011/7/18 11:452:20
2011/7/18 11:53:203:202011/7/18 11:502011/7/18 11:503:20
2011/7/18 11:57:202:202011/7/18 11:552011/7/18 11:552:20
2011/7/18 12:02:192:192011/7/18 12:002011/7/18 12:002:19

こちらも2分20秒か、3分20秒ごとに更新しています。タイムラグも同じ時間で、東北電力に次ぎます。

以上のようなことを考慮に入れて、電気アラートでは、5分刻みの時刻に2分30秒を加えた時刻（7分30秒、12分30秒、17分30秒……）に自動アップデートを行うようにしています（ただし、時間の経過とともに少しずれていきます）。

電力会社ごとに細かく合わせるように変更しました（電気アラート（続）参照）。

[追記2] 日またぎ時の再開時刻

深夜0時に日付が変わった後、電力会社のデータは更新がしばらく途切れます。もちろん、この時間帯に途切れても実用上は何の問題もありませんが……。

とにかく、正常なデータの更新が再開する時刻を同じく自作ソフトで調べてみたのが以下です。
東京電力
(時:分:秒)		東北電力
(時:分:秒)		関西電力
(時:分:秒)		九州電力
(時:分:秒)
2011/7/211:05:531:02:081:19:570:08:14
2011/7/221:07:401:02:171:20:070:08:42
  • 東京電力と東北電力は、その日の1回目の更新で前日のデータを全部出した後、更新が止まり、1時過ぎに0時台の1時間のデータとともに、5分ごとのデータの更新が再開します。これも一つの割り切りだとは思います。

  • 関西電力は、更新は止まらないのですが、中身は前日のデータという状態が続き、中身もその日のデータに切り替わるのは1時20分頃です。止まらないのはいいのですが、あまり行けてない感じがします。

  • 九州電力は、1回だけ更新がスキップしますが、その日の2回目のタイミングから更新が再開します。圧倒的に早いです。まあ九州電力は1時間ごとのデータを出してないので、そこが他とは違いますが。
以上のように、九州電力を除いて、0～1時頃の間は正常なデータがリアルタイムで出ていません（その間のデータは再開した時点でまとめて出ます）。電気アラートでは、正常でないデータはスルーするようにしているので、再開するまで前日のデータが表示されたままになります。実用上は問題ないと思いますが、念のため。
投稿者: EMO 0 コメント
ラベル: ,

2011/07/01

東京電力の電力状況

いよいよ夏到来の7月ということで、東京電力の地域の電力状況について中間まとめをしてみる。

初めに、使用率という数字はYahoo!などが（たぶん一目で分かるように）東京電力のデータを加工して出しているだけで、東京電力自身が積極的に出しているものではないので、念のため。自分はTPTPコネクトで計算してバッテリ駆動時間の閾値に使っているが。

1. 電力使用率とピークタイム


3/23から6/30までの電力使用率とピークタイムを一覧にしてみた。赤みが強いほど使用率が高い。なお、前回は速報値で計算したが、今回は確定値で計算したので、5/7までの数字でずれている部分がある。
使用率はゴールデンウィーク明けの5/9の週に高くなってからは低い状況が続いてきたが、6/20の週にぐぐっと上がり、週末を挟んでまた上がってきている。

ピークタイムに関しては、東京電力による予想の的中率はあまり高くないが、数字的には僅差だったりすることが多いので、それほど外れているわけでもない。

一方、ピーク使用量も見れば分かるとおり、使用率と使用量は単純な比例関係にはない（使用率の高い日が使用量も高い日とは限らない）。これは母数の「ピーク時供給力」も日ごとに変動しているからで、使用率を理解するにはこの間の関係を見る必要がある。

2. 電力使用量と「ピーク時供給力」


まず3/23から5/11までについて、電力使用量と「ピーク時供給力」、さらに都心部の最高気温（気象庁のデータによる）の推移を見ると、
ピーク使用量が「ピーク時供給力」に近づくほど使用率は高くなるが、3月の切迫した状況を脱した後、4月に入ってからは一部の高い日を除いて余裕がある。

基本的に使用量は平日に高く、週末に低くなるが、東京電力はそうした需要を予想して「ピーク時供給力」を調整しているらしい（発電施設の整備点検のやり繰りがあるだろうし、需要がないのに高くしておく理由もない）ことが見て取れる。

また、使用率が特に高い日を見てみると、
  • 4/4に90%を超えたのは、週初めの需要を甘く見ていた（翌日から供給力を上げたこともあり、使用率は下がっている）
  • 4/23に90%を超えたのは、週末だから需要が下がると予想したら、意外に下がらなかった
  • 4/29と5/6に90%を越えたのは、需要が落ちるゴールデンウィーク直前と狭間だったにもかかわらず、需要がそれほど落ちなかった
からと推測できる。つまり、使用率が高くなったのは、供給力の制約というより、東京電力の予想よりかは需要があったからという方が正しいように思う。どうもこの点を誤解している人が多い気がする。もちろん、その日にスタンバイしている供給力の上限に近づいているという意味では切迫しているわけだが。

続いて5/12から6/30までを見ると、
5/9の週は「ピーク時供給力」が低めだったので使用率が高くなっているが、それ以降は東京電力が供給力を上げたにもかかわらず需要は横這いだったので、使用率は低い状況が続いていた。

その間にも6/6の週、6/13の週と、東京電力は供給力をじわじわ上げて用意してきていて（過去の実績によるものか）、6/20の週に一気に引き上げた。その週の半ばに気温の上昇とともに使用量が大きく伸び、久しぶりに90%を超えたわけだが、それを予想して東京電力は待ち構えていたことが分かる。

その後、東京電力は週末を挟んでさらに供給力を引き上げて対応している。

3. 今後


7月1日の東京電力のプレスリリース（今夏の需給見通しと対策について（第４報））によれば、この夏は大体5500万kWが供給力の上限となるらしい。既に「ピーク時供給力」は5000万kWを超え、これまでは余裕のあった東京電力も、いよいよ本気を出さないといけなくなりつつある。これまでは使用率といっても、それ自体に深い意味はなかったが、今後は本当に供給力との戦いの意味を持つようになってくるのだろう。

一方、6/29は都心部の最高気温が35度に達する中で、使用量は（7月からの電力使用制限が始まる前にして）4570万kWに留まっている。この気温と使用量の関係について、早野東大教授は「（参考出品）TEPCO最大電力と東京の最高気温の関係」で、これまでの実績では最高気温1度上昇につき使用量が約135±17万kWの上昇になっていることを示している。

今後もこの相関関係が続くなら、最高気温が40度に達しても使用量は5300万kWぐらいに留まる計算になるので、このまま波乱がなければ凌げそうにも思う。ただ、さすがに気温が30度台後半になると、我慢とか工夫とかで何とかなる世界ではなくなるのでクーラーを使う人が増えるかもしれず、使用量が急上昇するかもしれない。

いずれにしても、今年の夏は「忘れらない夏」になりそうではある。
投稿者: EMO 0 コメント
ラベル:

2011/05/20

Netgearの省電力ハブ

手近な機器の消費電力を測ったときに気になっていた、Buffaloの古いGbEハブ（LSW-GT-5W）をNetgearのGS105v3（ProSafe 5-port Gigabit Desktop Switch）に更新した。
Netgear GS105v3

これにしたのはコンパクトで真四角な金属筐体というのが最大の理由で、消費電力については最大3.2Wというぐらいしか情報がなかった。

今時のハブにはたいてい省電力機能があって、例えばBuffaloのLSW3-GT-5NSでは不使用ポートの電力オフとケーブルの長さに応じた電力カットを謳っているが、GS105v3の場合は詳しい説明がない。一応、外箱には「Auto power-down mode saves energy when port is unused」との記述があるので、不使用ポートの電力オフ機能があることは分かるが。

そこでワットモニターで消費電力を測ってみたのが以下。
リンク
速度		使用
ポート数		消費電力
(W)
電源オンのみ01.1
ADSLルーターを接続100M11.2
ThinkPad X61sを接続1000M21.7
ReadyNAS Ultra 2を接続1000M32.2
ThinkPad X60sを接続1000M42.7
ReadyNAS Duoを接続1000M53.2

ワットモニターの誤差もあり得るが、
  • 基本は1.1W
  • 使用ポートが増えるにつれ、大体0.5Wずつ増えていく
  • 公称の最大3.2Wというのは正確
ということが分かる。なお、5ポートに接続した状態で全ポートをビジーにしてみたが（X61sでYouTubeの動画を見つつ、Ultra2上の動画ファイルを再生し、かつDuo上の動画ファイルをX60sで再生）、消費電力に変化はなかった。使用状況で何か変わるかと思ったが、そうでもないらしい。

結果としては、消費電力を公表しているLSW3-GT-5NSより、いずれの状態でも消費電力は小さく、十分な省電力性が確保されていると思う。

問題ではないが、気づいたこともあって、それはLEDの光が強いこと。
Netgear GS105v3

下のLSW-GT-5Wの電源LEDがぼうっと点いているのに比べて、GS105v3のLEDは眩しく光っている。5つのポートを全部使用すると最大11個のLED（電源＋1000Mの場合の各ポート2×5）が点灯する。ハブなので別にいいのだが、結構派手ではある。
投稿者: EMO 0 コメント
ラベル: ,

2011/05/08

東京電力のピークタイム

TPTPコネクトの開発が一段落したので（TPTPコネクト自体の関係はSourceForgeの方で）、そもそも東京電力のピークタイムはどうなっているのか？について、改めて東京電力電力供給状況APIからスクリプトでデータを取得してまとめてみた。

大体3/26を境目に、それまで毎日のように計画停電が打たれていたのが、気温の上昇と発電能力の一部回復で需給が緩和されていき、現在に至っている。

なお、電力使用率の高い日が特別逼迫しているというより、需給予想に従って東京電力が発電能力を増減させているので、東京電力の予想よりは使用量が高かった日と見た方がいいと思う。

例えば、4/19は4月に入ってから使用量が一番高かった日だが、使用率には比較的余裕がある。これに対して、4/23は使用量はさほどでもないのに使用率は高くなっている。2日前の5/06の使用率が高いのも、連休の狭間にしては使用量が高かったということではないかと思う。

ともあれ、ピークシフト的には、
  1. どの情報からピークタイムを得ればいいのか？
  2. （バッテリ駆動がそれなりに長く可能として）バッテリ駆動時間をどのように配分すればいいのか？
ということが問題になるが、
  1. 東京電力の予想するピークタイム（ピーク時供給力の時間帯。グラフに横棒が引っ張ってある部分）は、時々外すが、最近では概ね安定している。
  2. 平日の日中は使用率が僅差で高止まりしているので（12時台に少し落ちる以外）、どの時間帯にバッテリ駆動すればいいのかは簡単には決め難い。
えいやっと決め打ちでもいいのだが、どうせやるならうまくピークタイムと使用率の高い時間帯に合わせられた方がいいよね、ということでTPTPコネクトの出番となるわけだが、さて。
投稿者: EMO 0 コメント
ラベル:

2011/04/08

ReadyNASとは何か

ReadyNASを普通に使っている限りは全く気にする必要はないが、何か問題が起きたりしたときに、そもそもReadyNASの中はどうなってるのかということに興味が湧くのは自然だと思うので、その流れの話。

（このエントリは一続きのエントリの5/5）

4.1. ReadyNASの構成（推測）


ReadyNASが何かといえば、LinuxをOSとして稼働する/RAID構成で/NAS専用のPC、ということになる。アプライアンスのLinux機としては普通のPCに近いが、普通のPCと特に違うのは、
  • オンボードにOSのインストールイメージを持っていること
  • ブートプロセスが少し変わっていること
ただ、Netgearの人はこういう話をあまり正面から書いてくれてない。あくまでアプライアンスであってユーザーの心配することではないし、SSHでログインすれば分かる人には分かるだろう、と説明の必要を感じてないのかもしれない。したがって、自分の推測がかなり入っているし、自分はLinuxに特に詳しいわけでも何でもないので、その前提で。

本当にトラブルに陥って回復作業をしなければいけないときは、素直にNetgearのサポートに頼った方がいい。

先に用語について。ReadyNASでは、そのファームウェア＝専用にカスタマイズされたLinux＝OSのことをRAIDiatorと呼んでいる。よく似た名前でRAIDarもあるが、こちらはクライアントPCからネットワーク上のReadyNASをモニターするためのソフト。何でこんなややこしい名前にしたのか知らないが。

いきなりだが、ReadyNASの構成とRAIDiatorのアップデート/回復の関係を整理。
場所Duo
(Sparc)
(X-RAID)		Ultra 2
(x86)
(X-RAID2)		RAIDiatorのアップデート/回復の影響
Frontview
/USBメモリ
からの
アップデート
(注1)		OS
Reinstall
(注3)		Factory
default
(注4)
BIOSオン
ボード		NAND
Flash
(64MB)		Flash ROM
(2MB)


Linux
カーネル		NAND
Flash
(128MB)		書き換え
Linux
インストール
イメージ
(RAIDiator
ファイル)
OS (Linux
ユーザー
ランド)
(RAIDiator)		HDD
(2台
とも)		2GB
(初期に
約350MB
を使用)		4GiB
(初期に
約370MB
を使用)		書き換え
(注2)		OSをNAND
Flashから
インストール		パーティション
を作成し直して
（ユーザーデー
タは消える）、
OSをNAND
Flashから
インストール
スワップ256MB512MiB
ユーザー
データ		残り残り
DRAM
メモリ		SO-
DIMM		DDR-
SDRAM
(初期は
256MB)		DDR3-
SDRAM
(初期は
1GB)
（注1）USBメモリからのアップデートを確認したのはUltra 2のみ。
（注2）既にインストールされているバージョンと同じ場合は書き換えない。
（注3）何かの事情でNAND FlashとHDDのRAIDiatorのバージョンが違う状態になった場合、自動的にOS Reinstallが行われる。ただし、これがうまく行かず、起動できない状態になることもあり、そのときは手動でOS Reinstallが必要。
（注4）そのReadyNASで稼働する状態になったHDD以外を入れた場合、自動的にFactory defaultが行われる。ただし、これがうまく行かず、起動できない状態になることもあり、そのときは手動でFactory defaultが必要。なお、同じ機種同士であればそのままのHDDで稼働する模様。

4.2. アップデート/回復手段


なぜこう言えるのかはひとまず置いて、具体的な方法について説明すると、

Frontviewからのアップデート


基本簡単。ただし、古いバージョンに戻せない制限付きのことがあるので、リリースノートに注意。

USBメモリからのアップデート


ReadyNASがまともに起動せず、Frontviewが使えない場合や、Frontviewからは古いバージョンに戻せない制限がある場合でも可能だったりする。

以下はUltra 2（x86）の場合の方法。

[参考] 非公式だが、公式FAQからリンクされている方法
Unofficial ReadyNAS USB Recovery Guide for x86-based Systems

  1. ReadyNAS_x86_USB_Flash_Recovery-4.2.12.zipをダウンロードする。これを展開してusbrecovery.exe（NETGEAR USB Recovery Utility）を実行すればUSBメモリが作成される。

    なお、このユーティリティの実行にはVisual C++ 2005 SP1 Redistributable (x86)が必要。また、これにはRAIDiatorファイル（4.2.12）が同梱されているが、同じフォルダに新しいRAIDiatorファイルをコピーすれば、実行時にそれを選ぶことができる。

  2. このUSBメモリを前面のUSB3.0ポートに挿し、backupボタンを押した状態で電源ボタンを押して離す。電源が入って自動的にUSBメモリにアクセスが行われ、2分ぐらいで自動的に電源が落ちる（ここまでbackupボタンは押したまま）。

  3. USBメモリを抜き、普通に電源を入れると、アップデート作業が行われて起動する。
ちなみに、自分のDuoではUSBメモリによるアップデートに成功したことは、相当粘ってみたが一度もない。どこかに問題があるのだと思う。一方、DuoにはPCと直結してTFTPでアップデートする方法があるが、Ultra 2でも同様の方法があるのかは不明。

OS Reinstall


HDDにあるOSをNAND Flashにあるインストールイメージを使って書き換えるもの。ユーザーデータには触らないので、ユーザーデータが失われることはない。

ただし、これを開始する操作はFactory defaultにごく近いので、一歩間違えるとFactory defaultになってユーザーデータは失われる。もし誤ってFactory defaultが開始されかけたときは、電源ケーブルを引き抜いてでも止めなければいけない。

以下はUltra 2（x86）の場合にOS Reinstallを開始する方法。

[参考] 日本公式サイトにある説明
ReadyNAS Ultra2 ： RAIDiator (ReadyNAS OS) の再インストール

  1. 後面のResetスイッチをピンで押した状態で電源ボタンを押して離す（Resetスイッチは押したまま）。Act以外のLEDが全部点灯したらResetスイッチを離す。

  2. これで管理用のブートメニューに入ったので、backupボタンを3回押し、HDD2のLEDだけが点灯した状態（OS Reinstallが選択された状態）にする。ここで後面のResetスイッチを押すと、選択が確定され、OS Reinstallが開始される。
ちなみに、このブートメニューとLEDの関係は以下のようなもの（Readynas Ultra 2 how to resets etc...）。
電源HDD 1HDD 2backup
(USB)
ブートメニュー開始●●●●
1回目Normal●---
2回目Factory default-●--
3回目OS Reinstall--●-
4回目Tech Support---●
5回目Skip Vol Check●●--
6回目Memory Test●-●-
7回目Test Disk●--●
（注）Actは関係ない。

なお、OS Reinstallの後も一部の設定は残ってたりするので、OSのパーティションをフォーマットしてからインストールするのではなく、上書きインストールをする模様。

Factory default


最も根本的かつ破壊的な手段で、HDDをチェックした後、全てのパーティションを作成し直した上で（ユーザーデータは消える）、OSをNAND Flashにあるインストールイメージからインストールするもの。

なお、工場出荷時の状態にリセットするといっても、RAIDiatorをアップデートしたことがあれば、NAND Flashのインストールイメージも書き換えられているので、文字通り工場出荷時の状態に戻るわけではない。

以下はUltra 2（x86）の場合にFactory defaultを開始する方法。

[参考] 日本公式サイトにある説明
ReadyNAS Ultra2 ： 工場出荷時の設定への戻し方

  1. 後面のResetスイッチをピンで押した状態で電源ボタンを押して離す（Resetスイッチは押したまま）。Act以外のLEDが全部点灯したらResetスイッチを離す。

  2. これで管理用のブートメニューに入ったので、backupボタンを2回押し、HDD1のLEDだけが点灯した状態（Factory defaultが選択された状態）にする。ここで後面のResetスイッチを押すと、選択が確定され、Factory defaultが開始される。
上記の（注4）のとおり、そのReadyNASで稼動する状態になっているHDD以外を入れた場合（空のHDDや普通のPCで使っていたHDDを入れた場合、Duo（Sparc）で稼動していたHDDをUltra 2（x86）に入れた場合、またはその逆も含まれる）は、起動時に自動的にFactory defaultが行われる。この辺は少し怖いところ。

ただし、これがうまく行かず、起動できない状態になることがある。法則性はよく分からないが、以前にReadyNASで使っていたHDDを一旦別の用に使い、再びReadyNASで使おうとしたときに起こった（RAIDarに「ルートファイルシステムが壊れています」と表示される。このルートファイルシステムとはRAIDiatorのOSのあるパーティションを指しているようなので、それがない状態では当然ではある）。

そういうときは手動でFactory defaultを開始すれば回復できた。

4.3. ReadyNASの構成に関する推測


話は戻って、ReadyNASの構成に関して。基本的に、馴染みのあるx86のUltra 2を中心に話を進める。

まずメモリの構成については、Netgearの資料に記載がある（Letter of Volatility）。これを見るまで、Ultra 2のAMIBIOSがNAND Flashにあるのか、（普通のPCのように）独立したFlash ROMにあるのか分からなかったが、答えは後者だった。

HDDのパーティション


パーティションについては、実はログ（「全てのログ」の方）に出ている。まずDuo（HDDは5400.5の320GB）の方で、「fdisk -l」の結果らしきpartition.logを見ると、
Disk /dev/hdc: 320.0 GB, 320062447616 bytes
255 heads, 63 sectors/track, 38912 cylinders, total 625121968 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x53c9a337

   Device Boot      Start         End      Blocks   Id  System
/dev/hdc1              32     4096031     2048000   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/hdc2         4096032     4608031      256000   82  Linux swap / Solaris
Partition 2 does not end on cylinder boundary.
/dev/hdc3         4608032   625105615   310248792    5  Extended
/dev/hdc5         4608040   625105615   310248788   8e  Linux LVM

Disk /dev/hde: 320.0 GB, 320062447616 bytes
255 heads, 63 sectors/track, 38912 cylinders, total 625121968 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000

この中のhdc1のパーティションがOSのあるルートで、hdc2はスワップ、その後ろの拡張パーティション中のhdc5にユーザーデータの入ったLVMがある。

さらに「df -h」の結果らしきdisk_usage.logを見ると、
Filesystem            Size  Used Avail Use% Mounted on
/dev/hdc1             2.0G  352M  1.6G      18% /
tmpfs                  16k     0   16k       0% /USB
/dev/c/c              294G  270G   24G      92% /c

OSのあるhdc1の使用量が分かる。また、ユーザーデータは/dev/c/cにマウントされていることも分かる。

同様に、Ultra 2（HDDは5K500.Bの500GB）のpartition.logを見ると、
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0xbe56265a

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              64     8388671     4194304   fd  Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sda2         8388672     9437247      524288   fd  Linux raid autodetect
Partition 2 does not end on cylinder boundary.
/dev/sda4         9437248   976768064   483665408+   5  Extended
/dev/sda5         9437256   976768064   483665404+  fd  Linux raid autodetect

Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              64     8388671     4194304   fd  Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sdb2         8388672     9437247      524288   fd  Linux raid autodetect
Partition 2 does not end on cylinder boundary.
/dev/sdb4         9437248   976768063   483665408    5  Extended
/dev/sdb5         9437256   976768064   483665404+  fd  Linux raid autodetect

Disk /dev/md0: 4293 MB, 4293906432 bytes
2 heads, 4 sectors/track, 1048317 cylinders, total 8386536 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000


Disk /dev/md1: 536 MB, 536805376 bytes
2 heads, 4 sectors/track, 131056 cylinders, total 1048448 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000


Disk /dev/md2: 495.2 GB, 495272132608 bytes
2 heads, 4 sectors/track, 120916048 cylinders, total 967328384 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000


Disk /dev/dm-0: 489.8 GB, 489894707200 bytes
255 heads, 63 sectors/track, 59559 cylinders, total 956825600 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000

こちらは完全にソフトウェアRAIDの状態を示していて、sda1とsdb1から成るmd0がOSのルート、sda2とsdb2から成るmd1がスワップ、拡張パーティション中のsda5とsdb5から成るmd2にユーザーデータの入ったLVMがある。

同じくdisk_usage.logを見ると、
Filesystem            Size  Used Avail Use% Mounted on
/dev/md0              4.0G  371M  3.5G  10% /
tmpfs                  16K     0   16K   0% /USB
/dev/c/c              455G  273G  182G  60% /c

OSのあるmd0の使用量が分かる。

また、同じくmdconfig.logを見ると、
Device         : /dev/md0
Create Time    : 1296968223
Update Time    : 1299155668
RAID Level     : 1
RAID Capacity  : 4193268
Disk Size      : 4193268
Chunk Size     : 0
Disks          : 2
RAID Disks     : 2
Active Disks   : 2
Working Disks  : 2
Failed Disks   : 0
Spare Disks    : 0
State          : 1 [ Clean ]

Disk  Device         RAID Disk  Maj/Min     Sectors   State
---------------------------------------------------------------------------
  0   /dev/sda1          0        8/ 1      8388608    6 [ Active Sync ]
  2   /dev/sdb1          1        8/17      8388608    6 [ Active Sync ]

Device         : /dev/md1
Create Time    : 1296968223
Update Time    : 1299119883
RAID Level     : 5
RAID Capacity  : 524224
Disk Size      : 524224
Chunk Size     : 65536
Disks          : 2
RAID Disks     : 2
Active Disks   : 2
Working Disks  : 2
Failed Disks   : 0
Spare Disks    : 0
State          : 1 [ Clean ]

Disk  Device         RAID Disk  Maj/Min     Sectors   State
---------------------------------------------------------------------------
  0   /dev/sda2          0        8/ 2      1048576    6 [ Active Sync ]
  2   /dev/sdb2          1        8/18      1048576    6 [ Active Sync ]

Device         : /dev/md2
Create Time    : 1296968223
Update Time    : 1299155668
RAID Level     : 5
RAID Capacity  : 483664192
Disk Size      : 483664192
Chunk Size     : 65536
Disks          : 2
RAID Disks     : 2
Active Disks   : 2
Working Disks  : 2
Failed Disks   : 0
Spare Disks    : 0
State          : 1 [ Clean ]

Disk  Device         RAID Disk  Maj/Min     Sectors   State
---------------------------------------------------------------------------
  0   /dev/sda5          0        8/ 5    967330809    6 [ Active Sync ]
  2   /dev/sdb5          1        8/21    967330809    6 [ Active Sync ]

RAIDの設定が分かる。OSのあるmd0はRAID1、ユーザーデータのあるmd2はRAID5と出ているが、X-RAID2はNetgearの独自拡張らしいので、その通りに取っていいかは不明。

ちなみに、Ultra 2はRAIDiator 4.2.16で3TBのHDDに対応するが、そのためにHDDのパーティショニングが従来のMBRからGPTに変わる。その場合はどうなるかといえば、4.2.16-T33にアップデートしたUltra 2（HDDは5K500.Bの120GB）で「sgdisk -p」をすると、
Disk /dev/sda: 234441648 sectors, 111.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 316D3541-952B-44B0-ABC1-E150505DF780
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 234441614
Partitions will be aligned on 8-sector boundaries
Total free space is 5108 sectors (2.5 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              64         8388671   4.0 GiB     FD00  Linux RAID
   2         8388672         9437247   512.0 MiB   FD00  Linux RAID
   5         9437256       234436544   107.3 GiB   FD00  Linux RAID

同じく「df -h」をすると、
Filesystem            Size  Used Avail Use% Mounted on
/dev/md0              4.0G  376M  3.5G  10% /
tmpfs                  16K     0   16K   0% /USB
/dev/c/c              102G  257M  102G   1% /c

パーティション自体はMBRのときと変わってないのが分かる。というわけで、4.2.16にアップデートしたらパーティションはそのままGPTに横滑りする仕組みらしい。なお、HDDのセクタ0はしっかりprotective MBRになっていた。

以上でHDD内の大まかな構成は分かった。

カーネルの所在


オンボードのNAND Flashについて、そこにRAIDiator（ファームウェア）のインストールイメージが置かれていることは色々なところで書かれている。例えば、Netgearの人はPro（x86）についてこう書いている。
(Re: [Readynas Pro Business] 128MB or 256MB embedded flash?)
That is just where the firmware image is stored for re-install/factory installs, you cannot use the flash in user mode. Right now the firmware image is around ~65MB. Upon system install, an OS partition is created on the hard drives that is 4GB in size. That is where all applications/configuration is stored.

また、Sparc（機種は書いてないが時期的に）については、
(Re: general interest question about the firmware)
The firmware is stored on Flash RAM on the main board. The OS is installed to a 2GB partition on the drives.
(Re: iTunes Server won't go away)
The firmware will stay as whatever you have installed. When you update the system, the firmware is written to the NAND/Flash as well, which is the source during a re-install. It won't touch your data, but will set the network IP to DHCP and admin password to default (netgear1).

HDDにインストールされたOSの使用量から見て、NAND Flashにその（たぶん圧縮された）インストールイメージが入っているのは容易に理解できる。ただ、NAND Flashの役割が単にその倉庫だけなのか、あるいはブートプロセスに関わっているのかが分からなかった。

そこで、Ultra 2のHDD（5K500.Bの500GB）のセクタ0を見てみると、

パーティションテーブルは当然あるが、ブートコードの部分は空になっている（WindowsのDiskIDが付いているが、これはX61sに接続したときに書き込まれたものだと思う）。

さらに、OSのパーティションの中を見回しても、GRUBのようなLinuxのブートローダーがないことに気づいた。つまり、普通にHDDからブートしている形跡がない。

不思議に思いながら、ブート時の記録であるdmesg.logを見ると、その冒頭に以下の記述があった。
Linux version 2.6.33.7.RNx86_64.2.2 (jmaggard@calzone) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Oct 15 13:20:46 PDT 2010
Command line: initrd=initrd.gz console=ttyS0 sk98lin.LowLatency=Off,Off reason=normal BOOT_IMAGE=kernel

実はここでLowLatencyの設定がされてたりするが、それは置いといて重要なのは以下の部分。
  • initrd=initrd.gz
  • BOOT_IMAGE=kernel
これはinitrd（ブート初期のramdiskイメージ）としてinitrd.gzを、カーネルイメージとしてkernelをロードしているらしいが、OSのパーティションにはそれらしきものはなかった。

が、この2つのファイルには見覚えがあった。それはRAIDiatorのアップデート用のUSBメモリの中で。

実はこのUSBメモリはsyslinuxでブータブルになっていて、X61sでも途中まで起動できたりする。

さらに面白いのは、この設定ファイルであるsyslinux.cfgで、その中身が以下。
serial 0 9600 0

default Normal

label Normal
kernel kernel
append initrd=initrd.gz console=ttyS0 reason=normal

label FactoryDefault
kernel kernel
append initrd=initrd.gz console=ttyS0 reason=factory

label OSReinstall
kernel kernel
append initrd=initrd.gz console=ttyS0 reason=os_reinstall

label TechSupport
kernel kernel
append initrd=initrd.gz console=ttyS0 reason=diag

label SkipVolCheck
kernel kernel
append initrd=initrd.gz console=ttyS0 reason=skip_fsck

label MemoryTest
kernel memtest

冒頭にシリアルポートの設定らしきものがあるが、その後には明らかに管理用のブートメニューと関係ありそうな記述が並んでいる。とくに、先頭のlabel Normalの部分はdmesg.logの冒頭と似ていて、カーネルイメージとしてkernelを、initrdイメージとしてinitrd.gzをロードするとの設定になっている。

ここで、ブート時にNAND Flashがどういう扱いになっているか調べてみると、ReadyNAS Pro（x86）でBIOSのブート時の画面が写っているものがあった（ReadyNAS Pro RNDP6350 Possible Flash Disk Boot Failure）。

ProのPCBにはVGAのピンが出ていて、こういう画面が出せたりするようだが、AMIBIOSがHDDを認識した後にこんな表示を出している。
Device #01 : SMI USB DISK *HiSpeed*
01 USB mass storage devices found and configured.

この「SMI USB DISK」に関して、Ultra 2のusb_devices.logに以下の記述があるのを見つけた。
T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=090c ProdID=1000 Rev=11.00
S:  Manufacturer=SMI Corporation
S:  Product=USB DISK
S:  SerialNumber=AA04012700015822
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=31875us

この「Vender＝090c」で検索してみると、SMIは「Silicon Motion Inc.」を指すらしい。したがって、Proには（Ultra 2やUltra 4と同様に）Silicon MotionのNAND Flashコントローラがあり、これがブート時にBIOSでUSB接続の、たぶんブートデバイスとして認識されているのだと思う。

ということは、同じx86のUltra 2でもオンボードのNAND FlashがBIOSでブートデバイスとして認識されているのではないか、ということになる。ただ、それを直接確かめることはできないので（カーネルが起動する前のことなのでログにも残らない）、NAND Flashの中身を見られないか。

Ultra 2のdmesg.logには以下の記述があるので、NAND Flashはsdcとなっているらしい。が、色々試しても自分ではこれをマウントできず、中身は分からなかった。
scsi 4:0:0:0: Direct-Access     SMI      USB DISK         1100 PQ: 0 ANSI: 0 CCS
sd 4:0:0:0: Attached scsi generic sg2 type 0
sd 4:0:0:0: [sdc] 244736 512-byte logical blocks: (125 MB/119 MiB)
sd 4:0:0:0: [sdc] Write Protect is off
sd 4:0:0:0: [sdc] Mode Sense: 43 00 00 00
sd 4:0:0:0: [sdc] Assuming drive cache: write through
sd 4:0:0:0: [sdc] Assuming drive cache: write through
 sdc: sdc1
sd 4:0:0:0: [sdc] Assuming drive cache: write through
sd 4:0:0:0: [sdc] Attached SCSI removable disk

ともあれ、諸々を考え合わせると、以下のような推測を立てられる。
  1. ブート時にはBIOSがいわばオンボードのUSBメモリであるNAND Flashをブートデバイスとし、
  2. NAND Flashから（syslinuxか何かのブートローダーを介して）Linuxのカーネル（kernel、initrd.gz）がロードされて起動し、
  3. 後はカーネルがHDD内のOSのパーティションからカーネル以外（ユーザーランド）をロードして起動する。
と、ここまで来たところで、そういうことはNetgearの人も書いている（断片的だが）のを見つけた。まずNVX（x86）についてこう書いている。
(Re: PAE (Physical Address Extention) for NVX Models)
It has some custom modules for handling the special hardware, and the kernel itself is not stored on disk, but in the firmware flash, so doing an apt-get won't do much.

また、全てのx86について、
(Re: Ultra 6 with 4.2.15 - GPT support?)
The Ultra (all x86) boot using BIOS to Internal Flash ROM. It mounts / (root) from the disks, but the boot process is in the flash.

Duo（Sparc）については、
(Re: Duo stuck in boot up flashing blue light)
The drives aren't needed for it to boot in telnet mode, it loads that boot image from the internal flash.

また別の人はNV+（Sparc）についてこう書いている。
(Re: T21: Trouble (re)booting after first application of update)
It does do the initial booting off the flash, so I suppose it's possible there are some bad blocks on the flash.

ということで、初期のブート（＝カーネルのロード）はオンボードのNAND Flashから行われることが確定。

なお、Netgearの人はブートプロセスに関してこうも書いている。
(Re: VirtualBox version of x86 RAIDiator?)
Not possible at this time. It would take much changing on the boot code. Much of it is tied to hardware addresses (firmware location etc), so it would never find the boot flash.

これを見ると、NAND Flashには普通のファイルシステムはなく、ハードウェアのアドレスを直接叩くやり方になっているのかもしれない。

ちなみに、このカーネルはRAIDiatorをアップデートするとバージョンが変わるので、一緒にアップデートされる模様。USBメモリからアップデートした場合でもUSBメモリ中のkernelとは違うので、単純なコピーではない。
  • 4.2.13: 2.6.33.6.RNx86_64.2.1 #1 SMP Tue Jul 27 13:21:19 PDT 2010
  • 4.2.14: 2.6.33.7.RNx86_64.2.2 #1 SMP Wed Sep 29 17:22:45 PDT 2010
  • 4.2.15: 2.6.33.7.RNx86_64.2.2 #1 SMP Fri Oct 15 13:20:46 PDT 2010

シリアルポート

Duoの後面には診断用のシリアルポートが付いている（ReadyNAS DUO Reset Switch Location Image）。同じものはUltra 2の後面にもある。4pinのもので、ピンアサインも分かっているようなので（Running own code on the Infrant ReadyNAS）、もし興味があれば。

4.4. ReadyNASのHDDをPCで直接見る可能性

DuoとUltra 2は2台のHDDによるミラーリングなので、原理的には、どちらか1台を普通のPCに繋げばユーザーデータを見ることはできる。

ただし、DuoはハードウェアRAID（たぶん）のせいか、パーティションは普通のLinuxのPCと変わらないが、ユーザーデータはLVMで管理されていて、かつブロックサイズがx86のLinuxでは標準でサポートされてない16KBなので、これを読むのに四苦八苦してたりする（ReadyNAS Data Recovery - VMware recovery toolなど）。なお、暗号化はされてない。

以下はDuo（HDDは5K500.Bの120GB）のユーザーデータのある/dev/c/cを「dumpe2fs -h」したもの。
dumpe2fs 1.40.11 (17-June-2008)
Filesystem volume name:   c
Last mounted on:          <not available>
Filesystem UUID:          8adbb446-8d4d-4ec1-a6e1-2223841c5417
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              3590400
Block count:              7180288
Reserved block count:     0
Free blocks:              7089875
Free inodes:              3590376
First block:              0
Block size:               16384
Fragment size:            16384
Reserved GDT blocks:      128
Blocks per group:         65528
Fragments per group:      65528
Inodes per group:         32640
Inode blocks per group:   510
Filesystem created:       Wed Feb 16 19:24:25 2011
Last mount time:          Wed Feb 16 19:39:31 2011
Last write time:          Wed Feb 16 19:39:31 2011
Mount count:              4
Maximum mount count:      -1
Last checked:             Wed Feb 16 19:24:25 2011
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      552799a4-355e-4415-9b7c-2c78b4f7772b
Journal backup:           inode blocks
Journal size:             512M

また、Ultra 2の方はソフトウェアRAIDなので、そもそもパーティションが違う。ただ、ブロックサイズは4KB。

以下はUltra 2（HDDは5K500.Bの120GB）のユーザーデータのある/dev/c/cを「dumpe2fs -h」したもの。
dumpe2fs 1.41.12 (17-May-2010)
Filesystem volume name:   <none>
Last mounted on:          /c
Filesystem UUID:          01ce2742-6b27-49ea-b11a-ec7e7290767b
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1675264
Block count:              26804224
Reserved block count:     0
Free blocks:              26649527
Free inodes:              1675241
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              16
RAID stripe width:        16
Flex block group size:    16
Filesystem created:       Wed Feb 16 18:12:28 2011
Last mount time:          Wed Feb 16 18:30:05 2011
Last write time:          Wed Feb 16 18:30:05 2011
Mount count:              5
Maximum mount count:      -1
Last checked:             Wed Feb 16 18:12:28 2011
Check interval:           0 (<none>)
Lifetime writes:          543 MB
Reserved blocks uid:      0 (user unknown)
Reserved blocks gid:      0 (group unknown)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      fe87f508-0a80-4ad7-a643-23ffa57bc308
Journal backup:           inode blocks
Journal features:         (none)
Journal size:             128M
Journal length:           32768
Journal sequence:         0x0000001e
Journal start:            1

ここまで見て、これは普段からmdadmやlvmに慣れ親しんだLinux使いの人でもなければ太刀打ちできないと思う。いざとなればLinuxをインストールしたPCに繋げれば読めるだろう、というのは甘ーい幻想。お任せのアプライアンスなNASのために、それだけの苦労をするのも本末転倒なので、バックアップなど運用上の注意で何とかするのが結果的には楽だと思う。

なお、ReadyNAS本体が故障してHDDが生き残った場合、そのHDDを読む方法は、Netgearの公式では、同じ機種のReadyNASを入手してきて同じ順番で差せばそのまま稼働する、というもの。絶対どうしても、という場合はこれが確実かつ安全策ではある。

いずれにせよ、本体がハードウェア的に壊れた様子はないが、起動しなくなったり、OSがおかしくなったりした場合には、まずはOS Reinstallを試してみるのが基本。
投稿者: EMO 2 コメント
ラベル: , ,
登録: 投稿 ( Atom )