自分はHttpWebRequestを使っていて、それで作成した後に知りましたが、SecurityProtocolType.Ssl3を指定する部分は取り入れさせてもらいました。Tool?[追記4]Beta版を公開しました。プログラミング2011/08/02電気アラート(続)電気アラートに関する続きです。新しい情報はSourceForge.jpのプロジェクトサイトにまとめています。)は5分ごとの使用量データを5分に1回更新していますが、タイムラグを短くしようとすると、この更新をどう追いかけるかが問題になります。単純に力技でいいなら、より短い間隔でアクセスし続ければ更新を引っ掛けやすくなるわけですが、それはあまりうまくないと思うので、アクセスも5分に1回とすると、そのタイミングが重要になります。いうことで、電気アラートの動作検証と平行して、また自作ソフトで電力会社の更新タイミングを調べた結果が以下です。7/28~8/2の5日間、3秒間隔で更新をチェックしたものですが、ソフトの開発で中断していた時間も長いので、網羅的なものではありません(更新回数は1000回強)。見てのとおり、東北電力と関西電力は鋭い山が1つだけで、更新タイミングはほぼ固定されています。九州電力は3つの山ができていて、3つのタイミングがあることが分かります。どの順番でどのタイミングになるかという法則性は、元の更新時刻を見てもよく分かりませんでした。東京電力は前半に低い山並みができてますが、これには理由があります。例として、7/31の19:00~21:00の更新時刻を挙げます。2011/7/31,20:50更新タイミングは早い時刻から始まって、1回の更新ごとに20~30秒遅れていき、これを5~6回繰り返した後に元に戻るというパターンになっています。それぞればらつきが大きいので、集計してみると低い山の連続になるというわけです。それぞれの山の中に谷がありますが、これも理由があって、大まかに休日と平日の差によるものです。以下は電気アラートのコマンドラインオプションを使って「内部時刻」と「更新状況」を表示させたものです。この「更新状況」は上で使ったソフトのサブセットで、30分間、3秒間隔で更新をチェックします。これは7/31のものですが、更新タイミング(表中の「差」の列)は大体124秒です。更新タイミングは大体140秒になります。見られ、平日は10~20秒遅くなります。以上を考慮して、電気アラートではアップデートのためにアクセスするタイミングを、電力会社ごとのプリセット値として持っています(Ver.0.8.0)。東北電力の例では、上の7/31の時点では140秒=2分20秒としていて、これは「内部時刻」の「アップデート」の「次回」時刻に反映されています。平日は遅くなることが分かったので、下の8/2の時点では150秒=2分30秒に変更しています。この場合、23:07:17に更新されたデータを23:07:30にアクセスして見に行こうとしている直前で、データの時刻から電気アラートに反映されるまでのタイムラグは2分30秒ということになります。これほどタイムラグを短くできるのは、データが出てくるのが速く、更新タイミングが安定している東北電力ならではですが。この更新タイミングがずっと同じかは不明なので、タイムラグがどうも長い......というときは、「更新状況」で更新タイミングを確かめた上で(その間のアクセスが増えるのは目を瞑ってもらうとして)、コマンドラインオプションでアップデートのタイミングを指定することで調整できます。SSDのE2/E3/E4Intelの天野氏の置き土産について、自分でもよく分かってないが、とりあえず書き留めておく。Writesとはまた別の方法を説明していた。これが詳しく出ている記事(インテル天野氏が最後のイベント出演、Z68とSSDを語る)を見ると、これまで明らかでなかったSMARTのE2、E3、E4の意味が出てくる。/dev/hdx(注)丸括弧内は、元はIntel内部の資料だったものに天野氏が書き加えたものっぽい。/dev/hdx」で変化を見ろ、という話(注)らしい。(注)記事のキャプションでは少し違うことが書いてあるが、どうも分かってない感じがするので、資料の記述だけを信じる。例として、E2が22、E3が99、E4が981のときは以下のようになる。Years981分間の消耗率が0.021%ということから計算して(この負荷だけをかけ続けた場合の)寿命は8.9年になるとのこと。8.687422167(全消耗にかかる年数)......。8.887801696(全消耗にかかる年数)合った。いずれにせよ、E3はこの計算には入ってこない。「書き込みの割合が増えると耐久性は一気に下がる」というのは、E3が下がる=書き込みの割合が上がる負荷のときは、逆にE2は上がるという逆相関関係の意味だろうか。80GBで試してみる。/dev/sda」で表示されるものも全て入っている)。このSMARTの部分は、226(E2)、227(E3)、228(E4)とも65535になっている。SSDに対応しているようで、資料とほぼ同じ名前が短縮されたものになっている。これはsmartmontoolsのデータベースであるdrivedb.hにあるもので、この中を見るとIntelの情報は伝わっていることが分かる。0x40」に成功しているように見える。この後再起動しようと何をしようと65535の数字は全く変わらなかった。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進数はどれも既に上限に達しているので、もう変わりようがない、ということではないかと......。これをリセットできない以上、先に進みようがない。いうことで、よく分からないまま終わる。Addendum)にはE2、E3、E4の説明があったので、320シリーズだけで有効なのかもしれない。value)ではそうなっているというだけらしい。[追記2]CrystalDiskInfo(4.1.0)からE2、E3、E4の名前に対応されているので補完。日本語表記もばっちり。それぞれの詳細な意味は320シリーズの追補を読んでもらうということで。ストレージ2011/07/17マウス三台クリックボタンがおかしくなったVX-Nanoの交換機としてM905が来たので、Logicoolマウスを比較してみる。右がM905、左がVX-Nano、奥がM555b。重量M905を空の状態で持ち上げると、VX-Nanoに慣れた手には重さを感じた。重量を電池を入れた状態で比較すると、以下のようになる。116(注)単4はアダプターを含む(VX-Nanoを除く)。計測したときの電池のブランドが違うので、電池の重量にズレがある。M905はマウス単体で他より11~18g重いので、単3×2のフル状態だと結構ずっしり来る。他と違って1本でも動作するので、最軽量の単4×1の状態であれば99gと、他の最軽量状態とさほど変わらない。その分、電池寿命は短くなるわけだが、自分はeneloopを使っているので、そこは問題ではなかった。1本だけではバランスがどうなるか気になったが、単4であれば左右どちらでもさほど違いは感じない。自分は右手で使うので親指に近い左側に1本入れた状態にすると、ほとんど違和感はなかった。[追記]単4×1(eneloopの750mAhのほぼ新品を満充電状態から)で使っていたところ、5日目で電池切れとなった。充電池だからまあいいが、乾電池では奨められない方法ではある。スイッチ裏側にはスイッチ兼用のシャッターがあるが、これが小気味よく動くので、バッテリーの蓋を外して裏返してみると、くるくる平たく巻いたバネが入っていた。このバネがシャッターのスライドで動く。バネの一方の端が蓋側のピンに、もう一方がシャッター側のピンに固定され、開閉それぞれの位置で止めるようになっている。安上がりに済ませる方法もあるだろうに、この薄いスペースにこういう細かい機構を組み込んであるのが面白い。インターフェイス2011/07/16電気アラート自作ソフトの紹介です。機能としてはとくに目新しいものではありませんが、シンプルにまとめました。新しい情報はSourceForge.jpのプロジェクトサイトにまとめています。)から一定間隔でデータをダウンロードし、その日のピーク時供給量、最新の使用量を見て、最新の使用率とその動きをタスクトレイから色と数字で知らせます。使用率が高くなっている場合はアラートを出します。タスクトレイにアイコンが出ます。この数字が使用率で、どれぐらい高いかをこの色で直感的に示します。マウスオーバーすると最新の数字と上下動をチェックできます。色は以下のカラーチャートに従っています。赤くなってきたら使用率が高くなっています。アップデートしたときに使用率の閾値を超えている場合は、設定に従って音とバルーンメッセージによるアラートを出します。アラート音として任意のWAVファイルを再生できます。説明を兼ねてフリーのWAVファイルを同梱していますが、これには、Free音素材「音楽室」(http://www.otosozai.com)のva01.wavを使わせていただいてます。4.0がインストールされていることが必要です。ダウンロード以下からダウンロードできます。その他このソフトはオープンソースです。使用条件については同梱のlicense.txtをご覧ください。Expressで開発しています。単体で動作するWindowsアプリとしては初なもので、ソースは推して知るべしです。ソースを公開することにためらいがないということもありますが......。電力会社が公開しているデータファイル(CSVファイル)は、どこも最初に出した東京電力のものがベースになっているので、共通の部分が多いです。TPTPコネクトでは、ピークタイムを取得するアルゴリズムは全部同じで済んでいます。似たような形式でも意味が微妙に違っていたり、データが更新される速さに差があったりします。東京電力を基準とすると、東北電力は同じぐらい。九州電力は公開を開始したのは一番遅かったですが、かなり頑張っています。関西電力も頑張っていますが、更新が少し遅いです。残る中部電力はまだ1時間ごとのデータしか出していない分、遅れていると言わざるを得ません。電力会社の更新タイミング関西電力は3分ごとのデータを公開していますが、更新間隔はこれと少しずれていて、かつ遅れ気味ということを見つけたので、自作ソフトを使ってデータを取得してみました。15:14(注)2秒間隔で更新をチェックし、更新があればデータを記録していく方式。「CSVファイルが更新された時刻」は自作ソフトを実行中のPCのものなので、誤差があり得る(以下同じ)。見てのとおり更新時刻の間隔は5分で、UPDATEに記載された時刻の5分後になっています。データは3分ごとなので当然ずれていくわけですが、5分の更新で3分×2のデータを追加するのを基本として、詰まってくるとスキップするようです。法則性があまりはっきりしないのと、データが細かい割に更新時刻とのタイムラグがおよそ15~24分と、結構あるのがちぐはぐで、謎仕様です。はというと、データもUPDATEに記載された時刻、更新時刻も5分ごとなので、ずれることはありません。5:50データと更新時刻のタイムラグは5~8分です。これは東北電力と九州電力と照らし合わせると、データの時刻の表記方法がこれらとは違っていて、5分ずれているかもしれません。10:45のデータは10:40~10:45の5分間ではなく、10:45~10:50の5分間を示すというように。それにしては早すぎる場合もあるので(差が1桁のときもある)、不明です......。「5分刻みの時刻との差」というのは5分、10分、15分...という5の倍数の時刻との差で、自動アップデートのタイミングを決める参考になります。これは大体2分以内に収まっています。2:15規則正しく2分14秒ごとに更新しています。タイムラグも同じく2分14秒です。2:19こちらも2分20秒か、3分20秒ごとに更新しています。タイムラグも同じ時間で、東北電力に次ぎます。以上のようなことを考慮に入れて、電気アラートでは、5分刻みの時刻に2分30秒を加えた時刻(7分30秒、12分30秒、17分30秒......)に自動アップデートを行うようにしています(ただし、時間の経過とともに少しずれていきます)。電力会社ごとに細かく合わせるように変更しました(電気アラート(続)参照)。深夜0時に日付が変わった後、電力会社のデータは更新がしばらく途切れます。この時間帯に途切れても実用上は何の問題もありませんが......。正常なデータの更新が再開する時刻を同じく自作ソフトで調べてみたのが以下です。0:08:42東京電力と東北電力は、その日の1回目の更新で前日のデータを全部出した後、更新が止まり、1時過ぎに0時台の1時間のデータとともに、5分ごとのデータの更新が再開します。これも一つの割り切りだとは思います。関西電力は、更新は止まらないのですが、中身は前日のデータという状態が続き、中身もその日のデータに切り替わるのは1時20分頃です。止まらないのはいいのですが、あまり行けてない感じがします。九州電力は、1回だけ更新がスキップしますが、その日の2回目のタイミングから更新が再開します。九州電力は1時間ごとのデータを出してないので、そこが他とは違いますが。以上のように、九州電力を除いて、0~1時頃の間は正常なデータがリアルタイムで出ていません(その間のデータは再開した時点でまとめて出ます)。電気アラートでは、正常でないデータはスルーするようにしているので、再開するまで前日のデータが表示されたままになります。実用上は問題ないと思いますが、念のため。電力2011/07/01東京電力の電力状況いよいよ夏到来の7月ということで、東京電力の地域の電力状況について中間まとめをしてみる。初めに、使用率という数字はYahoo!などが(たぶん一目で分かるように)東京電力のデータを加工して出しているだけで、東京電力自身が積極的に出しているものではないので、念のため。自分はTPTPコネクトで計算してバッテリ駆動時間の閾値に使っているが。電力使用率とピークタイム3/23から6/30までの電力使用率とピークタイムを一覧にしてみた。赤みが強いほど使用率が高い。前回は速報値で計算したが、今回は確定値で計算したので、5/7までの数字でずれている部分がある。使用率はゴールデンウィーク明けの5/9の週に高くなってからは低い状況が続いてきたが、6/20の週にぐぐっと上がり、週末を挟んでまた上がってきている。ピークタイムに関しては、東京電力による予想の的中率はあまり高くないが、数字的には僅差だったりすることが多いので、それほど外れているわけでもない。ピーク使用量も見れば分かるとおり、使用率と使用量は単純な比例関係にはない(使用率の高い日が使用量も高い日とは限らない)。これは母数の「ピーク時供給力」も日ごとに変動しているからで、使用率を理解するにはこの間の関係を見る必要がある。電力使用量と「ピーク時供給力」まず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%を超えたわけだが、それを予想して東京電力は待ち構えていたことが分かる。その後、東京電力は週末を挟んでさらに供給力を引き上げて対応している。今後7月1日の東京電力のプレスリリース(今夏の需給見通しと対策について(第4報))によれば、この夏は大体5500万kWが供給力の上限となるらしい。「ピーク時供給力」は5000万kWを超え、これまでは余裕のあった東京電力も、いよいよ本気を出さないといけなくなりつつある。これまでは使用率といっても、それ自体に深い意味はなかったが、今後は本当に供給力との戦いの意味を持つようになってくるのだろう。6/29は都心部の最高気温が35度に達する中で、使用量は(7月からの電力使用制限が始まる前にして)4570万kWに留まっている。この気温と使用量の関係について、早野東大教授は「(参考出品)TEPCO最大電力と東京の最高気温の関係」で、これまでの実績では最高気温1度上昇につき使用量が約135±17万kWの上昇になっていることを示している。今後もこの相関関係が続くなら、最高気温が40度に達しても使用量は5300万kWぐらいに留まる計算になるので、このまま波乱がなければ凌げそうにも思う。気温が30度台後半になると、我慢とか工夫とかで何とかなる世界ではなくなるのでクーラーを使う人が増えるかもしれず、使用量が急上昇するかもしれない。いずれにしても、今年の夏は「忘れらない夏」になりそうではある。Switch)に更新した。これにしたのはコンパクトで真四角な金属筐体というのが最大の理由で、消費電力については最大3.2Wというぐらいしか情報がなかった。今時のハブにはたいてい省電力機能があって、例えばBuffaloのLSW3-GT-5NSでは不使用ポートの電力オフとケーブルの長さに応じた電力カットを謳っているが、GS105v3の場合は詳しい説明がない。unused」との記述があるので、不使用ポートの電力オフ機能があることは分かるが。そこでワットモニターで消費電力を測ってみたのが以下。基本は1.1W使用ポートが増えるにつれ、大体0.5Wずつ増えていく公称の最大3.2Wというのは正確ということが分かる。5ポートに接続した状態で全ポートをビジーにしてみたが(X61sでYouTubeの動画を見つつ、Ultra2上の動画ファイルを再生し、かつDuo上の動画ファイルをX60sで再生)、消費電力に変化はなかった。使用状況で何か変わるかと思ったが、そうでもないらしい。結果としては、消費電力を公表しているLSW3-GT-5NSより、いずれの状態でも消費電力は小さく、十分な省電力性が確保されていると思う。問題ではないが、気づいたこともあって、それはLEDの光が強いこと。下のLSW-GT-5Wの電源LEDがぼうっと点いているのに比べて、GS105v3のLEDは眩しく光っている。5つのポートを全部使用すると最大11個のLED(電源+1000Mの場合の各ポート2×5)が点灯する。ハブなので別にいいのだが、結構派手ではある。APIからスクリプトでデータを取得してまとめてみた。大体3/26を境目に、それまで毎日のように計画停電が打たれていたのが、気温の上昇と発電能力の一部回復で需給が緩和されていき、現在に至っている。電力使用率の高い日が特別逼迫しているというより、需給予想に従って東京電力が発電能力を増減させているので、東京電力の予想よりは使用量が高かった日と見た方がいいと思う。4/19は4月に入ってから使用量が一番高かった日だが、使用率には比較的余裕がある。これに対して、4/23は使用量はさほどでもないのに使用率は高くなっている。2日前の5/06の使用率が高いのも、連休の狭間にしては使用量が高かったということではないかと思う。東京電力の予想するピークタイム(ピーク時供給力の時間帯。グラフに横棒が引っ張ってある部分)は、時々外すが、最近では概ね安定している。平日の日中は使用率が僅差で高止まりしているので(12時台に少し落ちる以外)、どの時間帯にバッテリ駆動すればいいのかは簡単には決め難い。えいやっと決め打ちでもいいのだが、どうせやるならうまくピークタイムと使用率の高い時間帯に合わせられた方がいいよね、ということでTPTPコネクトの出番となるわけだが、さて。電力2011/04/08ReadyNASとは何かReadyNASを普通に使っている限りは全く気にする必要はないが、何か問題が起きたりしたときに、そもそもReadyNASの中はどうなってるのかということに興味が湧くのは自然だと思うので、その流れの話。ReadyNASの構成(推測)ReadyNASが何かといえば、LinuxをOSとして稼働する/RAID構成で/NAS専用のPC、ということになる。アプライアンスのLinux機としては普通のPCに近いが、普通のPCと特に違うのは、オンボードにOSのインストールイメージを持っていることブートプロセスが少し変わっていることただ、Netgearの人はこういう話をあまり正面から書いてくれてない。アプライアンスであってユーザーの心配することではないし、SSHでログインすれば分かる人には分かるだろう、と説明の必要を感じてないのかもしれない。したがって、自分の推測がかなり入っているし、自分はLinuxに特に詳しいわけでも何でもないので、その前提で。本当にトラブルに陥って回復作業をしなければいけないときは、素直にNetgearのサポートに頼った方がいい。ReadyNASでは、そのファームウェア=専用にカスタマイズされたLinux=OSのことをRAIDiatorと呼んでいる。似た名前でRAIDarもあるが、こちらはクライアントPCからネットワーク上のReadyNASをモニターするためのソフト。何でこんなややこしい名前にしたのか知らないが。ReadyNASの構成とRAIDiatorのアップデート/回復の関係を整理。(注2)既にインストールされているバージョンと同じ場合は書き換えない。Reinstallが行われる。Reinstallが必要。defaultが行われる。defaultが必要。同じ機種同士であればそのままのHDDで稼働する模様。アップデート/回復手段なぜこう言えるのかはひとまず置いて、具体的な方法について説明すると、Frontviewからのアップデート基本簡単。古いバージョンに戻せない制限付きのことがあるので、リリースノートに注意。USBメモリからのアップデートReadyNASがまともに起動せず、Frontviewが使えない場合や、Frontviewからは古いバージョンに戻せない制限がある場合でも可能だったりする。2(x86)の場合の方法。SystemsReadyNAS_x86_USB_Flash_Recovery-4.2.12.zipをダウンロードする。Utility)を実行すればUSBメモリが作成される。これにはRAIDiatorファイル(4.2.12)が同梱されているが、同じフォルダに新しいRAIDiatorファイルをコピーすれば、実行時にそれを選ぶことができる。このUSBメモリを前面のUSB3.0ポートに挿し、backupボタンを押した状態で電源ボタンを押して離す。電源が入って自動的にUSBメモリにアクセスが行われ、2分ぐらいで自動的に電源が落ちる(ここまでbackupボタンは押したまま)。USBメモリを抜き、普通に電源を入れると、アップデート作業が行われて起動する。ちなみに、自分のDuoではUSBメモリによるアップデートに成功したことは、相当粘ってみたが一度もない。どこかに問題があるのだと思う。2でも同様の方法があるのかは不明。Flashにあるインストールイメージを使って書き換えるもの。ユーザーデータには触らないので、ユーザーデータが失われることはない。defaultになってユーザーデータは失われる。defaultが開始されかけたときは、電源ケーブルを引き抜いてでも止めなければいけない。Reinstallを開始する方法。再インストール後面のResetスイッチをピンで押した状態で電源ボタンを押して離す(Resetスイッチは押したまま)。Act以外のLEDが全部点灯したらResetスイッチを離す。Reinstallが選択された状態)にする。Reinstallが開始される。●(注)Actは関係ない。Reinstallの後も一部の設定は残ってたりするので、OSのパーティションをフォーマットしてからインストールするのではなく、上書きインストールをする模様。Flashにあるインストールイメージからインストールするもの。Flashのインストールイメージも書き換えられているので、文字通り工場出荷時の状態に戻るわけではない。defaultを開始する方法。後面のResetスイッチをピンで押した状態で電源ボタンを押して離す(Resetスイッチは押したまま)。Act以外のLEDが全部点灯したらResetスイッチを離す。defaultが選択された状態)にする。defaultが開始される。defaultが行われる。この辺は少し怖いところ。これがうまく行かず、起動できない状態になることがある。法則性はよく分からないが、以前にReadyNASで使っていたHDDを一旦別の用に使い、再びReadyNASで使おうとしたときに起こった(RAIDarに「ルートファイルシステムが壊れています」と表示される。このルートファイルシステムとはRAIDiatorのOSのあるパーティションを指しているようなので、それがない状態では当然ではある)。defaultを開始すれば回復できた。話は戻って、ReadyNASの構成に関して。2を中心に話を進める。Volatility)。ROMにあるのか分からなかったが、答えは後者だった。HDDのパーティションパーティションについては、実はログ(「全てのログ」の方)に出ている。0x00000000この中のhdc1のパーティションがOSのあるルートで、hdc2はスワップ、その後ろの拡張パーティション中のhdc5にユーザーデータの入ったLVMがある。/cOSのあるhdc1の使用量が分かる。ユーザーデータは/dev/c/cにマウントされていることも分かる。0x00000000こちらは完全にソフトウェアRAIDの状態を示していて、sda1とsdb1から成るmd0がOSのルート、sda2とsdb2から成るmd1がスワップ、拡張パーティション中のsda5とsdb5から成るmd2にユーザーデータの入ったLVMがある。/cOSのあるmd0の使用量が分かる。]RAIDの設定が分かる。OSのあるmd0はRAID1、ユーザーデータのあるmd2はRAID5と出ているが、X-RAID2はNetgearの独自拡張らしいので、その通りに取っていいかは不明。4.2.16で3TBのHDDに対応するが、そのためにHDDのパーティショニングが従来のMBRからGPTに変わる。/cパーティション自体はMBRのときと変わってないのが分かる。いうわけで、4.2.16にアップデートしたらパーティションはそのままGPTに横滑りする仕組みらしい。以上でHDD内の大まかな構成は分かった。Flashについて、そこにRAIDiator(ファームウェア)のインストールイメージが置かれていることは色々なところで書かれている。Netgearの人はPro(x86)についてこう書いている。Flashにその(たぶん圧縮された)インストールイメージが入っているのは容易に理解できる。Flashの役割が単にその倉庫だけなのか、あるいはブートプロセスに関わっているのかが分からなかった。2のHDD(5K500.Bの500GB)のセクタ0を見てみると、パーティションテーブルは当然あるが、ブートコードの部分は空になっている(WindowsのDiskIDが付いているが、これはX61sに接続したときに書き込まれたものだと思う)。OSのパーティションの中を見回しても、GRUBのようなLinuxのブートローダーがないことに気づいた。普通にHDDからブートしている形跡がない。不思議に思いながら、ブート時の記録であるdmesg.logを見ると、その冒頭に以下の記述があった。BOOT_IMAGE=kernel実はここでLowLatencyの設定がされてたりするが、それは置いといて重要なのは以下の部分。initrd=initrd.gzBOOT_IMAGE=kernelこれはinitrd(ブート初期のramdiskイメージ)としてinitrd.gzを、カーネルイメージとしてkernelをロードしているらしいが、OSのパーティションにはそれらしきものはなかった。この2つのファイルには見覚えがあった。それはRAIDiatorのアップデート用のUSBメモリの中で。実はこのUSBメモリはsyslinuxでブータブルになっていて、X61sでも途中まで起動できたりする。面白いのは、この設定ファイルであるsyslinux.cfgで、その中身が以下。memtest冒頭にシリアルポートの設定らしきものがあるが、その後には明らかに管理用のブートメニューと関係ありそうな記述が並んでいる。Normalの部分はdmesg.logの冒頭と似ていて、カーネルイメージとしてkernelを、initrdイメージとしてinitrd.gzをロードするとの設定になっている。ProのPCBにはVGAのピンが出ていて、こういう画面が出せたりするようだが、AMIBIOSがHDDを認識した後にこんな表示を出している。2のusb_devices.logに以下の記述があるのを見つけた。Inc.」を指すらしい。Flashコントローラがあり、これがブート時にBIOSでUSB接続の、たぶんブートデバイスとして認識されているのだと思う。FlashがBIOSでブートデバイスとして認識されているのではないか、ということになる。Flashの中身を見られないか。Flashはsdcとなっているらしい。試しても自分ではこれをマウントできず、中身は分からなかった。diskともあれ、諸々を考え合わせると、以下のような推測を立てられる。後はカーネルがHDD内のOSのパーティションからカーネル以外(ユーザーランド)をロードして起動する。ここまで来たところで、そういうことはNetgearの人も書いている(断片的だが)のを見つけた。NVX(x86)についてこう書いている。flash.また別の人はNV+(Sparc)についてこう書いている。Flashから行われることが確定。Netgearの人はブートプロセスに関してこうも書いている。Flashには普通のファイルシステムはなく、ハードウェアのアドレスを直接叩くやり方になっているのかもしれない。ちなみに、このカーネルはRAIDiatorをアップデートするとバージョンが変わるので、一緒にアップデートされる模様。USBメモリからアップデートした場合でもUSBメモリ中のkernelとは違うので、単純なコピーではない。