OpenZFS Developer Summit 2018を眺めてたら、Device Removalなるスライドを発見。タイトルの通りvdevの取り外しに関する機能である。

ご存知の通りZFSでは、一度プールに組み込んだデバイスの削除に非常に厳しい制約がある。プールのスケールアップは極めて容易な一方、スケールダウンは事実上不可能だった。しかしDevice Removalによって、ミラー構成のvdev限定ではあるものの削除が可能となる。

嬉しい人には嬉しいと思われるこの機能、なんとFreeBSD 11.2-RELEASEで既に取り込まれてた。11.2Rのmanから説明を引用してみる。

Removes the specified device from the pool. This command currently only supports removing hot spares, cache, log devices and mirrored top-level vdevs (mirror of leaf devices); but not raidz.

スライドの方にしか書いてないけど、この機能でミラー構成トップレベルvdevを削除するには、各vdevのashiftが同量じゃないと駄目らしい。ashiftはvdev単位での設定なので、デバイス追加時は注意が必要。

RAID-Zでも使えるようになってほしいけど、実装面ではRAID-Z Expansion頼みかしら…？こっちの進捗具合はどうなってんだろうなー。去年のちょうど今ごろRAID-Z Expansionに関する記事を書いたものの、とんと続報がない。FreeBSD 12で実装見込みとのことだったが、十中八九間に合わないだろうなー。現時点で12.0Rは12月頭のリリース予定だし…。

家のFreeBSDサーバのportsたちをportmasterで更新していたところ失敗するやつがあった。失敗自体は取り立てて珍しいことでもないが、今回はThis command has been saved to /tmp/portmasterfail.txtという見慣れない行が現れた。メッセージの通り、失敗した時の結果が保存されるらしい。中身はというと…

portmaster <flags> lang/php71-extensions graphics/php71-gd x11/libXpm x11-toolkits/libXt x11/libICE x11/xorgproto x11/libSM x11/libX11 x11/libXau x11/libxcb devel/check x11/libXdmcp x11/xcb-proto x11/libXext math/php71-gmp security/php71-filter security/php71-mcrypt security/libmcrypt security/php71-openssl sysutils/php71-fileinfo sysutils/php71-posix textproc/php71-ctype textproc/php71-dom textproc/php71-simplexml textproc/php71-xml textproc/php71-xmlreader textproc/php71-xmlwriter www/php71-opcache www/php71-session

あ、うん、はい（白目

失敗部分のログが保存されてるかと思いきや、portmasterコマンドのログだけだった…。この機能は2017/2/3のportmaster 3.17.10で実装されたっぽい。まぁ、何も無いよりはマシか。

ちなみに今回の直接の失敗原因はxorgprotoとglprotoの競合だった。

===>  Installing for xorgproto-2018.4
===>  Checking if xorgproto already installed
===>   Registering installation for xorgproto-2018.4 as automatic
Installing xorgproto-2018.4...
pkg-static: xorgproto-2018.4 conflicts with glproto-1.4.17 (installs files into the same place).  Problematic file: /usr/local/include/GL/glxint.h
*** Error code 70

Stop.
make: stopped in /usr/ports/x11/xorgproto

こういう時はまず/usr/ports/UPDATINGを見てみる。特にportsの競合の場合は大抵解決策が書いてある。今回も見事に書いてあった。

20180731:
  AFFECTS: users of x11/xorg and all ports with USE_XORG=*proto
  AUTHOR: zeising@FreeBSD.org

  The xorg *proto packages have all been merged into one package,
  x11/xorgproto.  This might cause issues with upgrading.  If you
  get conflicts between xorgproto and old *proto packages, please
  remove the old package and install xorgproto again.

  In order to remove all orphaned ports, including all *proto port,
  the following can be used after the ports tree has been updated:
  pkg version -l \? | cut -f 1 -w | grep -v compat | xargs pkg delete -fy

X.orgのproto系パッケージがx11/xorgprotoに統合されたために、glprotoと衝突した事がわかる。最終行のコマンドを実行して解決。失敗したportmasterコマンドを再実行してインストール完了。あ、この時にportmasterfail.txtが役立つのか！

Emacs上でソースコードのコンパイルを行うにはM-x compileコマンドを使う。するとmakeが走り、結果がCompilatinバッファに表示され、M-x next-errorなどでエラー行に一発ジャンプ出来て超便利ッ……という所までは良く語られる。が、しかーし、肝心のMakefileの指定方法に触れている解説が少ない。

実際のところ、M-x compileのmakeの引数指定のところで書いてやればいいのだが、カレントパスや取り掛かっているプロジェクトごとにアレコレ考えてMakefileを指定するのは現実的ではない。それする位なら、Compilationの利点を捨て、ターミナルのコマンドヒストリーでコンパイルした方がよっぽどマシである。たいてい、Makefileはソースフォルダのトップなりに置くので、編集中のファイルから上に辿り、見つかったMakefileでmakeしてくれれば済む話。

で、ようやくそれを実現する方法を見つけた。Recursively go up to find Makefile and compileに載ってるelispを使う。万が一消えた時用に転載。

(defun desperately-compile ()
  "Traveling up the path, find a Makefile and `compile'."
  (interactive)
  (when (locate-dominating-file default-directory "Makefile")
  (with-temp-buffer
    (cd (locate-dominating-file default-directory "Makefile"))
    (compile "make -k"))))
 
; C-x mでMakefileを探してコンパイル
(global-set-key (kbd "C-x m") 'desperately-compile)

上記サイトの回答に書いてあることだが、指定ファイルが見つかるまでディレクトリを遡って検索する打って付けのlocate-dominating-fileなる関数があるそうで。今回の用途だけではなく、様々な場面で役に立ちそう。

英語勉強のために宮崎駿作品集の北米版Blu-ray BOX「The Collected Works of Hayao Miyazaki」を買おうとしてるんだけど、どうも大量の海賊版が出回っているようだ。eBayは元よりメルカリやAmazon.co.jpでも“未開封新品”が販売されている。

正規品は2015年11月17日発売で、Amazon.com専売商品として希望小売価格249.99ドルで販売されていたらしい。当然ながら既に在庫はなく、日本国内から北米正規品を買うのはかなり困難だと思われる。2018年9月現在、12000円前後で新品未開封として販売されているものは、全て偽物と考えてよいだろう。

redditや解説動画によれば偽物の見分け方は結構簡単で、以下の部分に着目すれば良いそうだ。

1. パッケージを囲んでいる映画フィルム装飾が宮崎監督キャラ（ブタのやつ）に被っていたら偽物
   • 本物はTHE COLLECTED〜の題字の真下に来るようになっている。
2. 未開封パッケージ裏面に同フィルム装飾が見えたら偽物
   • 本物はボックスカバー紙（CDの帯カバー的なやつ）の下を通ってるので、見えるはずがない。
3. 内側のディスク収納ケースが外側ボックスの中央に格納されていたら偽物
   • 本物はブックレットの厚みの分、左寄りになっている。
4. 偽物はディスクの収納が雑。ディスク保護のビニールがはみ出している。
   • 本物はきちんとケース内に収まっている。

他にもシュリンクラップ（商品を覆ってるビニール）の形状が違うとか印刷物の色味が違うとかあるみたいだが、上記の特徴がわかれば十分かと。文字で説明すると何のこっちゃだが、映像を見れば一目瞭然なので、上記サイトの一読をオススメします。

ジブリの北米版Blu-rayは正規版が単品16ドル程で買えるので、微妙な値段で海賊版を掴まされないように気をつけよう！

• Beware of "The Collected Works of Hayao Miyazaki" Pirate Bootlegs! (Comparison of legit boxset vs. bootleg boxset) : ghibli
• The collected works of Hayao Miyazaki. Real VS Fake - YouTube
• THE COLLECTED WORKS OF HAYAO MIYAZAKI Blu-Ray Review | Nerdist

Windowsの記憶域階層について調べてたら、MSの中の人が書いたUnderstand Storage Space Tiering in Windows Server 2012 R2がとても分かりやすかった。Windows Server 2000 R2時代のものだけど、今でも通じる内容でしょう多分。記憶域階層使おうとしてる人は一読しといた方がいいと思う。

元記事の焼き直しでしかないが、気になったことをメモっておく。

• 記憶域階層に入ってくるデータは、まずはSSD層に満杯になるまで書き込まれる。
• SSD層が満杯になると、ランダムライトはSSD層内に予め確保されているライトバックキャッシュの方に書き込まれる。
• ライトバックキャッシュも一杯になると、HDD層の方に書き込まれると共にライトバックキャッシュのHDD層へのフラッシュが行われる。
• ライトバックキャッシュが空けば、ランダムライトは再びキャッシュの方に書き込まれる。

ここでのライトバックキャッシュとは、記憶域階層が持っている機能を指している。仮想ディスク毎にSSD層に確保される領域で、標準では1GBだがNew-VirtualDiskコマンドレットの引数-WriteCacheSizeで任意の容量を指定できる。前述の通り、SSD層が埋まらないとライトバックキャッシュは使われないため、あまり大きな領域を確保しても無駄だと思われる。

自分はてっきり、ライトバックキャッシュという名前の通り、その領域分が書き込み全般のキャッシュとして使われると思っていた。Crystal Disk Markでキャッシュサイズを超えるテストサイズでベンチ回しても速度が全く落ちずに不思議だったが、なるほどSSD層全体がキャッシュとして使われてたとはね。

読み込みの方は明確な説明がないので間違ってるかも…。

• SSD層にあるデータはSSD層から読まれる。
• SSD層にないデータはHDD層から読まれる。
• 毎日の記憶域階層最適化によりSSD層とHDD層でデータの入れ替えが行われ、よく使われるデータはサブファイル単位でSSD層に配置される。

自分はZFSしか知らんのでZFSとの比較になっちゃうけど、読み込みキャッシュの方は割と慎ましい挙動のように思う。記憶域階層最適化のサブファイル単位というのは、1MBブロック単位らしい。

これらの挙動から分かる通り、記憶域階層ではSSD層が酷使されるため、相応のSSDと相応のデータ保護手段を用いた運用にしないとトラブりそう。SSD層が死んだ場合に、記憶域スペース/仮想ディスクがどうなるかは未確認＆情報がない…。仕組み的にはSSD層にあるデータが死ぬだけで済みそうに思うんだけど、どうだかなー。現状、一旦記憶域階層として作ったが最後、後からSSD層を取り外す事もできないしなー。

• Understand Storage Space Tiering in Windows Server 2012 R2 – Larryexchange Blog
• The Effects Of WS2012 R2 Storage Spaces Write-Back Cache | Aidan Finn, IT Pro