タイトルの通りでござる（ヽ´ω`）

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にせよ、その都度引っ張り出してくるようでは面倒になってその内バックアップしなくなるのは目に見えてるし、かといって繋ぎっぱなしじゃバックアップの意味が薄れるし。流行のクラウドは容量も然る事ながら、自分の管理外の場所にデータを置くってのが信用できないし。

あ～ん♡データの維持もなかなか大変である。

どこかからの放出品なのか、東芝のエンプラ向けHDD MG030ACA300が安かったので買ってみた。例によってCDMの結果を貼り付け。これまた例によってUSB 3.0変換での結果なので参考程度にオナシャス。

5860533167セクタを6時間42分でゼロクリアできたので、平均書き込み速度は118.6MiB/sという結果に。

速度は至って普通だが、ゼロクリア中の最高温度が60℃（室温26.5℃）と最近のHDDにしてはかなり熱め。アイドル状態で1時間放置しても53℃で、使ったケースがスライディング裸族で放熱性が悪いことを差し引いても熱い気がするなぁ。似たような条件でここまで高温になったHDD見たことないし。実運用では放熱をしっかり考慮する必要がありそう。実家の屋根裏サーバに使うつもりだけど、果たして大丈夫か！？

郵便の再配達で「他の郵便局の窓口でお受け取り」を選択した場合、配送履歴は「最寄局・最寄店送付」を経て「保管中」となる。

受け取る事ができるのは保管中になってからである。「送付」は受取指定したところまで配送中という意味なのでお間違えの無きよう…。なお、2017年2月7日現在の情報なので、遠い未来でこのページを見てる人は要注意。

国際書留には追跡番号がついてるのに、再配達は「お知らせ番号」で管理されてるのは何でなんだろう？二重管理で面倒なだけな気がしてならない…。

家鯖のPHPを5.5から7.1に更新した。

バージョン毎にportsが分かれているソフトを更新するときは、portmasterの-oオプションを使ってportmaster -o 置き換えるports(新バージョン) 置き換えられるports(旧バージョン)とする。そうしないと「php55-5.5.38 conflits with php71-7.1.1 (installs files into same place)」という具合に怒られる。

# sudo portmaster -o lang/php71 php56

PHPの場合、付随するモジュールも更新する必要があり、基本的には同じ方法で行う。しかし、1つずつportmaster -oしなきゃならなくて地味に面倒なんすよね(´・ω・｀)。いい方法がないものかとネットを彷徨っていたら（この時間で手作業で更新できた説）、Stack Overflowに素敵な回答を発見。元のスクリプトだとdistfile削除プロンプトの入力待ちが正しく処理できなかったため、ちょっと改造させて貰った。

$ awk -vPATTERN="55" -vREPLACEMENT="71" \
'BEGIN { while (("pkg query -x %o \"/(mod_)?php" PATTERN "(-|$)\"" \
| getline name) > 0) { oldname = name; sub(PATTERN, REPLACEMENT, name); print "ALWAYS_SCRUB_DISTFILES=dopt portmaster --no-confirm -o " name " " oldname } }' \
| sudo sh

統廃合などで必ずしもモジュールが1対1で対応しなかったり、php-extensionパッケージは上手く扱えなかったりで、エラーなしで一発更新という訳にはいかないのが玉に瑕。でもこのスクリプトで更新作業はかなり楽になるハズ。PATTERNとREPLACEMENTはお使いの環境に応じて書き換えてね(ゝω・)v

• php - upgrading port php55 to php56 - conflict with non-existing helpers - Stack Overflow
• portmaster マニュアル - [SILVER SACKの自画自賛