HDDのリトラクトを行う

●更新履歴
20041010 実験2に「ちょっと追試」を追加/実験3を追加
20040919 実験2を追加
20040905 公開

●はじまり
ファンレスパソコン(動作報告)で超漢字を使用しています。
快適なのですが、1つ気になる現象があるのですよ。

それは、自動電源OFF時にHDDが緊急リトラクトを行う事です。

HDDのデータシートによると、緊急リトラクトは1万回保証しているので、すぐに壊れるという物ではないのですが、メカ的な負担は通常時の100倍あり、突発的な事故が発生する可能性があるので「極力緊急リトラクトは行わないように」とも書かれています。
(使用中のHDDは、構造的にはアンロードと表現するのが正しいが、ここではリトラクトと書きます。)

ちょうどファンレスパソコンへの移行期だったので、念のため今まで使用していた超五月蠅いパソコンで確認してみたところ、やはり緊急リトラクトしてました。今まで気付かなかったよ〜 −−;

これはOS終了時にリトラクトを行っていないのでは?
そこでPMCに問い合わせてみました。こんな変な質問に返事が来るのかドキドキでしたが、すぐに回答をいただきました。いつも思うのですが、対応の早さに感心します。
「APM BIOSを叩いてディスクをスタンバイ状態にしたのち、電源を切っている」とのことで、OS終了時のシーケンスに問題は無いように思えました。

ということは、マザーボードのBIOSに問題があるのか?
そういえば新旧マシンともに、同じBIOSメーカーだったような気が…



●実験1 マイクロスクリプトでリトラクト・・・失敗
ひとまずHDDにコマンドを送ってリトラクトさせてみよう。ということで、ATコマンドを送るAPIやら仕組みを探してみたのですが見当たらず、ATAPIコマンドなら送れる事がわかりました。
 Chapter 5 System Dis
  → 5.4 属性データ(CTLfd以外) → DN_DISKCMD

ところでHDDにATAPIコマンドは有効なのでしょうか?
という訳で実験です。はじめはC言語(BV−GSDK)で組むつもりだったのですが、第1章 デバイスドライバ共通仕様 を眺めていたら、突如マイクロスクリプトで謎だったDOPEN命令とベクトルが繋がったため、調子づいて作ったのがコレ。
 書庫形式:retract.bpk (実行するときは自己責任でお願いします)

結局DOPEN命令で、デバイス操作エラー(16)が発生して失敗。hdaは/SYSにマウントされて使用中なので、まぁ〜当たり前といえば当たり前ですね。



●実験2 対症的リトラクト・・・負け(失敗)
実験1の結果からC言語で書いても動かないと思うので、他の方法を考えてみる。
使用中の2.5”HDDは、ある時間アクセスがないと自動的にリトラクトする機能がついています。これを使わない手はありません。というわけで、電源off前に待ち時間を入れてみよう作戦です。

ひとまずOSの起動から終了までの動きを想像(妄想?)してみます。
IPLやらMBRやらBootセクターやらkernelローダーやら諸々あって
STARTUP.CMD始まり
 カーネル拡張(外殻)とか、いろいろ準備して
 logon
 $cli STARTUP.CLI !224
  STARTUP.CLI始まり
   aliasされたdoのDLEDで初期ウィンドウが開いて
   初期ウィンドウを閉じると戻ってきてexitで終了
  STARTUP.CLI終わり
 logon E  ←ここで何時ものパネルが表示されたりする
 exit 1
STARTUP.CMD終わり という感じかなぁ〜

つ〜ことで、STARTUP.CMDの「exit 1」の前で待ち時間を入れれば良さそうです。cliにsleepとsync命令があるので、お気楽モード。さっそく元の実身のバックアップを取って
「$cli −e sync; sleep !224」を追加してみました。よっしゃぁ〜、再起動やぁ〜
・・・・・・・・・・ (・・?)
・・・・・・・・・・ ( ̄▽ ̄;)
事件勃発です。起動しません。
ふっふぅ〜、こういう時の為にバックアップをとっ・・・どうやって戻すんじゃぁ〜 >_<

いやぁ〜大変でしたよ〜、元に戻すの。せめてコンソールさえ動いてくれれば助かるのに…という事で作っちゃったのがコレ→超漢字4緊急起動ディスクを作る

「OSは壊した回数だけ詳しくなれるのだよ」、うむうむ。強い見方を手に入れたので、気を取り直して再実験です。結果は、
 初期ウィンドウを閉じる→いつものパネルが表示される
  →10秒間の待ち時間→自動リトラクト(きたきた)
  →ディスクアクセス(あれ?)→約2秒後に電源off
  →緊急リトラクトが必ず発生
が〜ん、症状が悪化してしまった。HDDはアクセス状況に応じて自動リトラクトするまでの時間を可変するらしく、希に(30回に1回程度)リトラクト後に電源offしていたのですが、今回は全くもってダメダメです。
久々に負け気分  _| ̄|○

一応まとめ
・STARTUP.CMDの本体は、レコード番号0に無いとダメらしい
・STARTUP.CMDの「exit 1」文以降でもディスクアクセスは行われる

ちょっと追試
電源off前に何故ディスクアクセスが行われるのか?
比較のため、勝手に作った超漢字4緊急起動ディスクのSTARTUP.CMDを書き変えて、FDからBootしてみました。結果は、
 コンソール画面を閉じる→いつものパネルが表示される→10秒間の待ち時間
  →ディスクを取り出してくださいパネルが表示される
  →ディスクを取り出す→約2秒後に電源off
この間、FDへのアクセスは行われませんでした。
やはりスワップ領域(実身)の後片づけでも行っているのでしょうかねぇ?
(漢字変換関係がバックグラウンドで動いているのも気になる。終了時に辞書を閉じるかも…)



●実験3 セカンダリでリトラクト・・・微妙だ!!
ここは基本に戻ってAPMの仕様を調べます。ついでに上位互換っぽいACPIも調べます。仕様書はAdvanced Power ManagACPIにありますが、英語大嫌いなのでネットサーフィンやググって調べます。結局あきらめて仕様書も眺めましたけどね。

いろいろ調べていくうちに、次のような内容を見つけました。
「全デバイスを指定してスタンバイを行った場合、プライマリのストレージは含まれない
正確には「全デバイス」の部分の注記として書かれていたのですが、それが何処の何という資料で見つけたのか忘れてしまって、探しているのですが見当たらないのです(鮮度落ち)。これが見つかればPMCさんにもズバッと言えるのですがねぇ〜、夢にでも見たのでしょうか?(私の超プアな誤英訳が原因という説もある)

まぁ〜、なにはともかく、やってみれば判る!!。ということでHDDをセカンダリに接続してみました。
結果は、3割くらいの確率でリトラクト後に電源が切れる、といった感じ。
びみょ〜・・・微妙すぎるぞ!!。どうしろと言うのだ。

確率が上がっていることを考えると、HDDにコマンドが送られている可能性は高いです。リトラクトコマンドはオプション扱いなので、普通はスピンドルモータを止めるスタンバイコマンドを使いますが2種類あるんですよ、単なるスタンバイと即時スタンバイ。おそらく前者のコマンドが送られているのでしょう。(最近のドライブは大容量キャッシュを搭載していて、例えば先読みキャッシュ動作中にスタンバイコマンドとか来たら、一連のデータを読み終わるまでスタンバイ状態に移行しないと想像される)

使用中のパソコンが小さく、長さを合わせたケーブルを作らないと蓋が閉まらない状態なので、結局もとに戻してしまいました。あの25mil(0.635mm)ピッチのケーブルとコネクタを準備するのが大変そうなので…



さてさて、だんだんと想像やら妄想話が増えてきました。そろそろ限界でしょうかねぇ。
なんとなく次の手は考えているのですが、ちょっと準備期間が必要なので、しばらく更新は無いでしょう。