そもそもきょうはにょほほのハングへコントロールしたかも。
かつきょうpochiがツールまでパワー消費♪
きょう、マウントも移行されたみたい…
*このエントリは、B l o g P e t(ブログペット)の「p o c h i」が書きました。
*このエントリは、BlogPet(ブログペット)の「pochi」が書きました。
2006年6月30日金曜日
（FreeBSD）そのパソコン、無意味に熱くなってませんか？ ――― CPUの消費電力を減らす方法(BlogPet)
pochiが周波数も比例された。
そもそもきょうはにょほほのハングへコントロールしたかも。
かつきょうpochiがツールまでパワー消費♪
*このエントリは、BlogPet(ブログペット)の「pochi」が書きました。
そもそもきょうはにょほほのハングへコントロールしたかも。
かつきょうpochiがツールまでパワー消費♪
*このエントリは、BlogPet(ブログペット)の「pochi」が書きました。
（FreeBSD） smartctlコマンドで表示される属性（Attribute）について
smartmontools（/usr/ports/sysutils/smartmontools）と、rrdtool（/usr/ports/net/rrdtool）と、ちょろっと書いたperlスクリプトとを組み合わせて、定期的にSMARTのAttribute値を採取し、グラフにしてみました。
■ 関連記事
■ １時間あたりのグラフ
Spin Up Time
・・・ディスクが回転を始めた時刻？増加していない。
Seek Time Performance
・・・シークタイム（の何？）
Power On Minutes
・・・電源が入っている時間（分）？
Hardware ECC Recovered
・・・誤り訂正符号（ECC）により修正された回数？
Soft Read Error Rate
・・・一時的なリードエラー（たまたまエラーになっただけでもう一度リードすれば正常）の回数？
Temperature Celsius
・・・温度（単位は摂氏）
■ １日あたりのグラフ
Spin Up Time
Seek Time Performance
Power On Minutes
Hardware ECC Recovered
Soft Read Error Rate
Temperature Celsius
この波形をながめていて、なんとなく想像できること。
- どうやら、Seek Time Performaceは、どんどんカウントアップするカウンタになっていて、ある一定値に達すると、リセットされているらしい。
- Hardware ECC Recovered、Soft Read Error Rateも、アップカウンタなんだけど、どちらかが、先に天井に達すると、両方とも同時にリセットされているらしい。
- マシンが遊んでいるときは、滑らかに上昇し、portupgradeを実行中など、ディスクがガリガリ動いているようなときは、密な、ギザギザ波形（三角波だね）が現れていた。
この属性値の正確な意味、つまり、smartctlコマンドで表示される、Attributeの値の意味が知りたくて、smartctlコマンドのマニュアルを読んでみました。どうやら、結論は、
ハードディスクのベンダーが勝手に決めた値
ってことらしいです。とはいえ、なかなか興味ぶかげな値です。せっかくなので、非常にラフですが、日本語に訳しておきました。
-A, --attributes
Prints only the vendor specific SMART Attributes. The Attributes are numbered from 1 to 253 and have specific names and ID numbers. For example Attribute 12 is "power cycle count": how many times has the disk been powered up.
-A, --attributesオプションを指定すると、ベンダー固有のSMART属性のみを表示する。この属性には、１から２５３までの番号が割り振られていて、特定の名前とID番号がついている。たとえば、属性１２は、「power cycle count」であり、ディスクの電源をこれまで何回入れたか、を表す。
Each Attribute has a "Raw" value, printed under the heading "RAW_VALUE", and a "Normalized" value printed under the heading "VALUE". [Note: smartctl prints these values in base-10.] In the example just given, the "Raw Value" for Attribute 12 would be the actual number of times that the disk has been power-cycled, for example 365 if the disk has been turned on once per day for exactly one year. Each vendor uses their own algorithm to convert this "Raw" value to a "Normalized" value in the range from 1 to 254. Please keep in mind that smartctl only reports the different Attribute types, values, and thresholds as read from the device. It does not carry out the conversion between "Raw" and "Normalized" values: this is done by the disk's firmware.
各属性には、「Raw（生）」値というのがあり、これは、「RAW_VALUE」と書かれた見出しの下に表示され、また、「Normalized（正規化）」値が、「VALUE」見出しの下に表示される。［注：smartctlでは、10進数で表示する］。先ほどの例で言えば、属性１２のRaw値は、おそらくは、ディスクの電源が実際に入れられた回数であり、たとえば、ちょうど過去１年間にわたって、毎日１回、電源を入れたのなら、３６５になる。各ベンダーは、ベンダー固有の変換アルゴリズムにしたがって、Raw値を、１から２５４までの間のNormalized値へ変換する。注意して欲しいのだが、smartctlは、デバイスから読み出したままの、属性タイプ、値、閾値をレポートしている。Raw値とNormalized値との間の変換処理は、smartctlでは行っておらず、ディスクのファームウェアによって変換されている。
The conversion from Raw value to a quantity with physical units is not specified by the SMART standard. In most cases, the values printed by smartctl are sensible. For example the temperature Attribute generally has its raw value equal to the temperature in Celsius. However in some cases vendors use unusual conventions. For example the Hitachi disk on my laptop reports its
power-on hours in minutes, not hours. Some IBM disks track three
temperatures rather than one, in their raw values. And so on.
Raw値を、物理的な単位の値へ変換する方法は、SMARTの規格では規定されていない。たいていの場合、smartctlで表示される値は、感覚的に理解できる。たとえば、温度の属性なら、一般に、Raw値は、摂氏での温度である。しかし、めずらしい表現方法を用いるベンダーがたまにいる。たとえば、私のラップトップPCに入っている日立のディスクでは、power-on hours（パワーオン時間）の単位が、時間ではなく、分でレポートされる。IBMのディスクのうちの一部では、１つではなく、３つの温度を、Raw値で記録している（訳注：訳が間違ってるかも）。などなど。
Each Attribute also has a Threshold value (whose range is 0 to 255) which is printed under the heading "THRESH". If the Normalized value is less than or equal to the Threshold value, then the Attribute is said to have failed. If the Attribute is a pre-failure Attribute, then disk failure is imminent.
また、各属性には、閾値（０から２５５までの範囲）があり、「THRESH」見出しの下に表示される。もしも、Normalized値が、閾値以下の場合、その属性は、failedであるという。その属性がpre-failure属性（訳注：pre-failureについてはこの後に説明がある）の場合、そのディスクは、切迫した故障状態である。
Each Attribute also has a "Worst" value shown under the heading "WORST". This is the smallest (closest to failure) value that the disk has recorded at any time during its lifetime when SMART was enabled. [Note however that some vendors firmware may actually increase the "Worst" value for some "rate-type" Attributes.]
各属性には、「Worst」値というものあり、「WORST」見出しの下に表示される。これは、ディスクのSMART機能が有効にされていて、ディスクが使用されている期間中に記録された、最小（故障する寸前の）値である。［注：ベンダーのファームウェアによっては、「rateタイプ」の属性の「Worst」値を増加させる場合がある］。
The Attribute table printed out by smartctl also shows the "TYPE" of the Attribute. Attributes are one of two possible types: Pre-failure or Old age. Pre-failure Attributes are ones which, if less than or equal to their threshold values, indicate pending disk failure. Old age, or usage Attributes, are ones which indicate end-of-product life from old-age or normal aging and wearout, if the Attribute value is less than or equal to the threshold. Please note: the fact that an Attribute is of type 'Pre-fail' does not mean that your disk is about to fail! It only has this meaning if the Attribute's current Normalized value is less than or equal to the threshold value.
smartctlが表示する属性の表には、属性の「タイプ」も表示される。属性には、Pre-failureと、Old ageの、２つのタイプがある。Pre-failure属性の場合、閾値以下なら、ディスクの故障は保留中であることを意味する。Old ageまたはusage属性の場合、閾値以下なら、製品寿命であることを意味する（訳注：訳がよくわからない）。注意してほしいのだが、属性がPre-failになっていても、そのディスクが故障しかけているという意味ではない。現在のNormalized値が、閾値以下になったときだけ、故障寸前という意味になる。
If the Attribute's current Normalized value is less than or equal to the threshold value, then the "WHEN_FAILED" column will display "FAILING_NOW". If not, but the worst recorded value is less than or equal to the threshold value, then this column will display "In_the_past". If the "WHEN_FAILED" column has no entry (indicated by a dash: '-') then this Attribute is OK now (not failing) and has also never failed in the past.
属性のNormalized値が閾値以下になると、「WHEN_FAILED」見出しの列に、「FAILING_NOW」と表示される。それ以外の場合で、worst値が閾値以下なら、この列には「In_the_past」と表示される。「WHEN_FAILED」列に何の値も入っていない場合（「-」ダッシュで表示される）、その属性は今はOK（故障はしていない）であり、過去にも故障したことはない。
The table column labeled "UPDATED" shows if the SMART Attribute values are updated during both normal operation and off-line testing, or only during offline testing. The former are labeled "Always" and the latter are labeled "Offline".
表の「UPDATE」列に、「Always」と表示される場合、通常動作状態およびオフライン・テスト中に、属性の値が更新されることを意味し、「Offline」の場合は、オフライン・テストのときのみ更新されることを意味している。
So to summarize: the Raw Attribute values are the ones that might have a real physical interpretation, such as "Temperature Celsius", "Hours", or "Start-Stop Cycles". Each manufacturer converts these, using their detailed knowledge of the disk's operations and failure modes, to Normalized Attribute values in the range 1-254. The current and worst (lowest measured) of these Normalized Attribute values are stored on the disk, along with a Threshold value that the manufacturer has determined will indicate that the disk is going to fail, or that it has exceeded its design age or aging limit. smartctl does not calculate any of the Attribute values, thresholds, or types, it merely reports them from the SMART data on the device.
というわけで、まとめ。
Raw属性値は、摂氏の温度、時間、スタート・ストップ回数といった、物理的な意味の値の場合がある。ディスクの製造メーカーは、各自が知っているディスクの動作や故障モードといった詳細な知識に基づいて、Raw値を、１～２５４の範囲のNormarize値へ変換している。Normalized値の、現在の値と、Worst値（最悪値。これまでで記録した最小値）、そして、閾値が、ディスクに記録されている。閾値は、ディスクが故障しそうか、設計寿命か、使用期限か、などを判断するための値であり、メーカー側で決めたものである。smartctlは、属性の値、閾値、タイプなどを変換処理はしておらず、単に、デバイスのSMARTデータをそのままレポートしている。
Note that starting with ATA/ATAPI-4, revision 4, the meaning of these Attribute fields has been made entirely vendor-specific. However most ATA/ATAPI-5 disks seem to respect their meaning, so we have retained the option of printing the Attribute values.
ATA/ATAPI-4 revision 4のときから、属性のフィールドの意味は、ベンダー固有であると決めれていた。しかしながら、ほとんどのATA/ATAPI-5 ディスクがこれらの意味を尊重しているようなので（訳注：？？？）、この属性値を表示するためのオプションを残したままにしている。
For SCSI devices the "attributes" are obtained from the temperature and start-stop cycle counter log pages. Certain vendor specific attributes are listed if recognised. The attributes are output in a relatively free format (compared with ATA disk attributes).
SCSIデバイスの場合、属性は、temperatureとstart-stopサイクルカウンタのログ・ページから読み出される（訳注：？？？）。認識可能ないくつかのベンダー固有の属性も、リストされる。属性は、（ATAディスクの属性と比べると）ややフリー・フォーマットで表示される。
（FreeBSD） lpr: Connection refused
今日、プリンタで印刷しようとして、lprコマンドやlpqコマンドを実行すると、今まで見たことのないエラーが出ることに気がつきました。
こんなエラーです。
% lpr -Pプリンタ ファイル.ps
lpr: Connection refused% lpq -Pプリンタ
lpq: Unable to connect to server
環境変数LANGがja_JP.eucJPだったりすると
% lpq -Pプリンタ
lpq: サーバに接続できません
しばらく、あちこち調べまわって、意外なところに問題が見つかりました。
% which lpr
/usr/local/bin/lpr
% which lpq
/usr/local/bin/lpq
なんと、/usr/local/binですか。普通は、/usr/binのはずです。
こいつは何者だ！？と調べてみると・・・
% pkg_which /usr/local/bin/lpq
cups-base-1.2.0_2
はぁ・・・
どうやら、portupgradeで、cups-baseを最新版にアップデートしたところ、lpr、lpq、lprmという、/usr/binにある印刷関係のコマンドと同名のコマンドが、/usr/local/binにインストールされてしまった、ということでした。
旧バージョンのときは、これらのコマンドはインストールされていなかったのですが、今回から入るようになってしまったようです（まさかパッケージングのミスではないですよね？）。
とりあえず、環境変数PATHを/usr/binを先にして回避することにしました。
☆ ☆ ☆ ☆ ☆
しかし、これもいい機会だということで、CUPSのセットアップでもしようかと思い、ドキュメントを見ながら、試すことにしました。
「えーと、次に、cupsdを実行するのですか。」
・・・cupsdを動かしたら、
/etc/printcapを上書きされてしまいました。
泣く泣く、バックアップのほうから、/etc/printcapを復活させました。
これまでCUPSは使わずに、昔ながらのLPR、LPDでの印刷を行っていたのですが、そろそろ、CUPSを使うようにしたほうがいいんでしょうかね？
2006年6月29日木曜日
（FreeBSD）そのパソコン、無意味に熱くなってませんか？ ――― CPUの消費電力を減らす方法
ここ数日、急に、暑くなってきました。
あぁ、暑い、あつい、熱い、といえば、パソコンも暑くなる原因の１つ。ひどいときには、ファンから、まるでドライヤーのように熱風が吹き出していたり・・・
パソコンが何十台もある部屋があるんですが、1台から出る熱が少なくても、台数が増えてくると、たまりません。パソコンから出た熱をさますために、クーラーががんばるので、クーラーの電力消費量も増えますし、そもそも、熱の発生源であるパソコン自体が、熱の分だけ電力を消費しているわけです。電気を大切にね、と。
というようなわけで、最近のパソコンには、とくになんの仕事もしていないときは、CPUのクロック周波数を低くしたり、CPUの電源電圧を下げたりすることで、電力消費量を減らす仕組みが用意されています。
こういう機能は、一見、バッテリで動くノートパソコンだけの専用機能かと思いがちですが、実は、最近のデスクトップパソコンの多くでも、利用可能になっています。
さてさて、FreeBSDの場合、そのへんの仕組みは、どうなってんのよ？と思い、調べてみました。
わかったこと。
インストールしたまんまの状態では、何もやってません。
おしまい。
なんと、そうだったんですかっ！？
一応、現在の最新バージョンである、FreeBSD 5.5、FreeBSD 6.1の両方で、機能は用意されているのですが、使うように設定しない限り、機能は無効化されています。
というわけで、設定方法から・・・
■ FreeBSDで、消費電力を減らすための設定
/boot/loader.confに、以下の1行を追加します。
cpufreq_load="YES"
/etc/rc.confに、以下の1行を追加します。
powerd_enable="YES"
そして再起動するか、もしくは、以下のようにコマンドを実行して、即座に試してみることも可能のようです。
# kldload cpufreq
# powerd
■ ちょっと待ったぁ！
やるまえに、大切な注意事項のお知らせから。
運が悪いと、OSごとフリーズします・・・
私の場合、数台のデスクトップPCで試してみて、２台でフリーズしました。
だから、デフォルトではこの機能が有効になっていないのかもしれません。
ハングしてもいいマシンで、ハングしても大丈夫な状態にして（たとえば大容量のファイルシステムはumountしておくか、read only mountにしておく）、試しましょう・・・えぇ、私は大失敗しましたから・・・
● その動かなかった例とは・・・
- 1台は、Xeonが2個のってて、かつHyperThreadingが有効になっているマシン。HyperThreadingを無効にしたら、フリーズしなくなりました
- もう1台は、Pentium4が2個のってて、HyperThreadingは無効になっていたマシン。当初、大丈夫そうに見えて、しばらくしたら、急にフリーズしました
SMPになっていると、なんか問題があるんでしょうかねぇ？
● 動いた例
- Athlon64な自作マシン。クロック周波数も変化しますし、電圧も変化していました。
- PentiumM 1000MHz（いわゆるBanias）なノートパソコン。クロック周波数が変化することは確認できましたが、電圧の変化は確認できませんでした（たぶん変化してるんじゃないかな）。
- Pentium4 3GHzなデスクトップパソコン。周波数は変化しましたが、電圧は変化しませんでした。もともと電圧を変化させる機能が無いものかも？
- Xeon 3.6GHzが2個のったPCワークステーション（前述のやつで、HyperThreadingは無効にしている）。周波数は変化しましたが、電圧は変化しませんでした。電圧を変化させる機能があるっぽいのですが、FreeBSDのデバイスドライバが対応していない？
■ ちょっと詳しい話
cpufreqというデバイスドライバが、CPUの処理性能を変化させるインターフェイスになっていて、その裏には、AMDのPowerNow!やCool'n'Quietとか、IntelのEnhanced SpeedStepとかのドライバが実働部隊として控えていて、実際に、クロック周波数や電源電圧を変化させる仕事をしているようです。
powerdというデーモンが、OSの負荷状況に応じて、CPUの処理性能を上下させたりしています。特に重いプログラムを実行していない限り、CPUのクロック周波数が、どんどん下がっていきます。プログラムを実行すると、即座に、元のフルパワーで動き出します。
現在のCPUのクロック周波数は、次のようなコマンドでわかります。
% sysctl -a dev.cpu.0.freq
dev.cpu.0.freq: 1000
この場合、1000となっているので、たぶん、1000MHzのことなんでしょう。
ところで、よくわかってないのですが、CPUが2個あっても、dev.cpu.1.freqってのはでてきません。もしも、CPUが2個とも、同じクロック周波数で動いているとすれば、まあ、1個だけでいいわけですが・・・いまどきのでも、まだ、個別に変えられないんでしたっけ？
さてさて、なにか重いプログラムを実行させておいてから、もう一度見ると
% sysctl -a dev.cpu.0.freq
dev.cpu.0.freq: 2400
ちゃんと、フルパワーで処理しています。
ところで、消費電力は、クロック周波数に比例し、電源電圧の２乗に比例します。たとえば、クロック周波数が2.4GHzから1GHzへ落ちて、電圧が1.25Vから1.10Vへ落ちたとすると、
(1000/2400)*(1.1/1.25)^2
.32266666666666666666
ってことで、消費電力は、元の３２％にまで、削減されます。もっとも、実際には、回路構成とか（clock gatingとか）いろいろな要因で、理論計算式からは誤差が生じますし、パソコンの中で、電力を消費しているのは、CPUだけでなく、ほかにもいろいろあります（ビデオチップとか、チップセットとか、ハードディスクとか、あとロスしている電力とか・・・）。あと、単位の、電力と電力量を間違わないようにね・・・中学校の理科でならうんだっけ？高校？
以下は、MBMONというツールと(/usr/ports/sysutils/mbmonにあります)、rrdtoolというツール（同じく/usr/ports/net/rrdtool）を組み合わせて、CPUなどの温度や、ファンの回転数などを記録しておき、グラフにしたものです。
- 横幅いっぱいで、1日分です。
- クロック周波数は、計測してませんでした。
- 上に上がっている部分が、CPUがフルパワーで回っているときです。
温度
CPUの電源電圧
ファンの回転数
● その他
# sysctl debug.cpufreq.verbose=1
とやると、CPUのクロック周波数が変化している様子が、ログにでてきます。
Jun 27 11:27:20 athlon64 kernel: cpufreq: get returning known freq 2400
Jun 27 11:27:20 athlon64 kernel: cpufreq: get returning known freq 2400
Jun 27 11:27:20 athlon64 kernel: cpufreq: adding abs setting 2400 at head
Jun 27 11:27:20 athlon64 kernel: cpufreq: adding abs setting 2200 after 2400
Jun 27 11:27:20 athlon64 kernel: cpufreq: adding abs setting 2000 after 2200
Jun 27 11:27:20 athlon64 kernel: cpufreq: adding abs setting 1800 after 2000
Jun 27 11:27:20 athlon64 kernel: cpufreq: adding abs setting 1000 after 1800
かなり大量にでてくるので、1度見て満足したら、さっさと止めましょう。
# sysctl debug.cpufreq.verbose=0
■ いろいろ試した例
● Athlon64なマシン
FreeBSD 5.5-STABLE #1: Wed Jun 7 17:40:23 JST 2006
root@ほげ:/usr/src/sys/i386/compile/ほげ
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) 64 Processor 3400+ (2403.09-MHz 686-class CPU)
Origin = "AuthenticAMD" Id = 0xfc0 Stepping = 0
Features=0x78bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2>
AMD Features=0xe0500000<NX,AMIE,LM,DSP,3DNow!>
real memory = 3220373504 (3071 MB)
avail memory = 3150012416 (3004 MB)
（省略）
powernow0: <Cool`n'Quiet K8> on cpu0
となってて、sysctlでみると、こんなかんじ。
ほげ# sysctl -a | grep cpu
kern.threads.virtual_cpu: 1
kern.ccpu: 1948
cpu0: <ACPI CPU> on acpi0
powernow0: <Cool`n'Quiet K8> on cpu0
kern.smp.maxcpus: 1
kern.smp.cpus: 1
debug.cpufreq.lowest: 0
debug.cpufreq.verbose: 0
hw.ncpu: 1
hw.acpi.cpu.cx_supported: C1/0
hw.acpi.cpu.cx_lowest: C1
hw.acpi.cpu.cx_usage: 100.00%
machdep.cpu_idle_hlt: 1
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU1
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 1000
dev.cpu.0.freq_levels: 2400/89000 2200/72000 2000/53000 1800/39000 1000/22000
dev.acpi_perf.0.%parent: cpu0
dev.powernow.0.%parent: cpu0
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
● Xeonが2個なマシン
FreeBSD 6.1-STABLE #7: Tue Jun 13 15:57:03 JST 2006
root@ほげ２:/usr/src/sys/i386/compile/ほげ２
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.16-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0xf41 Stepping = 1
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0x659d<SSE3,RSVD2,MON,DS_CPL,EST,TM2,CNTX-ID,CX16,<b14>>
AMD Features=0x20100000<NX,LM>
Logical CPUs per core: 2
real memory = 3488481280 (3326 MB)
avail memory = 3409637376 (3251 MB)
ACPI APIC Table: <ふがふが>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 6
（略）
cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 122d0000122d
device_attach: est0 attach returned 6
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
est1: <Enhanced SpeedStep Frequency Control> on cpu1
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 122d0000122d
device_attach: est1 attach returned 6
p4tcc1: <CPU Frequency Thermal Control> on cpu1
どうやら、Enhanced SpeedStepが使えていないようです。ソースファイルは
/usr/src/sys/i386/cpufreq/est.c
が該当するようなので、暇があれば、いろいろ調べたり試したりしてみましょうかね。
% sysctl dev.cpu
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 451
dev.cpu.0.freq_levels: 3614/-1 3162/-1 2710/-1 2258/-1 1807/-1 1355/-1 903/-1 451/-1
dev.cpu.1.%desc: ACPI CPU
dev.cpu.1.%driver: cpu
dev.cpu.1.%location: handle=\_PR_.CPU1
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%parent: acpi0
● PentiumMなノートパソコン
OSは、上記とおなじときの、6.1-STABLE。
CPU: Intel(R) Pentium(R) M processor 1000MHz (999.97-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x695 Stepping = 5
Features=0xa7e9f9bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE>
Features2=0x180<EST,TM2>
（略）
cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
となっていて、sysctlで見ると、こんなかんじ。
% sysctl dev.cpu
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 75
dev.cpu.0.freq_levels: 1000/-1 900/-1 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1
% sysctl dev.est
dev.est.0.%desc: Enhanced SpeedStep Frequency Control
dev.est.0.%driver: est
dev.est.0.%parent: cpu0
dev.est.0.freq_settings: 1000/-1 900/-1 800/-1 600/-1
% sysctl dev.p4tcc
dev.p4tcc.0.%desc: CPU Frequency Thermal Control
dev.p4tcc.0.%driver: p4tcc
dev.p4tcc.0.%parent: cpu0
dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1
残念ながら、
% mbmon -d
ioctl(smb0:open): No such file or directory
SMBus[Intel8XX(ICH/ICH2/ICH3/ICH4/ICH5/ICH6)] found, but No HWM available on it!!
No Hardware Monitor found!!
InitMBInfo: Bad file descriptor
となってしまって、mbmonで、CPUの電圧を知ることはできませんでした。
portupgradeとかで負荷をかけたり、いろいろ使ってみて、体感としては、この機能を有効にする前よりは、ファンが高速回転する時間が少なくなったような気がします。気のせいかも。
■ ほかのOSはどうなの？
Windows用のユーティリティは、ちょこっとさがせば、すぐ見つかるでしょう・・・
とりあえず、Linuxな、Fedora Core 5の場合を、ちょっとだけ調べてみました。
マシンは、ラックマウントな1Uサーバで、CPUは、Opteron 250が2個。
実は、最新のBIOSへアップデートしたら、PowerNow!が使えるようになりました。アップデート前は、ACPIまわりがおかしかったっぽいです。
ブート時のログに、こんな風に表示されます。
powernow-k8: Found 2 AMD Athlon 64 / Opteron processors (version 1.60.0)
powernow-k8: 0 : fid 0x10 (2400 MHz), vid 0x2 (1500 mV)
powernow-k8: 1 : fid 0xe (2200 MHz), vid 0x6 (1400 mV)
powernow-k8: 2 : fid 0xc (2000 MHz), vid 0xa (1300 mV)
powernow-k8: 3 : fid 0xa (1800 MHz), vid 0xc (1250 mV)
powernow-k8: 4 : fid 0x2 (1000 MHz), vid 0xe (1200 mV)
cpu_init done, current fid 0x10, vid 0x2
powernow-k8: 0 : fid 0x10 (2400 MHz), vid 0x2 (1500 mV)
powernow-k8: 1 : fid 0xe (2200 MHz), vid 0x6 (1400 mV)
powernow-k8: 2 : fid 0xc (2000 MHz), vid 0xa (1300 mV)
powernow-k8: 3 : fid 0xa (1800 MHz), vid 0xc (1250 mV)
powernow-k8: 4 : fid 0x2 (1000 MHz), vid 0xe (1200 mV)
cpu_init done, current fid 0x10, vid 0x2
そして、普通にFedora Core 5をインストール（Core 3からアップグレード）しただけなんですが、勝手にcpuspeedというのがインストールされて、勝手に動いていて、知らないうちに、よきにはからって、CPUの周波数と電圧をコントロールしてくれていました（xmbmonで、その様子を確認）。
Linuxでは、「/sys/devices/system/cpu/cpu0/cpufreq/」とか「/sys/devices/system/cpu/cpu1/cpufreq/」以下で、CPUのパフォーマンスをコントロールできるようになっているようです。
% ls /sys/devices/system/cpu/cpu1/cpufreq/
/sys/devices/system/cpu/cpu1/cpufreq:
affected_cpus scaling_cur_freq
cpuinfo_cur_freq scaling_driver
cpuinfo_max_freq scaling_governor
cpuinfo_min_freq scaling_max_freq
scaling_available_frequencies scaling_min_freq
scaling_available_governors scaling_setspeed
こんなふうにして、CPUのクロック周波数を確認できます。
（現在の周波数）
# cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq
1000000
（設定可能な最高周波数）
# cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq
2400000
（設定可能な最低周波数）
# cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_min_freq
1000000
ちなみに、「/proc/cpuinfo」でも、今の周波数が見えました。
# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 5
model name : AMD Opteron(tm) Processor 250
stepping : 10
cpu MHz : 1000.000
cache size : 1024 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips : 2004.69
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp
processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 5
model name : AMD Opteron(tm) Processor 250
stepping : 10
cpu MHz : 1000.000
cache size : 1024 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips : 2004.69
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp
2006年6月27日火曜日
最近気になるＣＭ
なんか、海岸で、くまさんがいるんです。
しかも、あぐらをかいで。
で、何かを食べてるんですよね。
むしゃ むしゃ
「おひとついかが？」
「お、こりゃどうも」
ブルーベリーって、海岸にはえてるのでしょうか？
サプリメントでも、流行してますからねぇ。眼にいいとか。
この人は、ムルアカさん・・・じゃないか。
このおっさんは、くまさんからもらっておきながら、自分が木からつんだ実のほうがでっかいぞ、と見せつけたりして、かなり礼儀知らずなところがあります。
というわけで、今度は、「ブルーベリー狩り」だそうです。
ここのＣＭって、以前にも、「でんどろびゅ～む」がずっと頭に残ってしまう、不思議な雰囲気のがありました。
金ちゃんヌードル （２）
今度は、オーソドックスな、普通の「金ちゃんヌードル」。
これが、生まれて初めて食べたインスタントラーメン。やっぱり、これが一番好きかも。
金ちゃんラーメンという袋入りタイプのがあるみたいなんですが、そちらは、見たことがないです。静岡県内でも売ってるのかな？「金ちゃんねぎラーメン」とかいうカップ入りのなら、食べた記憶がありますが、ウェブで見られるパッケージデザインが、記憶の中のものとはまったく違うんです。
■ 前回の記事
2006年6月26日月曜日
朝の散歩
犬に起こされ、朝の６時台に、散歩に連れ出されました。
で、おまえは、また寝るのか！？
数週前のモーニングに掲載されていた「誰も寝てはならぬ （Nessun dorma）」 （サラ イネス著・・・「大阪豆ごはん」と同様に、好きな人にはたまらない、都こんぶみたいなマンガ）にて、飼い猫が、人が読んでいる新聞に乗っかってくるという描写があったんですが、こいつも、しますね。
じっくりと新聞を読んでいるときに、どこからかやってきて、目の前に、横たわってくれます。
彼らにとって、人間が文字を読むという行為を理解できないはずだから、単に、視線が集中している範囲に入り込めば、かまってもらえるとか、思っているのでしょうか。
2006年6月23日金曜日
年をとると、遅れて筋肉痛がやってくる
日曜日に、はしゃぎすぎちゃいましたか。じわじわと、体の節々が痛くなりだし、駐輪場で、自転車をかつぎあげるのも、一苦労。
うわぁ、今日、木曜になって、筋肉痛のピークか・・・
年をとったなぁ。 （しみじみ）
とか思ってたら、なぜか、夕方以降、どんどんだるくなってきて、あらら、熱がある。
明日、会社休んだら、どう思われるだろうか。
2006年6月22日木曜日
（FreeBSD） gvinumをやめてataraidにする
先日の
にあるように、gvinumには、たびたび苦労させられるので、FreeBSDで使える別のソフトウェアRAID機能、ataraidを使ったRAIDへと移行してみました（そのほかに、gmirrorというのもあります）。ちなみに、ataraidは、VIA（だったかな？）のRAIDチップで、BIOSメニューのところで作成できるRAIDドライブも、ataraidの「ar0」として認識されます。
ataraid（atacontrolコマンドで設定する）によるRAID1（mirroring:ミラーリング）は、１年前くらいから別のマシンで使っていて、ごくごく素直に使えているので、今回は、ataraidを選びました。
■ 移行の計画
現在は、ad0,ad1,ad2,ad3の4台のドライブにまたがって、gvinumによるRAID0+1ボリュームを使っています。
- 「ad0とad1」でストライピング
- 「ad2とad3」でストライピング
- ２つのストライピングボリュームを、ミラーリング
ということになっています（だと思った・・・）。
作業手順は、以下のような感じになると思われます。
（１） ad2とad3の中にあるplexを削除する。ad0とad1が残っているので、ミラーリングはされなくなるものの、一応、ファイルシステムにはアクセスできる
（２） ad2とad3のハードディスクを、別のより大容量のドライブへ交換する（ドライブ4台分の容量を、２台でまかなうようにするため）
（３） ad2とad3の２つを使って、ataraidにより、RAID1（ミラーリング）を作成
（４） 新しく作ったRAID1上に、ファイルシステムを作成
（５） gvinumによるボリュームの内容を、ataraidのほうへ全部コピーする
（６） gvinumを使うのを止める。さらば、gvinum！
■ （１）～（２）まで
で、さんざんやりました。gvinumコマンドの中の「rmコマンド」で、subdiskとplexを削除してしまえばOK。
あとは、ごく普通に、ハードディスクドライブを交換する。
■ atacontrolコマンドでのRAID1を作成する
いきなり、失敗しました（いまとなっては笑って話せます）。
「atacontrol create RAID1 ドライブ1 ドライブ2」というコマンドで、RAID1を作成できるはずです。やってみると・・・
# atacontrol create RAID1 ad2 ad3
atacontrol: ioctl(ATARAIDCREATE): Inappropriate ioctl for device
なんか、エラーがでて失敗しました。
あ、そういえば、ATAの同じチャンネルにぶら下がっている、masterとslaveをmirrorすることはできないという話を、どこかで聞いたことがあるような気がします！？（信頼性とか性能とかの面でも、やめといたほうがいいですね）。
というわけで、なぜか、たまたま余っていたATAを増設するのインターフェイス・カードを使って、別のchannelへ振り分けました。
こんな風なディスクの構成になりました。
# atacontrol list
ATA channel 0:
Master: ad0 <Maxtor 4R160L0/RAMB1TU0> ATA/ATAPI revision 7
Slave: ad1 <Maxtor 4R160L0/RAMB1TU0> ATA/ATAPI revision 7
ATA channel 1:
Master: no device present
Slave: no device present
ATA channel 2:
Master: ad4 <Maxtor 4R160L0/RAMB1TU0> ATA/ATAPI revision 7
Slave: no device present
ATA channel 3:
Master: ad6 <Maxtor 4R160L0/RAMB1TU0> ATA/ATAPI revision 7
Slave: no device present
再挑戦です。
# atacontrol create RAID1 ad4 ad6
atacontrol: ioctl(ATARAIDCREATE): Inappropriate ioctl for device
あれれ？また失敗しました。
ハッ！！！
そういえば、カーネルを再構築したときに、ataraidのデバイスドライバを削っちゃっていたのでした・・・
カーネルのコンフィギュレーションファイルの該当部分
# ATA and ATAPI devices
device ata
device atadisk # ATA disk drives
#device ataraid # ATA RAID drives
ataraidの行のコメントを削除して、生かしてやって、カーネル再構築。
3度目の正直。
# atacontrol create RAID1 ad4 ad6
ar0 created
やっとうまくいきました。ad4とad6という２つのドライブから、ar0というRAID1なドライブが作成されました。
RAIDのステータスを確認。
# atacontrol status ar0
ar0: ATA RAID1 subdisks: ad4 ad6 status: READY
あれれ？普通は、この瞬間から、2つのドライブ間で、同期処理が始まるんだと思ってたのですが、なんか、いきなり「READY」ってなってますね。新品のドライブだったからかしらん？？？
/var/log/messagesでは、こんな感じのログがでてます。
Jun 20 18:09:16 ほげ kernel: ar0: 156334MB <ATA RAID1 array> [19929/255/63] status: READY subdisks:
Jun 20 18:09:16 ほげ kernel: disk0 READY on ad4 at ata2-master
Jun 20 18:09:16 ほげ kernel: disk1 READY on ad6 at ata3-master
ググってみると、atacontrol createしたあと、一度再起動している人が何人かいたため、念のため再起動してみたのですが、やっぱりREADY。
ま、いいか。もともと空っぽのディスクなんだし。
■ ar0にファイルシステムを作成する
gvinumでは、「スライスに相当するもの」が作成されるので、そのままnewfsしちゃえばいいのですが、atacontrolで作成するataraidでは、「ドライブに相当するもの」が作成されるので、スライスを切ったり、ディスクラベルを書き込んだりできます。
以前、
では、sysinstallコマンドで、ファイルシステムを作成する方法を紹介しているので、今回は、fdiskコマンドと、disklabel（bsdlabel）コマンドを使った、オーソドックスな方法をば・・・
● fdiskで、スライスを切る
新品のディスクの場合、なんかよく知りませんが、カーネルのほうで、親切にも、デフォルトの値を用意してくれるらしいので、それをそのまま書き込んでしまいます（デフォルト値が違ってたら、一生懸命、正しい値を入力すること）。
# fdisk -i ar0
******* Working on device /dev/ar0 *******
parameters extracted from in-core disklabel are:
cylinders=19929 heads=255 sectors/track=63 (16065 blks/cyl)
Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=19929 heads=255 sectors/track=63 (16065 blks/cyl)
Do you want to change our idea of what BIOS thinks ? [n]
fdisk: invalid fdisk partition table found
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 63, size 320159322 (156327 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 472/ head 254/ sector 63
Do you want to change it? [n] ←このままでいいので変更しない
The data for partition 2 is:
<UNUSED>
Do you want to change it? [n] ←変更しない
The data for partition 3 is:
<UNUSED>
Do you want to change it? [n] ←変更しない
The data for partition 4 is:
<UNUSED>
Do you want to change it? [n] ←変更しない
Partition 1 is marked active
Do you want to change the active partition? [n] ←お好きに
We haven't changed the partition table yet. This is your last chance.
parameters extracted from in-core disklabel are:
cylinders=19929 heads=255 sectors/track=63 (16065 blks/cyl)
Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=19929 heads=255 sectors/track=63 (16065 blks/cyl)
Information from DOS bootblock is:
1: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 63, size 320159322 (156327 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 472/ head 254/ sector 63
2: <UNUSED>
3: <UNUSED>
4: <UNUSED>
Should we write new partition table? [n] y ←「y」と答える
● bsdlabelコマンドでパーティションを切る
これまた親切にも、「bsdlabel -w スライス」で、デフォルトのパーティションを書き込むことができるそうなので、それでいっちゃうことにしました。
# bsdlabel -w ar0s1
（確認してみる）
# bsdlabel ar0s1
# /dev/ar0s1:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 320159306 16 unused 0 0
c: 320159322 0 unused 0 0 # "raw" part, don't edit
全スライス容量が、aパーティションに割り当てられたんですね。ま、いいか。
これが気に入らない場合は、
# bsdlabel -e ar0s1
とやると、エディタ（viとか）が起動するので、そこで、ひたすら、値を書きこむ、という方法もあります。ただ、人によっては、そのやり方はきっと面倒だと思われるでしょうから、最初から素直にsysinstallを使ったほうがいいかもしれませんね。
・・・ところで、sysinstallで、ときどきうまくいかないことがあります。1度失敗すると、もう２度と、成功しなくなるとか。そのときは、経験的に、こうやってます。
- 1度、sysinstallを終了します。
- 新しく作成したパーティションのうち、マウントされているものがあれば、アンマウント（umount）します。
- 新しく作成したスワップパーティションが、すでに使用中になっていることがあります。swapinfoで、使用されているかどうかを見る。使用されていたらそのデバイス名を確認し、swapoffコマンドで、使用停止させます。
- もう一度、sysinstallコマンドを実行します。
たいてい、これでうまくいきます。
● newfsコマンドで、ファイルシステム作成
「-U」は、soft updateを有効にするオプションです。
# newfs -U /dev/ar0s1a
/dev/ar0s1a: 156327.8MB (320159304 sectors) block size 16384, fragment size 2048
using 851 cylinder groups of 183.77MB, 11761 blks, 23552 inodes.
with soft updates
super-block backups (for fsck -b #) at:
160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976,
3387328, 3763680, 4140032, 4516384, 4892736, 5269088, 5645440, 6021792,
6398144, 6774496, 7150848, 7527200, 7903552, 8279904, 8656256, 9032608,
9408960, 9785312, 10161664, 10538016, 10914368, 11290720, 11667072, 12043424,
12419776, 12796128, 13172480, 13548832, 13925184, 14301536, 14677888,
（以下省略）
# bsdlabel ar0s1
# /dev/ar0s1:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 320159306 16 4.2BSD 2048 16384 28552
c: 320159322 0 unused 0 0 # "raw" part, don't edit
● mountコマンドでマウントする
# mount /dev/ar0s1a /mnt
# df /mnt
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ar0s1a 155041638 4 142638304 0% /mnt
えっと、勢いあまって、まちがえて、「mount /dev/ar0s1 /mnt」とやったら、カーネル・パニックしました。気のせいかな。見なかったことにしておこう。
● ファイルシステムの内容をコピーする
これは、dumpコマンドとrestoreコマンドを使うのが定番です。
# cd /mnt （さっきマウントした新しいファイルシステムへchdir）
# dump 0uLf - /なんとか/コピー元ファイルシステム | restore rf -
DUMP: Date of this level 0 dump: Tue Jun 20 18:23:51 2006
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping snapshot of /dev/gvinum/raid (/なんとか/コピー元ファイルシステム) to standard output
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 60740881 tape blocks.
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
warning: ./.snap: File exists
expected next file 10, got 8
DUMP: 3.82% done, finished in 2:05 at Tue Jun 20 20:34:52 2006
DUMP: 8.50% done, finished in 1:47 at Tue Jun 20 20:21:34 2006
DUMP: 13.45% done, finished in 1:36 at Tue Jun 20 20:15:27 2006
コマンドの簡単な意味：
- 0は、レベル0ダンプ
- uは、ダンプ終了後に、/etc/dumpdatesを更新する（いつダンプしたかが記録されている）
- Lは、マウント中のファイルシステムをダンプするときに指定する（本当は、マウントしていない状態でdumpすべき）
- fは、出力先ファイルを指定するもので、「-」を指定していて、これは標準出力を意味している
- 「/なんとか/コピー元ファイルシステム」で、コピー元となるファイルシステムのマウント・ポイント（mountコマンドで指定するパス）を指定します。「/dev/ad0s1e」とかのデバイス名で指定することもできますが、たまに間違える恐れがあるので、パス名の方が安全かも
- 「|」でパイプにして、restoreコマンドに標準出力をつなぎ・・・
- rは、restoreをするの意味
- fは、入力ファイルを指定するもので、「-」を指定しているので、標準入力から読み込む、という意味になる（つまり、dumpの出力を、即、restoreする）
「expected next file 10, got 8」という、気になるメッセージがでていますが、これの意味は、man restoreしてみると、こう書いてあります。
expected next file <inumber>, got <inumber>
A file that was not listed in the directory showed up. This can
occur when using a dump created on an active file system.
きっと、dumpしている間に、dump元のファイルシステムに変更があたんでしょうね（新しくファイルが作成されたとかか？）。
「DUMP: 13.45% done」のように、ときどき、dumpの進行状況と、予想される終了時刻が表示されます。最初のころに表示される予想時刻は、たいていあてになりませぬ。
待ってるのも暇なので、vmstatコマンドで、ディスクへのアクセス状況を見てみるとか。
# vmstat ad0 ad1 ar0 5 （5は5秒ごとに表示の意味）
マウントしたままdumpしたので、dump中にファイルが変更されたり新規作成されたりすると、コピーされないファイルがでてきます。まあ、マウントしたまま、動かしているファイルシステムをまるごとコピーしようとすることに無理があるわけですが、とりあえず、レベル1ダンプして、差分コピーができます。
# dump 1uLf - /なんとか/コピー元ファイルシステム | restore rf -
■ ataraidのRAID1で、ディスクの交換
以前、ドライブがエラーを出して交換したことがあったので、そのときのメモ。
これは、ad4が、新しく交換されたドライブの場合です。
# atacontrol addspare ar0 ad4
# atacontrol rebuild ar0
しばらくして．．．こんなかんじですすんでいく様子が見られます。
# atacontrol status ar0
ar0: ATA RAID1 subdisks: ad4 ad6 status: REBUILDING 8% completed
2006年6月21日水曜日
やった！引っかかってくれたわ！
またもや、「美味しんぼ」の話。
雑誌「スピリッツ」での連載は、もう５年くらい読んでいないので、たまーに、単行本を某古書店で見つけたときに買って読むくらいです。読んだ中で、もっとも最近の作品が、９２巻だったんですが・・・ゆう子さんの悪女というか策士っぷりが、ますます、前面に出てきているようですね。
美味しんぼがグルメ漫画だったのは、もうはるか昔のこと。現在では、おかしな人たちがおかしな騒動を巻き起こす、人間模様のドラマ作品ですか。
あらかじめ仕掛けておいた罠に山岡の旦那がはまりこみ、こっそりと、歓喜するゆう子。
この男の行動は完全に自分の制御下にあることを再確認したゆう子。
夫婦喧嘩のときは、子供を自分側においておき、３対１で、完璧に相手を叩き潰すゆう子。
グルメ漫画っぽいところも、もちろんあるんですが、最近の、魚介類の描き込みは、ちょっとくどすぎて、おいしそうとは思えずに、逆に、グロテスクにさえ感じるんですが、気のせいかな。
2006年6月20日火曜日
（FreeBSD）Netatalkのpapを使ってlprで印刷できない ――― waiting for プリンタ名 to become ready (offline?)
lprで印刷して、lpqでステータスを確認すると、いつまでたっても、
waiting for プリンタ名 to become ready (offline?)
と表示されるだけで、ぜんぜん印刷がはじまらない、というトラブルを目にしました。
（この問題の背景）
プリンタは、某E社のレーザープリンタ（やや古い）で、なぜかlpdプロトコルで印刷すると、プリンタがハングアップしてしまうので、しかたなく、Netatalkを使ってEtherTalkのプロトコルにて印刷をしていました。Netatalkを動かすマシンを、FreeBSD4のマシンから、別のFreeBSD5のマシンに変えたところ、なぜかatalkdが動きだしたあたりで、まったくネットワークの通信ができない状態になってしまうというトラブルが発生し（そうなったり、ならなかったりする、といういやな状況。たぶんドライバの不具合だと思われる）、仕方ないので、またまた別のFreeBSD6なマシンでNetatalkを動かすことにしました。
（症状）
一通りセットアップが終わり、ためしにlprで印刷してみようとすると、
waiting for プリンタ名 to become ready (offline?)
で印刷できない。しかし、papコマンドでPSファイルをプリンタへ送ると、ちゃんと印刷できる。
・・・なんでだろう？1時間弱、悩みました。
（調査結果）
原因は、nullデバイスでした。printcapの書き方次第なので、厳密に言えば、netatalkとは、無関係でした。
Netatalk付属のマニュアルで、psfコマンドのマニュアルを読むと、/etc/printcapでは、たとえば以下のように記述するように説明されています。
プリンタ名|ほげほげ LaserWriter:\
:sh:mx#0:\
:lp=/var/spool/output/プリンタ名/null:\
:sd=/var/spool/output/プリンタ名:\
:lf=/var/log/lpd-errs.:\
:of=/usr/local/libexec/ofpap:\
:if=/usr/local/libexec/ifpap:\
:tf=/usr/local/libexec/tfpap:\
:df=/usr/local/libexec/dfpap:
「lp=～」では、通常、プリンタへデータを出力するためのデバイス名を指定しますが、NetatalkでLaserWriterへ出力するときは、フィルタがプリンタへデータを送信してしまいます（ofとかで呼び出され、psfを経由して、最終的にはpapで送信される）。
よって、lpに指定するものがないので、nullデバイスを指定します。man psfを読むと、netatalkで印刷するプリンタが1台だけの場合なら/dev/nullを指定してもいいけど、2台以上の場合は、プリンタごとにmknodコマンドでnullデバイス作って指定しなさい、みたいに記述されています。
それにしたがって、mknodで「/var/spool/output/プリンタ名/null」というのを作ったのですが、そのとき実行したコマンドが間違っていました。
FreeBSD5のときにセットアップしたときは
# mknod null c 2 2
とやってたので、このまんまFreeBSD6でもやってたのですが、これ、FreeBSD6の場合はダメです。nullデバイスのメジャー番号、マイナー番号が違うんですね・・・
だから、lpで指定されたデバイスをopenして、データを書き込もうとしても、メジャー／マイナーがぜんぜん間違っていますから、openやwriteができず、「waiting for ...」となったわけですね。ああ、納得できた。
てゆーか、FreeBSD6だから番号が違うってわけじゃなくて、いろいろ見てみると、FreeBSDマシンごとに、てんでばらばらです・・・
% ls -l /dev/null
crw-rw-rw- 1 root wheel 0, 24 Jun 19 22:39 /dev/null% ls -l /dev/null
crw-rw-rw- 1 root wheel 0, 23 Jun 19 22:42 /dev/null% ls -l /dev/null
crw-rw-rw- 1 root wheel 0, 15 Jun 19 22:42 /dev/null
0,24だったり、0,23だったり、0,15だったり・・・
FreeBSD5から、devfsというのが導入されていて、/dev以下は、自動的に作成されるような仕組みになったので、メジャー番号、マイナー番号は、固定されていないんですかね。
で、どうしたかっていうと・・・やっちゃダメって書かれていた方法、つまり、printcapのほうで、「lp=/dev/null」と指定することにしました。
だいたい、なぜ/dev/nullを指定してはいけないのか、理由がよくわかりません。/dev/nullをlockするんでしょうか？それで、複数のプリンタで並行して印刷できるはずのジョブが、１つずつ順番に印刷されるようになってしまうとか？ん～、/dev/nullで、そんなことおきるのかなぁ。ぜんぜんわかりません。
これで問題になるかどうか、しばらく様子見です。
/etc/devfs.rulesというファイルを作って、/dev以下に出現するデバイスファイルをコントロールできるみたいなんですが・・・ナナメ読みしただけでは、ハナモゲラで理解できなかったので、まだやってません（rulesetのあたりが、すぐには理解できなかった）。
2006年6月19日月曜日
日本青年館へ
約1年ぶりのライブに行ってきました。
去年は、中野サンプラザでしたが、今回は、2回目の日本青年館。
帰ってきて、今は、サッカー、見てます。
まだ、サイリュームが光ってます。
自分でやりたいと思う方向へ、進んでいけたらいいですね。
あまりにも久しぶりなので、これ↑の入れ方を、すっかり忘れてました。てへへ
（2006-06-19）
影山さんが第1部に出てたのは、コーラスと、スクリーンに映ったシルエットで、すぐに気がつきました。
第1部では、ステージ上にスクリーンが張られていて、スクリーンにはいろんな映像が映し出され、スクリーンの裏側に、バンドのみなさんがいる（隠れている？）という、なんだか、けっこう凝ったステージになっていました。
なぜか、ある曲でだけ（笑）、舞台奥からライトがあてられ、ギターを弾いている人のシルエットがスクリーン上に映し出され、「なんか、わざとらしい演出だなぁ・・・これって、ひょっとして、影さんでは？」と、バレバレでした。
と思ったら、気がついていない人もいたようです。
2006年6月18日日曜日
フルーツ牛乳蒸しぱん
なんか、巷では、フルーツ牛乳がブーム？
蒸しパンにも、フルーツ牛乳ブームが到来？？
ヤマザキのフルーツ牛乳蒸しぱん
水を一切使わずに、北海道の牛乳を使用して蒸しあげました。
ってことで、 「フルーツ」はオマケで、メインは牛乳の蒸しぱん、ってことかな。そういえば、以前、北海道で牛乳が余ってしまって困っているというニュースを見たことがありました。
バナナとオレンジの香りがほんのりとする、さっぱりしたかんじの蒸しパンでした。
☆ ☆ ☆ ☆ ☆ ☆
蒸しぱん むしぱん 虫ぱん？
そういえば、ムシキングパンってのがあって、包装に、昆虫の絵が描かれていて・・・あれはちょっと、食欲がわかないような気がしたのですが、どうなんでしょうか。
最近読んだマンガとか
昨日は、美味しんぼの話だったので、そこからひっぱってみたりして。
美味しんぼ ９２巻「桜エビ大作戦」
この中に収録されている、第3話「牛肉の未来」（前編）。
この話は、牛のＢＳＥ問題、とくにアメリカからの牛肉輸入にかんすることを取り上げていて、まあ、美味しんぼの昔からの読者なら、ああこの作者またやってるな、ってすぐに思ってしまう、そういうタイプのお話ですね。とくにアメリカだしね・・・ってことで。
居酒屋で牛皿を注文した、「富井富雄 東西新聞社 分株副部長殿」。あいにく、牛肉不足で、牛皿は品切れ。お酒もはいってホロ酔いの富井副部長は、いつもながら、大人気なく、それに対して怒り散らす・・・すると、店内には、わざとらしくも、アメリカ産牛肉に関して意見をもつ方々が何人もおり（ふつうの漫画なら苦しい設定ですが、美味しんぼならなんでもありですから）アメリカ産牛肉に関する大論争になる。
ここで、酔った副部長、いつものパターンで、ご乱心。テーブルの上に立ち上がり、お銚子から酒をラッパ飲みし、
「ＢＳＥが怖くて衛星放送が見られるかってえんだ！」
さらには、テーブルで四つんばいになって、牛のものまねをして、テーブルの上はひっちゃかめっちゃか
「子牛音頭行くぞー！」
「♪モォモォー 森の子牛ー 子牛跳ねれば ああ愉快ときたもんだー・・・」
さらにわるいことに、その大騒ぎしている様子が、まことに都合よくたまたまその場にいた帝都新聞の記者によって、
「東西新聞社の無知と無定見」
という、みっともない見出しで記事にされてしまう。
これまで何度も大失敗をしてきた富井副部長ですが、記憶の中では、これが一番最高だと思います。次は、何をやってくれるでしょうか・・・最悪で最高なキャラ、富井副部長の行動は、ますますエスカレートしていくのか！？
☆ ☆ ☆ ☆ ☆ ☆
昨日、アニメの美味しんぼの録画してのを見直したとき、当時放映していたアニメの「花田少年史」のＣＭが入ってました（ＣＭはカットしない主義ですので）。
アニメの花田少年史は、最初、見もしないのにはなから馬鹿にして、こんなのねぇ、とか思っていたら、ふと見てみてみたところ、おおはまりした、そんな作品です。表面的な見た目と、内容とのギャップがすごいんですね。
そんな「花田少年史」が今度、実写映画化されるということで、今発売中の、雑誌「週刊モーニング」（No.29）で、ちょっとだけ映画の特集ページが組まれてたりしてました。
・・・で・・・しばらく見落としていたのですが、実は、表紙に、こっそり（？）と
2007年劇場アニメ『ピアノの森』公開決定
とか描いてあるじゃないですか。なんか、これって、表紙にしか書いてなくて、雑誌の中身では、ぜんぜん触れられていないみたいなんですけど・・・掲載されている「ピアノの森」のページにも、なんも記載なし。
「ピアノの森」は、「花田少年史」の原作者、一色まことが、今、モーニングで連載している漫画です。毎週は掲載されていないし、1話完結ではないので話がどんどん続いていくので、雑誌で読んでいると、けっこうもどかしいです。もともと、ヤングマガジンアッパーズという別の雑誌に掲載されていたのが、しばらくお休みしてて？、ひょっこりと、モーニングでしばらく前に復活した、というもの。「しばらくお休み」って、この作者、前にもあったような・・・
連載再開を記念して、単行本の装丁が変わっています（写真は古いやつ）。
世間では、「のだめカンタービレ」という漫画が大評判だそうですが・・・えーと・・・見たこと無いです。たしか、講談社漫画賞を受賞したとき、「今、一番、音が聞こえてくる漫画」とか称されていたと記憶していますが、私は、
いや、そりゃぁ「ピアノの森」だろう！？
と思いました。それくらい、ピアノの森は、今お気に入りの作品の１つです。
☆ ☆ ☆ ☆ ☆ ☆
その「のだめカンタービレ」となぜかコラボレーションしているのが、「もやしもん」。雑誌「イブニング」で読んでますが、もやしもん、これいいですね。菌をネタにした漫画・・・連載開始当初、自分は面白いと思うけど、これって一般うけしないだろうなぁ。大丈夫かな、とか思っていたのですが、そんな心配は無用のようでした。
☆ ☆ ☆ ☆ ☆ ☆
漫画が実写映画化されて大ヒットした、といえば、映画「ALWAYS 三丁目の夕日」ですが・・・以前、どっちゃりと買ってきたコンビニ本。
「三丁目の夕日」 ［二学期］
これを読んでいて、改めて思ったけど、「この漫画って、ほのぼのしているようで、意外と、人がたくさん死んでる・・・」なと。
- 一平君の同級生、浅野君が、海でおぼれて
- 農家のおじいさん、鬼ジジこと、田所松蔵さん・・・は、実はまだ生きてたか
- 沼田さん一家。地震で長男、空襲で次女、交通事故で長女
- 「けいとうの花」で、結核で療養所に行ったキヨシくんが帰ってくるのを待たず、おばあちゃんがぽっくりと
- 「キャッチボール」では、お父さんがどうやらもう治らない病気。うるうる
ほんの40年くらい前は、まだまだ、死が日常の近いところにあったんだな、と思わされました。最近、犯罪が増えて、世の中がおかしくなっちゃったのは、みんなが病院で死を迎える人が増えたせいだと、誰かが言ってたような気がします。なんか、この漫画を読んで、それもあるのかもと思いました。
2006年6月17日土曜日
「おもてなし」と言えば・・・
まっさきに思いついたのが、
美味しんぼ
「もてなしの心」
漫画の本は実家に置いてあって、今すぐには見られないので、数年前に再放送されたのを録画してあったアニメの美味しんぼを、「マイ・アーカイブ」から引っ張り出してきました。こんなこともあろうかと、資料として保存しておいたものです。なんてね。
唐山陶人が、何十歳も歳の差がある若い女性と結婚。そのお祝いの席で、ひょんなことから、山岡と雄山が料理対決することになる。作る料理は、ご飯とみそ汁。
山岡 「バカな！飯とみそ汁は日本料理の基本だ。そんな簡単なことができないだと！くだらんいいがかりも、休み休み言え！」
雄山 「おお、簡単なこととぬかしたな。今の一言で、おまえが本当にうまい飯とみそ汁をつくれぬことがはっきりしたわ」
山岡 「飯を上手に炊くことが難しいことは承知しているよ。手のこんだ料理にくらべて簡単だといってるだけだ！」
雄山 「語れば語るほど自らのおろかさをさらけだしよるわ。手のこんだ料理より簡単だと？！」
結果は・・・
陶人「ぬぉ！？こ、この飯は！？」
栗田「山岡さんが炊いたご飯より、おいしいわ」
～
陶人 「舌触りにむらがある。羽毛ぶとんと固い綿布団ほどの差がある」
～
陶人 「士郎のみそ汁は、まだ生臭い」
で、そのあげく
雄山 「士郎、この差はどうしてできたと思う。言ってみろ」
山岡 「材料の差だ！米も味噌もしじみも、金の力に物を言わせて最上のものを集めたんだろう。へっ、あんたのやりそうなことだ」
あー、あー、あー、・・・ もう山岡さん、最悪。ボロボロですね。
雄山の料理を作ったのは本村さんという方。かつて雄山が本村さんのお宅を訪問したとき、本村さんは豪華な料理でもてなすことなどできなかったので、米を一粒ずつよりわけたり、自分ができる最大限のことをつくして、来客である雄山をもてなしをした。今回は、そのときの料理を再現。そのもてなしの心が、結果としてでてきたんだよ、っていう、わかりやすいストーリー。
だいたいですね、山岡さん。あなた、おそらく３０歳以上は年上の本村さんのことを、「本村じゃないかぁ」と、呼び捨てにするなんて。しかも相手は「士郎様」と様付けなのに・・・完全に、「いいとこのボンボン」じゃないですか。
ところで、料理中、山岡側では、水をポリタンクに入れてあったけど、本村さん側では、木桶にくんでありましたね。ポリタンクじゃ、水ににおいが移ってしまうと思うのですが、とくにそれには言及していませんでした。アニメオリジナルの演出だったのかな？
☆ ☆ ☆ ☆ ☆ ☆
もう１つ、美味しんぼでの、おもてなしに関するストーリーとして、これは外せないですね。
鮎のふるさと
京都の億万長者、京極さんが、文化部の富井副部長に飲みにつれまわされ、そのあげく、階段を踏み外し、足を怪我して入院。いつもながら、副部長のトラブルメーカーぷりには、あきれます。
京極さんは、退院したときには、山岡に「鮎のてんぷら」をご馳走してもらう、との約束をする。そこへ、海原雄山の登場（BGMにはダースベーダーのテーマがあいそうなシーンでした）。
山岡 「ふざけるな！てんぷらのあげかたくらい、十分に勉強している。鮎だってどんな鮎がうまいか、十分研究している。最良の材料と最高の技術。それ以上、何が必要だと言うんだ！」
雄山 「どうやらまた大事なことがわかっていないようだな」
あーあーあー・・・山岡さん、またですか。雄山の挑発にひっかかってしまったのは仕方ないとしても、また、そんなセリフはいて。ご飯とみそ汁のときに、学習したんじゃなかったんですか？
で、結果は・・・あの名セリフ！
京極 「なんちゅうもんを食わせてくれたんや。なんちゅうもんを・・・こんなうまいもんは食べたことはない。いや、そやない。何十年か昔に食べたおぼえがある。懐かしい味や。うまい。本当にうまい。山岡はんのとは比べ物にならん」
この名セリフは、日常会話にもよく登場するほどですが（ウソ）、このエピソードは、それくらい記憶に残る、名作ですね。
京極さんの出身地である四万十川の鮎をもってきた雄山。
雄山 「料理は、人の心を感動させて、はじめて芸術たりうる。たが、今のお前は、どんな料理を作ったところで、材料自慢、腕自慢の、低俗な見せびらかし料理で終わるだろう。そんなおまえが究極のメニュー作りなどと。笑わせるな！」
もうね、雄山、あんたの圧勝だよ・・・あんた、最高！
吼えまくる雄山。ああ、あのころの雄山はすごかった。連載当初は、イヤミたっぷりのいや～な奴だったけど、すぐにキャラがいい形に定まってきた。この２つのエピソードのころが、脂がたっぷりのった、一番エネルギッシュなころだったんじゃないかな。
もう最近は、息子の嫁にいいように扱われ、孫も生まれて、すっかり枯れたおじいちゃんだね・・・
2006年6月16日金曜日
smartmontoolsをちゃんと活用したいな
今日は、
のつづき、というか、落穂ひろいというか、実は単に、お茶をにごす話。ネタ切れというか、時間切れというか・・・
前回、
「914 hours (38 days + 2 hours)」のように、時間みたいなのが出ていますが、これが、いつエラーが発生したかのことなんですが、ドライブの中にある謎の時計で測っているらしく、いつのことだかよくわかんないです。
とか
ついさっきself testを実行したんですが、その結果が「Completed without error」と記録されています。「1016」が、ハードディスクドライブの“腹時計”の値ですね。だから、この値と、Error発生時の値の差から（値の単位は、１時間＝６０分です）、いつエラーが発生したのか、私は判断しています。もちっと、わかりやすく見る方法はあるのかな？
とか言ってましたが、smartctlの結果を、先頭から眺めていたら、なにか、気になるものが・・・
「smartctl -a デバイス」もしくは「smartctl -A デバイス」というコマンドを実行して、「SMART Attributes Data Structure ほにゃらら」というところを見ます。
たとえば、こんなかんじ。
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 061 060 006 Pre-fail Always - 145508798
3 Spin_Up_Time 0x0003 097 096 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 0
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 083 060 030 Pre-fail Always - 231159823
9 Power_On_Hours 0x0032 094 094 000 Old_age Always - 5881
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 91
194 Temperature_Celsius 0x0022 044 050 000 Old_age Always - 44
この中に、「9 Power_On_Hours」というのがあって、5881とあるじゃないですか。
あ！これかぁ！
セルフテストのログを見てみました。
最近は、毎晩１回実行しているので、LifeTimeが24時間くらいずつ増えてます。
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 6894 -
# 2 Short offline Completed without error 00% 6871 -
# 3 Short offline Completed without error 00% 6849 -
# 4 Short offline Completed without error 00% 6827 -
えーと、6894ですか・・・あれ？5881と6894・・・やっぱり、ぜんぜん違う値だな。なんなんだ、この腹時計は！？
やっぱり、ATAの規格書を読まないといけないのかなぁ。
とりあえず、まずはsmartmontoolsのドキュメントをちゃんと読むか。
☆ ☆ ☆ ☆ ☆ ☆
「SMART Attributes Data Structure ほにゃらら」というところの、最後の値って、けっこう頻繁に変化していたんですね。
どういう値を採取できるのかは、ドライブの種類（型番）ごとに異なっているようですが、たとえば、さっきみたドライブでは、Temperature_Celsius（摂氏単位の温度／でもどこを測ってるの？）とか、「Hardware_ECC_Recovered」、「Reallocated_Sector_Ct」、「Raw_Read_Error_Rate」などなど、興味深げな値が採取できているようです。
これを定期的に採取して（recommended polling time: ( 1) minutes.と書いてあるので、1分ごとですか）、その値を、rrdtoolでグラフにしてみるとおもしろいかもしれません。これから、perlスクリプトでも書いてみますか。
・・・ただ、rrdtoolの使い方がよくわからないんですけど。ハナモゲラだなぁ・・・
2006年6月15日木曜日
（VMware）FreeBSD 6.1Rのカーネル再構築（２） 不要なモジュールをビルドしないようにする
ふと思い出したので、先日のお話・・・
のつづきというか、落ち穂ひろいです。
カーネル再構築は、けっこう時間がかかります。VMwareの仮想マシンでやってるので処理が遅くなる、っていう理由もあるのですけれども、とくに、初めて実行したときは、たくさんのファイルをコンパイルするので、時間がかかります。
ええ、たくさんのファイルをコンパイルしてるのですが、実は、いらないもの、使いもしないものを、無駄にコンパイルしてたりしています。そのいらないものってのは、
カーネル・モジュール（*.ko）のほとんど
です。通常、/boot/kernel/というディレクトリの中に、カーネルのファイル（kernel）と一緒に、*.koという名前のファイルが大量に入っています。
> cd /boot/kernel/
> ls *.ko
3dfx.ko if_ex.ko ng_ppp.ko
3dfx_linux.ko if_faith.ko ng_pppoe.ko
aac.ko if_fatm.ko ng_pptpgre.ko
aac_linux.ko if_fe.ko ng_rfc1490.ko
accf_data.ko if_fwe.ko ng_socket.ko
（多すぎるので以下省略。全部で449個ありました）
一方、このなかで、実際に使っているものは何か？っていうと、kldstatというコマンドで、今ロードされているモジュールの一覧が表示されます。
これは、たとえば、ってことで極端な例ですが、
> kldstat
Id Refs Address Size Name
1 3 0xc0400000 3c02dc kernel
2 1 0xc07c1000 66190 acpi.ko
1番はカーネル、2番がacpiのモジュール、・・・それだけ。
つまり、449個中、1個しか使ってないわけで、ほかは、ただの「ディスクの肥やし」。肥やしを作るのに、馬鹿にならないくらい時間がかかってるんです。
そりゃぁないじゃん・・・というわけで、いらないモジュールはコンパイルしない／必要なモジュールだけをコンパイルする方法、ってのがちゃんとあります。
■ /etc/make.conf
/etc/make.confというファイルがあって、これは、FreeBSDでいろんなプログラムをコンパイルするとき（カーネルやportsも）、コンパイル条件などを指定するファイルです。「man make.conf」で、詳しい説明が見られますし、/usr/share/examples/etc/make.conf に、サンプルが載っています。
このmake.confに、たとえば、
NO_MODULES=true
とかいておくと、カーネル再構築のときに、モジュールが一切コンパイルされなくなります。
ちなみに、man make.confを見るとわかりますが、注意事項が１つあります。manを見ると、NO_MODULESにはboolと書かれています。boolというのは、変数（てゆーかマクロか？！）が定義されているかいないか、だけに意味があるので、
NO_MODULES=false
と書いてあっても、やっぱり、モジュールはまったくコンパイルされなくなります。
さてさて、これだと、acpi.koも作られなくなってしまうので、ちょっと困ってしまいます。
ほしいモジュールだけコンパイルして欲しい場合は、MODULES_OVERRIDEで指定します。たとえば、
MODULES_OVERRIDE="linux acpi/acpi"
とかくと、linux.koとacpi.koだけが作られます。
ちゃんと調べてないですが、どうやら、MODULES_OVERRIDEに指定するのは、ディレクトリ/usr/src/sys/modules以下にあるディレクトリ名だと思われます。
> ls /usr/src/sys/modules/
3dfx ichwd procfs
3dfx_linux ida pseudofs
Makefile idt pst
Makefile.inc ie puc
aac if_bridge ral
（長いので以下省略）
acpiというディレクトリの中には、さらに、ディレクトリがあるので・・・
> ls /usr/src/sys/modules/acpi/
Makefile acpi acpi_fujitsu acpi_panasonic acpi_toshiba
Makefile.inc acpi_asus acpi_ibm acpi_sony acpi_video
MODULES_OVERRIDE="acpi" と、「acpi」とだけ指定してカーネル再構築を行った場合は、
> ls /boot/kernel/acpi*
/boot/kernel/acpi.ko /boot/kernel/acpi_panasonic.ko
/boot/kernel/acpi_asus.ko /boot/kernel/acpi_sony.ko
/boot/kernel/acpi_fujitsu.ko /boot/kernel/acpi_toshiba.ko
/boot/kernel/acpi_ibm.ko /boot/kernel/acpi_video.ko
というような、acpiディレクトリ内のすべてがコンパイルされました。そのため、「acpi/acpi」というように限定してみました。
MODULES_OVERRIDE="linux acpi/acpi"と指定して、カーネルを再構築してみました。
freebsd# make install
thiskernel=`sysctl -n kern.bootfile` ; if [ ! "`dirname "$thiskernel"`" -ef /boot/kernel ] ; then chflags -R noschg /boot/kernel ; rm -rf /boot/kernel ; else if [ -d /boot/kernel.old ] ; then chflags -R noschg /boot/kernel.old ; rm -rf /boot/kernel.old ; fi ; mv /boot/kernel /boot/kernel.old ; sysctl kern.bootfile=/boot/kernel.old/"`basename "$thiskernel"`" ; fi
kern.bootfile: /boot/kernel/kernel -> /boot/kernel.old/kernel
mkdir -p /boot/kernel
install -p -m 555 -o root -g wheel kernel /boot/kernel
cd ../../../modules; MAKEOBJDIRPREFIX=/usr/src/sys/i386/compile/VMware/modules MODDIR=/boot/kernel MODULES_OVERRIDE="linux acpi/acpi" MACHINE=i386 KERNBUILDDIR="/usr/src/sys/i386/compile/VMware" make install
===> linux (install)
install -o root -g wheel -m 555 linux.ko /boot/kernel
===> acpi/acpi (install)
install -o root -g wheel -m 555 acpi.ko /boot/kernel
kldxref /boot/kernel
インストールされたのは、これだけです
freebsd# ls /boot/kernel
acpi.ko kernel linker.hints linux.ko
■ /etc/make.conf は影響範囲が大きすぎる
/etc/make.confに書いた内容は、カーネルをコンパイルするとき以外に、portsからソフトをインストールするときにも効いてしまいます。たまたま同じ変数を参照する、異なるportsがあったりすると、両方のportsに効いてしまうわけですね。
カーネル再構築の話から脱線しちゃいますが、ついでに書いときます。
portsの場合は、/usr/local/etc/pkgtools.confというファイルの、MAKE_ARGSというところで、パッケージごとに、オプションを指定できるようになっています（ちょっと記述方法が独特で迷うかもしれませんが）。このファイルはportupgradeをインストールすると作られます。
make.confに書かずに、pkgtools.confのMAKE_ARGSに書いておいてから、
portinstallコマンドで、portsをコンパイルします。
はい、ここ重要です！！「makeコマンド」でコンパイルしちゃうと、pkgtools.confは参照されません（make.confは参照されるんですけどね・・・）。
portsのコンパイルがはじまった直後に、pkgtools.confからどういうオプションが適用されたかが表示されるので、慣れないうちは、その表示を念入りに確認するといいでしょうね。
■ makeoptionsでカーネルごとに個別指定できる
カーネル再構築の場合は、どうするか？
べつにmake.confでもいいかもしれませんが、1台のFreeBSDマシン（処理が高速なマシン）で、別のマシン（処理がのろいマシン）のカーネルをコンパイルするようなケースがあるので、そういうときは、カーネルごとに、別のコンパイルオプションを指定したいです。make.confを毎回書き換えるっては、スマートじゃありません。
・・・ってことで、ちゃんと方法があります。
カーネルのコンフィギュレーション・ファイルに、
makeoptions MODULES_OVERRIDE="linux acpi/acpi"
のように書きます。ファイルにこのように書き込んでおいてから、「config ファイル」を実行して、カーネルをコンパイルすればいいだけです。これなら、カーネルごとに、異なるオプションを指定できます。
ところで、この書き方は、/usr/src/sys/conf/NOTES というファイルを見てて学びました。このファイルと、あと/usr/src/sys/i386/conf/NOTESには、カーネル・コンフィギュレーション・ファイルの書き方のヒントがたくさんのっています。
それと、「man 5 config」と実行すると、カーネルのコンフィギュレーション・ファイルの書式など、ごく基本的な情報が得られます。
■ VMwareの中のFreeBSD用カーネル・コンフィギュレーション・ファイル
上記を反映し、もうちょっと見直して、コンフィグファイルを書き変えてみました。
makeoptions MODULES_OVERRIDE="～"を追加して、IPv6も削除しちゃいました。splashも削ってしまっているので、スクリーンセーバーも使えなくなっているかと思います（まあ、VMwareの中では不要でしょう）。
machine i386
cpu I686_CPU
ident VMware
options SCHED_4BSD # 4BSD scheduler
options PREEMPTION # Enable kernel thread preemption
options INET # InterNETworking
options FFS # Berkeley Fast Filesystem
options SOFTUPDATES # Enable FFS soft updates support
options UFS_ACL # Support for access control lists
options UFS_DIRHASH # Improve performance on big directories
options MD_ROOT # MD is a potential root device
options NFSCLIENT # Network Filesystem Client
options NFSSERVER # Network Filesystem Server
options NFS_ROOT # NFS usable as /, requires NFSCLIENT
options MSDOSFS # MSDOS Filesystem
options CD9660 # ISO 9660 Filesystem
options PROCFS # Process filesystem (requires PSEUDOFS)
options PSEUDOFS # Pseudo-filesystem framework
options GEOM_GPT # GUID Partition Tables.
options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!]
options COMPAT_FREEBSD4 # Compatible with FreeBSD4
options COMPAT_FREEBSD5 # Compatible with FreeBSD5
options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI
options KTRACE # ktrace(1) support
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extension
s
options KBD_INSTALL_CDEV # install a CDEV entry in /dev
options ADAPTIVE_GIANT # Giant mutex is adaptive.
device apic # I/O APIC
device pci
device ata
device atadisk # ATA disk drives
device atapicd # ATAPI CDROM drives
options ATA_STATIC_ID # Static device numbering
device scbus # SCSI bus (required for SCSI)
device da # Direct Access (disks)
device atkbdc # AT keyboard controller
device atkbd # AT keyboard
device psm # PS/2 mouse
device vga # VGA video card driver
device sc
device agp # support several AGP chipsets
device pmtimer
device lnc # NE2100, NE32-VL Lance Ethernet cards
device loop # Network loopback
device random # Entropy device
device ether # Ethernet support
device tun # Packet tunnel.
device pty # Pseudo-ttys (telnet etc)
device md # Memory "disks"
device bpf # Berkeley packet filter
device uhci # UHCI PCI->USB interface
device usb # USB Bus (required)
device ugen # Generic
device umass # Disks/Mass storage - Requires scbus and da
device sound
device snd_es137x
makeoptions MODULES_OVERRIDE="linux acpi/acpi"
「VMware.FreeBSD.CONFIG2.txt」をダウンロード
2006年6月14日水曜日
（FreeBSD）恐怖のgvinum
昨日の話に登場したハードディスクを、交換しました。
新品のドライブに交換して、RAID（ストライピング＋ミラーリング）を再構築しようとしたら・・・カーネル・パニック！
え？？？？？？？？？
RAIDといっても、ソフトウェアRAID。
FreeBSDのgvinum（GEOM VINUM）という機能で実現されているソフトウェアRAIDです。これ、世間では、やたらと評判が悪いようです。ええ、個人的にも、最悪だと思っています。はい。
もともと、FreeBSDにはvinumというソフトウェアRAID機能があって、かつてはそれを使っていました。GEOMという新しいメカニズムが導入されたときに、これまでのvinumがうまく動かなくなったそうです。そのときは、gvinumという新しいのを用意したので、それを使えばいい、みたいな話になりました。すなおにそれに従って、gvinumへ移行したのですが・・・このgvinumが最悪。
何が最悪って、gvinumの気に障ることをしでかすと、即、panicが発生・・・
まるで腫れ物に触るかのように、gvinumを扱わないといけません。
で、もう１つ悪いことに、gvinumって、vinumを完全に置き換えるものではないのです。vinumにあったのにgvinumではまだ実装されていない機能ってのがたくさんあります。gvinumのマニュアルやhelpコマンドで、コマンド名がずらずら～と表示されるのですが、それらのほとんどが、実装されていません。
もうね、今日なんか、gvinumコマンドのソースコードを見ながら、操作方法を探しちゃいましたよ・・・
たとえば、「printconfig ファイル名」で、ファイルに設定を保存できるはずなんですが、実際には、ファイルに保存する機能は実装されていません。画面に表示されるだけなんです。ソースコードを見てたら、すぐにわかりました。そういや、stopコマンドもなんか変です。
なんとか、３回ほどpanicしたあと、復旧した・・・と思ったら、なんかまだ変です。
「degraded」って出てるんですけど。
gvinum -> l
4 drives:
D drive1 State: up /dev/ad1s1e A: 0/77888 MB (0%)
D drive3 State: up /dev/ad3s1e A: 1828/77888 MB (2%)
D drive2 State: up /dev/ad2s1e A: 0/76060 MB (0%)
D drive0 State: up /dev/ad0s3e A: 0/77888 MB (0%)
1 volume:
V raid State: up Plexes: 2 Size: 152 GB
2 plexes:
P raid.p0 S State: degraded Subdisks: 2 Size: 152 GB
P raid.p1 S State: up Subdisks: 2 Size: 148 GB
4 subdisks:
S raid.p0.s1 State: I 97% D: drive1 Size: 76 GB
S raid.p0.s0 State: I 97% D: drive0 Size: 76 GB
S raid.p1.s0 State: up D: drive2 Size: 74 GB
S raid.p1.s1 State: up D: drive3 Size: 74 GB
plexが2つあって、微妙にサイズが異なるので、なんかおかしくなっているのかな？
新しいドライブに交換したのは、drive1なので、raid.p0というほう。
あーもー、やだ。gvinumには、もうつきあいきれない！！
これって、けっこう昔セットアップした、80GBのドライブ4台からなるRAIDなんですが、いまじゃ、ドライブの容量もずっと増えてるので、もはや、4台も使う必要はなくて、2台を使ってミラーリングするだけで、十分な気がしてきました。
幸いなことに、FreeBSDには、gvinum以外にも、RAIDを実現する機能として、ATA RAIDと、GEOM MIRRORの2つがあるし、近いうちに、そっちへ乗り換えようと思います。
（本音： 昨日の話にもでてきた3ware製のRAIDカードが、ものすごくまともに素直に動いているので、予算さえつけば、そっちにしたいところです）
☆ ☆ ☆ ☆ ☆ ☆
今日、何回かkernel panicを発生させて、だいたい、gvinumのあやし方がわかってきたようなきがします。以下は、経験で学んだことで、正しい操作方法ではないかもしれません。その証拠に、上記のように、復旧できてませんから・・・
今回drive1というのが新しいドライブへ交換されたのですが、ドライブを交換したときは、
まず、「rm raid.p0.s0」とか「rm raid.p0.s2」、「rm raid.p0」というように、「rm」コマンドで、壊れた側のplexを削除してしまいました。rmできないこともあって、そういうときは、再起動したらrmできました。なんだかよくわかりません・・・
つぎに、「create」コマンドで、driveだけ定義しました。createコマンドを実行すると、現在の設定がコメント形式で表示されますが、以下の、driveだけ、定義してやりました。
drive drive0 device /dev/ad0s3e
drive drive1 device /dev/ad1s1e
drive drive2 device /dev/ad2s1e
drive drive3 device /dev/ad3s1e
ちなみにdrive1だけを定義してやったら、カーネルパニックしました。
運良く、このcreateコマンドが成功したので、つぎに、もう1度createコマンドを実行し、空のplexを定義（さっきと同様に、以下の1行だけ残して、残りはコメントアウトされたままに）。
plex name raid.p1 org striped 1024s vol raid
これも成功。最後に、もう1回createコマンドを実行。
sd name raid.p0.s0 drive drive0 plex raid.p0
sd name raid.p0.s1 drive drive1 plex raid.p0
これで、あとは、「start raid.p0」を実行したかしなかったか忘れましたが、データの同期処理が始まりました。
（で、いまだにdegradedのままである、というオチ）
ドライブのサイズが違っちゃっているので、正常なplex、raid.p1と同じサイズになるように、subdisk（sd）を定義するときに、lengthを指定すればいいのかなぁ？
でも、それをやって、またカーネル・パニックしたらいやだし・・・
（2006-06-21 追記）
subdiskのサイズをそろえてみたところ、うまくいきました。
- rmコマンドで、既存のplexとsubdiskを削除
- createコマンドを実行し、sdでsubdiskを定義するときに、lenで、既存のsubdiskと同じサイズを指定する
- 神に祈る！
これで、見事、gvinumによる、RAID0+1ボリュームが復活しました。
gvinum -> printconfig
# Vinum configuration of palomino.cad.flab.fujitsu.co.jp, saved at Fri Jun 16 17:21:41 2006
drive drive1 device /dev/ad1s1e
drive drive3 device /dev/ad3s1e
drive drive2 device /dev/ad2s1e
drive drive0 device /dev/ad0s3e
volume raid
plex name raid.p0 org striped 1024s vol raid
plex name raid.p1 org striped 1024s vol raid
sd name raid.p0.s1 drive drive1 len 155770880s driveoffset 265s plex raid.p0 plexoffset 1024s
sd name raid.p0.s0 drive drive0 len 155770880s driveoffset 265s plex raid.p0 plexoffset 0s
sd name raid.p1.s0 drive drive2 len 155770880s driveoffset 265s plex raid.p1 plexoffset 0s
sd name raid.p1.s1 drive drive3 len 155770880s driveoffset 265s plex raid.p1 plexoffset 1024s
gvinum -> l
4 drives:
D drive1 State: up /dev/ad1s1e A: 1828/77888 MB (2%)
D drive3 State: up /dev/ad3s1e A: 1828/77888 MB (2%)
D drive2 State: up /dev/ad2s1e A: 0/76060 MB (0%)
D drive0 State: up /dev/ad0s3e A: 1828/77888 MB (2%)
1 volume:
V raid State: up Plexes: 2 Size: 148 GB
2 plexes:
P raid.p0 S State: up Subdisks: 2 Size: 148 GB
P raid.p1 S State: up Subdisks: 2 Size: 148 GB
4 subdisks:
S raid.p0.s1 State: up D: drive1 Size: 74 GB
S raid.p0.s0 State: up D: drive0 Size: 74 GB
S raid.p1.s0 State: up D: drive2 Size: 74 GB
S raid.p1.s1 State: up D: drive3 Size: 74 GB
登録:
投稿 (Atom)