C2750D4I/C2550D4Iを使ってるシステムで、かつウォッチドッグタイマーを有効にしているなら、今すぐBMCのファームウェアを00.30.00（2017-05-29時点の最新版）に更新した方がよさげ。
以前のファームウェアだと、ウォッチドッグタイマーのリセットがかかる度に、BMCの内蔵フラッシュメモリへ設定のバッグアップが行われてしまっている模様。つまり、タイマーのリセット間隔によっては短時間でBMCのフラッシュが亡くなり、最悪の場合マザボがまな板化するとのこと。
ASRockの更新履歴では「Fix on Watchdog Timer.」と一言しか言及されてないが、割とヤバげなバグな気がす。
ところで最近、うちのC2750D4I with FreeBSD 11は何かの拍子で落ちて勝手にリブートしてることがある。その時は必ず「Processor | FRB2/Hang in POST failure」というイベントが記録されているんだけど、これもファーム更新で直ったりしませんかね…。
参考サイト
変態紳士ASRockの変態マザーC2750D4Iのファン速度を、IPMIで操作する方法のメモ。冷暖房不備の自宅サーバで使ってるもんで、夏場のここぞって時には強制的に回転数を上げたい時があるのだよ。制御方法はipmitoolコマンドでバイト列を投げるだけ。姉妹モデルのC2550D4I, C2450D4I+でも使えるらしい。これならファン制御ソフトのないFreeBSDでも使えるよ、やったねタエちゃん！！
ipmitool raw 0x3a 0x01 ア イ ウ エ オ カ 0x00 0x00
引数ア～カには対応するファンの回転数を指定する。値はPWMのデューティ比だと思われる。
| 引数 | ファン | 値 |
| ア | CPU_FAN1 | 0x01 : Smart Fan（BIOS設定での自動制御）
0x04 : 回転数最小
0xnn : ⇅
0x64 : 回転数最大 |
| イ | CPU_FAN2 |
| ウ | REAR_FAN1 |
| エ | REAR_FAN2 |
| オ | FRNT_FAN1 |
| カ | FRNT_FAN2 |
例えば、全部のファンをフル回転させるには以下のようにする。10進数も通るので、値は4～100で書いたほうが分かりやすいかも。
ipmitool raw 0x3a 0x01 0x64 0x64 0x64 0x64 0x64 0x64 0x00 0x00
実行例。
（最大）
$ sudo ipmitool raw 0x3a 0x01 0x64 0x64 0x64 0x64 0x64 0x64 0x00 0x00
$ ipmitool sdr type 'Fan'
CPU_FAN1 | 0Fh | ok | 7.0 | 1300 RPM
REAR_FAN1 | 11h | ok | 7.0 | 1900 RPM
FRNT_FAN1 | 13h | ok | 7.0 | 1500 RPM
FRNT_FAN2 | 14h | ok | 7.0 | 600 RPM
REAR_FAN2 | 15h | ns | 7.0 | No Reading
CPU_FAN2 | 17h | lnc | 7.0 | 0 RPM
（最小）
$ sudo ipmitool raw 0x3a 0x01 0x04 0x04 0x04 0x04 0x04 0x04 0x00 0x00
$ ipmitool sdr type 'Fan'
CPU_FAN1 | 0Fh | ok | 7.0 | 600 RPM
REAR_FAN1 | 11h | ok | 7.0 | 800 RPM
FRNT_FAN1 | 13h | ok | 7.0 | 500 RPM
FRNT_FAN2 | 14h | ok | 7.0 | 600 RPM
REAR_FAN2 | 15h | ns | 7.0 | No Reading
CPU_FAN2 | 17h | lnc | 7.0 | 0 RPM
（Smart Fan）
$ sudo ipmitool raw 0x3a 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x00 0x00
$ ipmitool sdr type 'Fan'
CPU_FAN1 | 0Fh | ok | 7.0 | 1300 RPM
REAR_FAN1 | 11h | ok | 7.0 | 800 RPM
FRNT_FAN1 | 13h | ok | 7.0 | 500 RPM
FRNT_FAN2 | 14h | ok | 7.0 | 600 RPM
REAR_FAN2 | 15h | ns | 7.0 | No Reading
CPU_FAN2 | 17h | lnc | 7.0 | 0 RPM
なんぞCPU_FAN1の挙動がおかしいけど、他は設定値通りに動いてるようなので気にしない。
尚、本M/BのCPUはファンレスで概ね大丈夫（公式にはヒートシンクを通る風が2CFM未満の場合はファンが必要）なのだが、CPUよりも先にSATAチップの方が音を上げるので、筐体内のエアフローには配慮が必要だ。HDDへ長時間アクセスすると特定のHDDが脱落する現象に見舞われていたが、どうも原因はSATAチップの過熱のようだった。なんたって触れるとアチッとなるくらいだったので。
とりあえずクールスタッフを貼り付けて、マザボを冷やす12cmファンも設置して様子見中。
参考サイト
Steamマシン用に中古のIntel SSDSC2BB600G4を購入した。使用時間24506時間≒1021日、総書込量246775GB≒240TBという中々使い込まれたブツだが、この辺は商品説明に載ってたので納得ずくでの購入である。稼働時間の割に電源投入回数が22回と極めて少なく、240GB/日の書き込み量から推察するに、どっかの業務サーバで使われてたものだろうか。
本SSDはエンプラ用だけあって330TBWもあるので、酷使されてなお一般用SSDと同等の耐久性が残っている事になる。メディア消耗指標を信じると残り1PBくらい書き込める計算だ。ZIGSOWのレビューによれば240GBモデルで905TB書き込めたそうなので、十分ありうる数値かと。
そんなわけで、使い込まれたIntel DC S3500 600GBの簡易ベンチマークなんぞを載せてみる。
-----------------------------------------------------------------------
CrystalDiskMark 5.2.1 x64 (C) 2007-2017 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes
Sequential Read (Q= 32,T= 1) : 502.399 MB/s
Sequential Write (Q= 32,T= 1) : 491.719 MB/s
Random Read 4KiB (Q= 32,T= 1) : 279.477 MB/s [ 68231.7 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 257.936 MB/s [ 62972.7 IOPS]
Sequential Read (T= 1) : 414.177 MB/s
Sequential Write (T= 1) : 462.606 MB/s
Random Read 4KiB (Q= 1,T= 1) : 29.766 MB/s [ 7267.1 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 67.414 MB/s [ 16458.5 IOPS]
Test : 4096 MiB [C: 42.8% (103.8/242.6 GiB)] (x5) [Interval=5 sec]
Date : 2017/04/01 19:29:06
OS : Windows 10 Professional [10.0 Build 10586] (x64)
Intel DC S3500 600GB (240TBW)
目立った性能劣化もなく、至って普通の結果やね。
タイトルの通りでござる（ヽ´ω`）
FreeBSD 11が入っているSSDの入れ替え作業でパーティションを切り直していた際、例によってブートコードを書き込もうとしたら空き容量がないと怒られた。
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada15
gpart: /dev/ada15p1: not enough space
パーティション構成は前のSSDからの丸コピーであるからして、FreeBSD 10から11に更新した時にブートコードの更新をしていなかった、ないし今回のようにエラーが出ていたもののスルーしてたって事になる。FreeBSD 11にしてから5ヶ月経つというのに今まで気付かなかった……。古いブートコードでよく起動できてたなっていう。
念のため調べてみた所、やはりFreeBSD 11.0-RELEASEで/boot/gptzfsbootの容量が87KiBに増え、64KBのパーティションでは物理的に収まらなくなったようだ。エラッタにも、次のような記載がしっかりとなされていた（ヽ´ω`）
[2016-10-21] The size of the GPT enabled ZFS boot blocks (/boot/gptzfsboot) has increased past 64K. Systems upgraded from older releases may experience a problem where the size of the existing “freebsd-boot” partition is too small to hold the new gptzfsboot.
FreeBSD 11.0-RELEASE Errata
さて、これはどうしたもんかね…。まぁどうしたもこうしたもパーティションを拡大するしかないわけだが、ブートパーティションはディスクの先頭にあり、その直後にシステム＆データパーティションが続いているので拡大の余地はないのだよ。このようなパーティション構成は極めて一般的だと思うし、とりわけFreeBSD 8/9時代にRootOnZFS環境を作って乗り継いできた人の殆どにとって頭の痛い問題なんじゃなかろうか。
ディスクの後方に空きがあるなら、そっちにfreebsd-bootパーティションに新設するってのが一番手っ取り早いかも？これはこれで凄い気持ち悪いのと、ブートローダの容量の壁（ディスクの先頭○GB以内に配置しないといけない系のやつ）にハマりそうな気がしなくもないが、2017年にもなって流石にもうないか？gpartのドキュメントによると、freebsd-bootパーティションは他のFreeBSD系パーティションの直前か直後に配置する必要があるそうなので、環境によっては完全に詰む可能性あり。
どうせ作り直すんだったらパーティションを超でっかくしたくなるが、最大545KBまでという制限もあるので要注意。起動時にfreebsd-bootパーティション全体がメモリに読み込まれるそうで、古のコンベンショナルメモリとの絡みから来る容量制限なのかしら？ゆとりの僕にはわかんないんです(・ω<)
これを機にUEFIブートに乗り換えるってのもありかなー。こっちはこっちでESPを確保しなければならないので、全く同じ問題を抱えてるわけですがね！
ちょっと前に家鯖が絶不調で、3.5インチHDD×4台のzpoolにアクセスするとフリーズする現象に見舞われていた。そのフリーズたるや生半可なものではなく、電源ボタン長押しすら受け付けず、コンセントぶっこ抜いた上に暫く放置してからじゃないと電源すら入らないというレベル。
すわ、電源ユニットが死んだか！？と思い早速手配し交換すべくサーバを開腹したところ、電源ファン前のフィルタが埃で目詰まりしていた。不調だったのは単に埃のせいで廃熱がままならず、サーマルプロテクションが動いてただけなんじゃないか疑惑。ま、もう電源買っちゃったし交換しときましたがね…。
こんな感じで、HDD×4台のRAID-Zは比較的短期間のうちに5〜6度に渡る不意の電源断にさらされたわけだが、いくら堅牢なZFSとはいえ流石に耐えられなかったようで。回復不能なエラーが発生し、ファイルが1つお亡くなりになってしまった。
$ sudo zpool status -v
パスワード:
pool: zdata
state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: http://illumos.org/msg/ZFS-8000-8A
scan: scrub repaired 0 in 64h6m with 2 errors on Sun Mar 5 06:42:20 2017
config:
NAME STATE READ WRITE CKSUM
zdata ONLINE 0 0 2
raidz1-0 ONLINE 0 0 4
ada5p1 ONLINE 0 0 0
ada4p1 ONLINE 0 0 0
ada3p1 ONLINE 0 0 0
ada2p1 ONLINE 0 0 0
logs
mirror-1 ONLINE 0 0 0
ada15p4 ONLINE 0 0 0
ada11p4 ONLINE 0 0 0
cache
ada11p5 ONLINE 0 0 0
errors: Permanent errors have been detected in the following files:
/zdata/path/to/broken_file.wmv
scrub中にも電源断が起こったため、このような残念な結果になってしまったのだろう。初回scrubが出来ていれば、恐らくデータが壊れることはなかったと思う（個人的な経験に基づく推測）。
幸いにして死んだファイルはあ〜ん♡な動画だったため大した影響はなかったが、バックアップの重要性を考えさせられる良い機会となった。……とは言ったものの、個人でTBレベルの現実的なバックアップって難しいんだよなぁ。HDDにせよLTOにせよ、その都度引っ張り出してくるようでは面倒になってその内バックアップしなくなるのは目に見えてるし、かといって繋ぎっぱなしじゃバックアップの意味が薄れるし。流行のクラウドは容量も然る事ながら、自分の管理外の場所にデータを置くってのが信用できないし。
あ〜ん♡データの維持もなかなか大変である。
