読み書きのためにヘッドが移動(シーク)するのにかかる時間のことです。通常外周と内周では速度が変わるため、平均値が使われます。b.(平均)回転待ち時間(サーチ時間)データが磁気ヘッドの下に来るまでの平均時間なので、最小0、最大1、なので1/2してます。1回転の時間つまり当然ですが、回転数が早いほうが応答時間としては短くなります。HDDの場合、5,400rpmより、7,200rpmのほうが早いということになります。policy今回のRAIDカードのようにバッテリーバックアップ付ライトキャッシュ(BBWC)が搭載されている場合、ライトキャッシュを有効にしたほうがよいケースが多いと思います。ライトキャッシュがあっても、書き込みデータはそこからあふれるわけですが、コントローラ側の実装により、隣接領域を連続して書き込んでくれるなど、キャッシュなしの場合に比べパフォーマンスが向上することが期待されます。キャッシュ有効化し、キャッシュに書き込みを完了した時点で完了通知を出すのをライトバック。キャッシュを使用しない(無効化している)書き込みをライトスルーといいます。今回はライトバックの設定としました。policy書き込み同様、読み取りのポリシーもいくつかあります。Adaptiveシーケンシャルリードと想定されれば先読みする。aheadとしました。aheadか、Adaptiveのほうがよいかもしれません。ディスクキャッシュディスクにも通常キャッシュが搭載されていますが、バッテリーバックアップが無い為、マシンのクラッシュ時には消えてしまう可能性があります。そのため、エンタープライズ系のHDDはよくデフォルトでディスクキャッシュが無効化されているのですが、されていない場合は明示的に無効化する必要があります。Policyこれいまいちよくわからなかったのですが、マニュアルを見る限り、読み取り処理を行ったあと、データをリードキャッシュに格納するかの設定っぽいです。LSIならでは?なのかな??Directキャッシュされない。aheadで読み込んだブロックはリードキャッシュに残る(っぽい)Cachedすべての読み取りがキャッシュされる。chachedにしてみました。I/Oでいいのかもしれません。None[/bash]MegaCli64のコマンド自体は、ネット上にコマンドリファレンスが転がっているので、それを参考にするのがよいかと思います。commandshttp://kb.lsi.com/KnowledgebaseArticle16516.aspx区切りがいいので今回はこのへんで。書ききれなかった「RAIDレベル」「フルストライプ書き込み」等については、次に触れたいと思います。当たり前ですが上記の記述は環境によって正しい場合と正しくない場合があります。今どきのLinuxだと、fdiskというより、partedでいいですよね。partedはいろいろ良い所がありますが、「--script(-s表記も同じ)」をつけると、非対話型モードとしてバッチ処理できるのがとても便利です。5系での動作になります。'print'#ディスクラベルの設定。gpt」とかにすればよいですね。13っていうノートPCを会社で買ったんですが、イーサネットのポートがなく(今時のうるとらPCってやつですね)。7から認識させようと思ったけど、認識してくれない。デバイスマネージャからは、「DAD」ヤル気のないデバイス名が表示され「?」が付いている。AX88772Aってチップを使ってるっぽかったので、チップ屋のサイトからドライバ落としてきてロードしたらちゃんと使えました。DELLのサイトちょろーっと探したけど、それっぽいの見つけられなかったなー。82574L某社の鯖(特に秘す)現象しばらく放置してると(通信した状態で)、/var/logに、こんなんでるねん。registerそして通信できなくなってしまう。CentOSのbugzillaにも似たようなのがあった。reboothttp://bugs.centos.org/view.php?id=5614どうしたかとりあえず、CentOS6.2のe1000eは1.4.4だったので、Intelのサイトから1.9.5(当時の最新)を拾ってきて適用。結果だめorz上記のbugzillaにpcie_aspm=offしたらいいぜHAHAHAみたいなコメントがあったのでやってみる。OK(^^)というわけで、某環境では、grub.confに上記の起動パラメータを追加してちゃんと動いてます(今のトコ)。最近読んだ本と、富士通のはなしauthor:scenicaviatorぼくは富士通のインサイダーではないので、公開情報しか知らないんだけど。前にプロジェクトXでもやっていたので、割と有名かもしれませんが、富士通のコンピュータ事業ってのは、池田敏雄さんというキーマンがいました。詳細は適当にぐぐって貰えばよいですが、書籍だとに、弟子の山本卓眞さんのインタビューが載っていて、いわゆる池田敏雄伝説みたいなのがでてきます。この「計算機や〜」も残念ながら品切れなんですが、サマリ版の新書が今はでてるっぽいです。池田さんは働きすぎて壮絶な「戦死」をとげられるわけですが、その後富士通のコンピュータビジネスは大きな問題に直面します。IBM互換の問題です。これもぐぐってもらえばいくらでも情報がでてきますが、かいつまむと、池田さんの時代にIBM互換でないコンピュータを作ったら、ユーザがそれまでIBMのコンピュータ向けに作ったプログラムが(当然)動かず、富士通のコンピュータがあまり売れませんでした。IBMのコンピュータは世界で売れていたので、世界で富士通のコンピュータを売るためには、IBMのコンピュータと互換性のある(IBM向けにつくったプログラムの動く)コンピュータをつくって売ろうと考えたのです。それがいわゆる互換機路線。こっからが本題なんですが、当然IBMが起こって、富士通側にクレームを入れてくるわけです。その交渉の内容を当事者が小説仕立てにしたのが、この2冊の本です。著者はすでにいろんな人がネタバレしていますが、鳴戸道郎さん。2009年に亡くなっています。)病床で書かれたと言われているのが、この2冊の小説です。最初の「雲を掴め」のほうは、IBMと富士通の直接交渉を小説風に再現したものです。後者の「雲の果てに」は第三者機関での仲裁の舞台裏となっています。小説としてはちょっと微妙なんですが、ルイスガースナーの「巨像は踊る」風にリアルなドキュメンタリーとして見ると、とても面白いです。アメリカ人相手の交渉や、弁護士とのやりとりは、「あーこういうの日本人苦手なんだろうなー」と思いながらも、いわゆる根性で乗り切る鳴門さんに、悲しい日本人の性を感じます。この事件は、コンニチ的な意義を見出すのが難しく、「雲の果てに」の後半でも出てきますが、業界としてはメインフレームからダウンサイジングの時代となり、和解締結のあたりになると、完全にPC主導のマーケットになっているんですよね。両者の法務部門ががんばっている間に時代が変わってしまった、というのが数少ない教訓かもしれません。